Хорошая мысль, я почему-то про текстовый узел и не подумал. До этого пробовал через комментарии, там само собой nodeValue брал, но когда переключился на скрипт совсем из виду упустил, что внутри script в любом случае у меня будет текстовый узел, и можно напрямую с него брать.
Это, конечно, вероятно никак на скорости не отразится ощутимо, но однозначно правильнее будет. Спасибо, поправлю чуть позже ;)
Хорошее замечание. Странно, когда я тестировал алфавит валидатор html не ругался на x98 символ. Меня не смутило, что у него глифа нет, главное, что его валидатор проглатывал. Но, сейчас перепроверил и валидатор грозно ругается на этот символ... Хм. Придется его заменить. Убрать его и вместо него другой использовать, например < (но с доп логикой, которая не позволит появится закрывающему тегу </script> ).
Спасибо за подсказу. Я бы сам не заметил проблему, так как неверные где-то результаты валидации были, из-за чего этот символ попал в алфавит кодировки.
IndexedDB позволяет передать браузеру большие Blob объекты, и он уже сам заботится, чтобы они не занимали оперативную память. Т.е. IndexedDB тут нужен лишь как disk-based хранилище данных
мне в любом случае приятно обсуждать это, так что спасибо за идеи)
Рисовать утомительно, всегда хочется упростить (при том, что я по профессии программист уже больше 20 лет и привык искать пути полегче), и уже не раз думал, что неплохо бы обучить нейронку в помощь в рисовании. Но потом всякий раз отрезвляло то, что я делаю - это творческая работа не для заработка, а для вау-эффекта и искусства в целом. И важно до последней анимации в этом проекте сохранить подход: нарисовано все должно быть от руки без замены человека нейронкой. Тогда ценность проекта сохранится, так как для его создания не применялся ИИ и другие сильные упрощения. Знаешь как в спорте, допинг запрещен. Вот тут применение ИИ - это чистый допинг :D
По поводу Unity и Unreal. Я больше веб-разработчик, поэтому мне ближе WebGL, WebGPU и библиотеки под него, типа Three.js. Для перевода моего проекта с рендара на потоках js в рендер на шейдерах видеокарты без сторонних библиотек нужно много работать. Я уже начинал это делать на WebGPU, придумал как создать рендер на шейдере но, забросил, пока что не возвращался. Но если перевести, то проблемы в производительности почти не будет. Но и сейчас их толком нет. Сейчас проекту нужен обычный 12fps, и согласно статистике проекта, большая часть пользователей успешно успевает рендерить 12fps. Т.е. проблемы с производительностью из-за использования рендера через канвас на js практически нет. Я делаю ставку на будущее, что и устройства, и браузеры - все будет ускорятся, а следом за ними мой проект. Его ещё рисовать как минимум 5 лет до 100 блоков, а там посмотрим ;)
пропускать анимацию через нейронку для апскейла и увеличения FPS анимации
Я бы хотел этого избежать. В моей анимации все криво, непрофессионально, редуцированно - все это часть образа, итог ручной работы. Именно это и должно быть во всех копиях проекта. Т.е. я специально не делаю интерполяцию (хотя могу запрограммировать её и без ИИ), специально не применяю трехмерные куклы для ускорения рисования, у меня в редакторе даже нет вставки картинок извне и нельзя печатать текст (специально), все рисую вручную, все тексты на экранах, все "копии" чего-либо (хотя 100 раз проще было бы вставить картинку, чем её перерисовывать). Я запретил все это со старта специально, чтобы у проекта был свой шарм, идея - все нарисовано от руки. Я не переделываю старые части проекта, которые рисовал ещё более криво и редуцированно, чем сейчас, также по причине того, что проект содержит историю изменения стиля и качества рисовки, это часть работы) Под редуцированием имею в виду прием в анимации для сокращения кадров, из-за этого анимация выглядит резкой, не такой естественной.
Итого, я целенаправленно не применяю ни ИИ, ни другие вещи, которые бы улучшали уже нарисованные сцены.
zip не поможет ничего сэкономить, точнее максимум 2%, именно та избыточность, которую добавляет Base223.
Оригинальные 168МБ данных уже сжаты разными Brotli и gzip/deflate. Так что сверху накладывается где-то 2% избыточности от Base223 и получается html весом 170МБ. Так что zip ничем тут не поможет для трафика, если оригинальный контент им сжимать или итоговый HTML им сжимать .
В теге script использовать & безопасно. Этот символ неотъемлемая часть js, в котором используется для операторов И и побитовое И.
А пробелы и табы просто так никто не будет трогать в документе. Если речь про использование Base223 где-то ещё, то само собой алфавит нужно пересматривать под ту задачу, к которой он применяется. В моем случае html файл собирается и его содержимое никто менять не должен. Точно также, как если собрать бинарник, его трогать нельзя, перестанет работать.
да можно и rar, чего уж там, у всех крякнутый где-то да найдется :)
Но если серьезно, то идея была сделать с максимальной доступностью. К примеру, zip на планшете или телефоне открыть может быть проблемой, да и рядовой пользователь может не понять что он скачал и как это открыть (уровень владения ПК у всех разный).
Также в идее с zip нет уникальности или какого-либо "открытия". Мне нравится мыслить креативно, искать новые пути. И вот показалось интересным возовом упаковать проект в один html, сделав его максимально компактным, с высокой доступностью и безопасностью.
Ну, я снова оставлю в спойлере ответ, если никак не получится, то смотри спойлер: там 8 тумблеров, каждой переключается в 2 состояния, т.е. по сути 8 значений от 0 до 1. Думаю так как мы на Хабре сейчас, то должно сразу быть понятно, что это двоичная форма байта. Т.е. задача ввести 77 число в двоичной форме. Можно так и загуглить "число 77 в 8 битах"
Тогда если нужна подсказка где штекер: его можно найти где комната с голограммами переключающимися. По задумке эти голограммы разработаны то же фирмой, что и тюнер.
Нужно подобрать правильную настройку тюнера. Для этого на экранчике на самом тюнере показывается подсказка, что нужно позвонить в сервис, и указывается на то, что номер телефона сервиса можно получить, если выдернуть штекер какой-то. Уточните, это уже прошли и штекер нашли?
98% всего объема, что добавляется в html документ - это уже сильно сжатые файлы: анимация, музыка, jpg и прочее. Эти данные практически не сжимаются больше.
2% - это всякие текстовые файлы, типа js, css, json и пр. Они предварительно сжимаются gzip, и далее кодируются через Base223.
Тут и замеры не нужны, обработка кодирования значительно дольше делается и более ресурсоемкая априори. Браузер как-никак сверхбыстрая штука нынче.
Но, как в статье и описано, декодирование делается ленивое, т.е. только когда требуется нужный ресурс. Не все 170 МБ сразу нужны для рендера. Поэтому декодирование делается лишь малой части от этого объема. А далее пользователь скролирует анимационную сцену и при подгрузке новых ресурсов налету делается декодирование. Чисто по визуальному и функциональному поведению все хорошо - браузер на разных устройствах успевает декодировать Base223 налету так, что глазу это практически незаметно. Результат меня удовлетворил. Однако, если даже предположить, что декодирование было бы долгим, то я все равно бы остался на выбранном варианте, просто искал способы ускорить декодирование, в частности применение wasm или webgpu.
Я понимаю ваши опасения касательно моего выбора. Внутри меня где-то чуйка тоже шепчет "куда ты лезешь, используй base64 и не выпендривайся". Но все же рациональная оценка ситуации говорит о том, что риски не такие большие, и в случае чего я всегда могу заменить способ кодирования на другой. Итого: файл значительно меньше, визуально никаких проблем с декодированием налету нет, поддержка cp1251 стабильная и нет предпосылок считать, что браузеры откажутся от этой кодировки в обозримом будущем.
дольше качаться будет. Не у всех высокоскоростной интернет.
я плачу за трафик. Не так много, $0.005 за ГБ, но с учетом, что на проект иногда наплывами заходят в день по 80 тыс человек, то трафик порой за месяц выходит в $100+.
чем больше по размеру HTML, тем больше браузеру нужно ресурсов для его загрузки. Это сказывается на скорости чтения файла: больше обращений к диску, больше объема данных на сканирование, больше объема данных для работы с памятью.
вопрос совести. Мне, как программисту, не дает покоя, что я делаю что-то неоптимальное. В данном случае риски фантомные пока что, я реальных рисков не вижу, поэтому путь оптимизации через использование cp1251 выглядит точно диким, но рабочим и на сегодняшний день не опасным на горизонте. Но согласен, что завтра все может поменяться.
Пока что да, стоит. Проект будет расти и через пару лет будет весить 220 уже в исходном виде, поэтому со старта искал вариант уменьшить размер.
А почему не у всех работает? И почему чем дальше, то не у всех? Эта кодировка никуда не планирует исчезать, повторюсь - она входит в спецификацию HTML как обязательная для поддержки браузерами.
В любом случае как только объявят, что cp1251 будет выпиливаться из поддержки основных браузеров, тогда я поменяю способ кодирования на Base85, или снова сяду за анализ вариантов и что-нибудь подберу оптимальное на замену cp1251. Но пока что нет ни намека, что какой-то браузер будет не поддерживать cp1251. Или я ошибаюсь и где-то поддержки нет?
да, понял теперь про что вы. Так и есть, при рендере HTML многие пробельные символы схлопываются. Но для нас важен сам контент, он само собой никуда не схлопывается если брать textContent от узла DOM. Табуляцию безопасно использовать, а вот перенос строки нужно много тестов на разных ОС, так как в некоторых случаях \n (т.е. 0x0A) не читался назад. А вот с \r (0x0D) совсем беда была. Поэтому чтобы сильно не рисковать я решил исключить \n из алфавита, хотя в теории можно его использовать, нужно просто все тесты перепроверить на разных устройствах.
Да, все отличные от UTF-8 кодировки накладывают различные особенности в работе браузера. Если рассматривать какой-нибудь сайт, где важна скорость загрузки, кеширование всего, и кучу разных метрик web vitals, то полностью поддерживаю, только utf-8 нужно использовать. То, что vk.com и pikabu.ru используют cp1251 связано с пресловутым "исторически сложилось", так как слезть с кодировки, когда у проекта вся база в ней, весь код написан с учетом однобайтовой кодировки - это титанический труд, когда проект очень большой и в нем миллионы страниц и пользователей. Если новый проект - само собой только utf8 и ничего другого.
Однако в моем случае речь идет про скачиваемый файл, который и так кеширования не будет изменить никакого. Для такого сценария можно закрыть глаза на использование однобайтовой кодировки в угоду уменьшения размера файла.
Хорошая мысль, я почему-то про текстовый узел и не подумал. До этого пробовал через комментарии, там само собой nodeValue брал, но когда переключился на скрипт совсем из виду упустил, что внутри script в любом случае у меня будет текстовый узел, и можно напрямую с него брать.
Это, конечно, вероятно никак на скорости не отразится ощутимо, но однозначно правильнее будет. Спасибо, поправлю чуть позже ;)
Хорошее замечание. Странно, когда я тестировал алфавит валидатор html не ругался на x98 символ. Меня не смутило, что у него глифа нет, главное, что его валидатор проглатывал. Но, сейчас перепроверил и валидатор грозно ругается на этот символ... Хм. Придется его заменить. Убрать его и вместо него другой использовать, например
<(но с доп логикой, которая не позволит появится закрывающему тегу</script>).Спасибо за подсказу. Я бы сам не заметил проблему, так как неверные где-то результаты валидации были, из-за чего этот символ попал в алфавит кодировки.
IndexedDB позволяет передать браузеру большие Blob объекты, и он уже сам заботится, чтобы они не занимали оперативную память. Т.е. IndexedDB тут нужен лишь как disk-based хранилище данных
Ссылку побоялся оставлять в тексте статьи, так как могли посчитать рекламой.
Сам проект https://floor796.com/
Ссылка на скачивание https://floor796.com/data/floor796.html
мне в любом случае приятно обсуждать это, так что спасибо за идеи)
Рисовать утомительно, всегда хочется упростить (при том, что я по профессии программист уже больше 20 лет и привык искать пути полегче), и уже не раз думал, что неплохо бы обучить нейронку в помощь в рисовании. Но потом всякий раз отрезвляло то, что я делаю - это творческая работа не для заработка, а для вау-эффекта и искусства в целом. И важно до последней анимации в этом проекте сохранить подход: нарисовано все должно быть от руки без замены человека нейронкой. Тогда ценность проекта сохранится, так как для его создания не применялся ИИ и другие сильные упрощения. Знаешь как в спорте, допинг запрещен. Вот тут применение ИИ - это чистый допинг :D
Спасибо)
По поводу Unity и Unreal. Я больше веб-разработчик, поэтому мне ближе WebGL, WebGPU и библиотеки под него, типа Three.js. Для перевода моего проекта с рендара на потоках js в рендер на шейдерах видеокарты без сторонних библиотек нужно много работать. Я уже начинал это делать на WebGPU, придумал как создать рендер на шейдере но, забросил, пока что не возвращался. Но если перевести, то проблемы в производительности почти не будет. Но и сейчас их толком нет. Сейчас проекту нужен обычный 12fps, и согласно статистике проекта, большая часть пользователей успешно успевает рендерить 12fps. Т.е. проблемы с производительностью из-за использования рендера через канвас на js практически нет. Я делаю ставку на будущее, что и устройства, и браузеры - все будет ускорятся, а следом за ними мой проект. Его ещё рисовать как минимум 5 лет до 100 блоков, а там посмотрим ;)
Я бы хотел этого избежать. В моей анимации все криво, непрофессионально, редуцированно - все это часть образа, итог ручной работы. Именно это и должно быть во всех копиях проекта. Т.е. я специально не делаю интерполяцию (хотя могу запрограммировать её и без ИИ), специально не применяю трехмерные куклы для ускорения рисования, у меня в редакторе даже нет вставки картинок извне и нельзя печатать текст (специально), все рисую вручную, все тексты на экранах, все "копии" чего-либо (хотя 100 раз проще было бы вставить картинку, чем её перерисовывать). Я запретил все это со старта специально, чтобы у проекта был свой шарм, идея - все нарисовано от руки. Я не переделываю старые части проекта, которые рисовал ещё более криво и редуцированно, чем сейчас, также по причине того, что проект содержит историю изменения стиля и качества рисовки, это часть работы) Под редуцированием имею в виду прием в анимации для сокращения кадров, из-за этого анимация выглядит резкой, не такой естественной.
Итого, я целенаправленно не применяю ни ИИ, ни другие вещи, которые бы улучшали уже нарисованные сцены.
zip не поможет ничего сэкономить, точнее максимум 2%, именно та избыточность, которую добавляет Base223.
Оригинальные 168МБ данных уже сжаты разными Brotli и gzip/deflate. Так что сверху накладывается где-то 2% избыточности от Base223 и получается html весом 170МБ. Так что zip ничем тут не поможет для трафика, если оригинальный контент им сжимать или итоговый HTML им сжимать .
В теге script использовать & безопасно. Этот символ неотъемлемая часть js, в котором используется для операторов И и побитовое И.
А пробелы и табы просто так никто не будет трогать в документе. Если речь про использование Base223 где-то ещё, то само собой алфавит нужно пересматривать под ту задачу, к которой он применяется. В моем случае html файл собирается и его содержимое никто менять не должен. Точно также, как если собрать бинарник, его трогать нельзя, перестанет работать.
да можно и rar, чего уж там, у всех крякнутый где-то да найдется :)
Но если серьезно, то идея была сделать с максимальной доступностью. К примеру, zip на планшете или телефоне открыть может быть проблемой, да и рядовой пользователь может не понять что он скачал и как это открыть (уровень владения ПК у всех разный).
Также в идее с zip нет уникальности или какого-либо "открытия". Мне нравится мыслить креативно, искать новые пути. И вот показалось интересным возовом упаковать проект в один html, сделав его максимально компактным, с высокой доступностью и безопасностью.
Ну, я снова оставлю в спойлере ответ, если никак не получится, то смотри спойлер: там 8 тумблеров, каждой переключается в 2 состояния, т.е. по сути 8 значений от 0 до 1. Думаю так как мы на Хабре сейчас, то должно сразу быть понятно, что это двоичная форма байта. Т.е. задача ввести 77 число в двоичной форме. Можно так и загуглить "число 77 в 8 битах"
Тогда если нужна подсказка где штекер: его можно найти где комната с голограммами переключающимися. По задумке эти голограммы разработаны то же фирмой, что и тюнер.
Добрый день)
Нужно подобрать правильную настройку тюнера. Для этого на экранчике на самом тюнере показывается подсказка, что нужно позвонить в сервис, и указывается на то, что номер телефона сервиса можно получить, если выдернуть штекер какой-то. Уточните, это уже прошли и штекер нашли?
98% всего объема, что добавляется в html документ - это уже сильно сжатые файлы: анимация, музыка, jpg и прочее. Эти данные практически не сжимаются больше.
2% - это всякие текстовые файлы, типа js, css, json и пр. Они предварительно сжимаются gzip, и далее кодируются через Base223.
Т.е. документ и так сильно сжат, сильнее его не сжать. Вы можете попробовать скачать его и сжать https://floor796.com/data/floor796.html
К примеру через zip он сожмется с 171 МБ до 168МБ, т.е. сократит ту избыточность, что добавляет кодировка Base223 назад в оригинальный размер данных.
Тут и замеры не нужны, обработка кодирования значительно дольше делается и более ресурсоемкая априори. Браузер как-никак сверхбыстрая штука нынче.
Но, как в статье и описано, декодирование делается ленивое, т.е. только когда требуется нужный ресурс. Не все 170 МБ сразу нужны для рендера. Поэтому декодирование делается лишь малой части от этого объема. А далее пользователь скролирует анимационную сцену и при подгрузке новых ресурсов налету делается декодирование. Чисто по визуальному и функциональному поведению все хорошо - браузер на разных устройствах успевает декодировать Base223 налету так, что глазу это практически незаметно. Результат меня удовлетворил. Однако, если даже предположить, что декодирование было бы долгим, то я все равно бы остался на выбранном варианте, просто искал способы ускорить декодирование, в частности применение wasm или webgpu.
Я понимаю ваши опасения касательно моего выбора. Внутри меня где-то чуйка тоже шепчет "куда ты лезешь, используй base64 и не выпендривайся". Но все же рациональная оценка ситуации говорит о том, что риски не такие большие, и в случае чего я всегда могу заменить способ кодирования на другой. Итого: файл значительно меньше, визуально никаких проблем с декодированием налету нет, поддержка cp1251 стабильная и нет предпосылок считать, что браузеры откажутся от этой кодировки в обозримом будущем.
Вижу вот такие проблемы:
дольше качаться будет. Не у всех высокоскоростной интернет.
я плачу за трафик. Не так много, $0.005 за ГБ, но с учетом, что на проект иногда наплывами заходят в день по 80 тыс человек, то трафик порой за месяц выходит в $100+.
чем больше по размеру HTML, тем больше браузеру нужно ресурсов для его загрузки. Это сказывается на скорости чтения файла: больше обращений к диску, больше объема данных на сканирование, больше объема данных для работы с памятью.
вопрос совести. Мне, как программисту, не дает покоя, что я делаю что-то неоптимальное. В данном случае риски фантомные пока что, я реальных рисков не вижу, поэтому путь оптимизации через использование cp1251 выглядит точно диким, но рабочим и на сегодняшний день не опасным на горизонте. Но согласен, что завтра все может поменяться.
Пока что да, стоит. Проект будет расти и через пару лет будет весить 220 уже в исходном виде, поэтому со старта искал вариант уменьшить размер.
А почему не у всех работает? И почему чем дальше, то не у всех? Эта кодировка никуда не планирует исчезать, повторюсь - она входит в спецификацию HTML как обязательная для поддержки браузерами.
В любом случае как только объявят, что cp1251 будет выпиливаться из поддержки основных браузеров, тогда я поменяю способ кодирования на Base85, или снова сяду за анализ вариантов и что-нибудь подберу оптимальное на замену cp1251. Но пока что нет ни намека, что какой-то браузер будет не поддерживать cp1251. Или я ошибаюсь и где-то поддержки нет?
Так и сделано) Для некоторых типов файлов применяется gzip, и поверх Base223.
Т.е. я максимально постарался все сжать. Файлы самой анимации сжаты очень сильно моим алгоритмом компрессии анимации, а поверх сжаты Brotli + Base223.
да, понял теперь про что вы. Так и есть, при рендере HTML многие пробельные символы схлопываются. Но для нас важен сам контент, он само собой никуда не схлопывается если брать textContent от узла DOM. Табуляцию безопасно использовать, а вот перенос строки нужно много тестов на разных ОС, так как в некоторых случаях \n (т.е. 0x0A) не читался назад. А вот с \r (0x0D) совсем беда была. Поэтому чтобы сильно не рисковать я решил исключить \n из алфавита, хотя в теории можно его использовать, нужно просто все тесты перепроверить на разных устройствах.
Да, все отличные от UTF-8 кодировки накладывают различные особенности в работе браузера. Если рассматривать какой-нибудь сайт, где важна скорость загрузки, кеширование всего, и кучу разных метрик web vitals, то полностью поддерживаю, только utf-8 нужно использовать. То, что vk.com и pikabu.ru используют cp1251 связано с пресловутым "исторически сложилось", так как слезть с кодировки, когда у проекта вся база в ней, весь код написан с учетом однобайтовой кодировки - это титанический труд, когда проект очень большой и в нем миллионы страниц и пользователей. Если новый проект - само собой только utf8 и ничего другого.
Однако в моем случае речь идет про скачиваемый файл, который и так кеширования не будет изменить никакого. Для такого сценария можно закрыть глаза на использование однобайтовой кодировки в угоду уменьшения размера файла.
Он запрещен в HTML во всех кодировках совместимых с ASCII.
Т.е. документ будет не валидным, если будет присутствовать такой символ что в utf8, что в cp1251