Всё просто - хром делает ставку на avif, у которой сейчас огромный консорциум поддерживающих организаций, в том числе аппаратное. А jpegxl на сколько я помню продвигает только MS в основном.
оценивать по наихудшим показателям, пожалуй, логичнее, чем по усреднённым
Даже во всяких "эксперементариумах" есть специальные комнаты, где даже находиться не комфортно, мозг визуально воспринимает одно, а сила тяжести оказывается совсем не в том направлении, который ощущает мозг.
+100500. Алгоритм ближайшего соседа используют только ради производительности. В остальных случаях всегда используется сглаживание по всем пикселям что попадают в новую сетку.
У меня обычный Ubuntu server в корпусе microtower, сама хостовая ос занимается функцией файлового хранилища (samba, WebDAV), dlna сервер, web-сервер на пару проектов, и как централизованный доступ к серверам (sshfs). В virtualbox крутится дев-сервер, на нем vscode (code-server), и склонированы все gitы активных проектов. Роутер keenetic рулит vpnами, у провайдера подключен статический IP.
Все это решает проблемы:
1) хранения и доступа к файлам из любого места (не люблю я эти nextcloud, проще через WebDAV/браузер зайти куда надо)
2) среды разработки доступной в любой точке мира из браузера, без конфигурирования.
3) лёгкого доступа к файлам и командной строке различных серверов
В начале процент и не нужен для MP. MySQL/PG/SQL Server/SQLite - 100% норм индексируют like с процентом на конце, у вас видимо экзотика. А вот в json или массивах точно не стоит это хранить, по крайней мере если хочется нормальный индекс) В лучшем случае это хранить в специализированных типах, типа ltree в pg.
Полнотекстовый поиск тут точно не нужен. Тут вообще можно collate на binary включить.
MP по сравнению с NS - очень легко готовится: 1) чтобы добавить элемент - берём path родителя, и добавляем к нему идентификатор элемента, таким образом получая новый path
2) Чтобы переместить узел просто меняем подстроку пути у всех элементов по like 'path%'
Materialized Path даёт возможность сделать выборку легко в этом случае: `select * from tree where path like 'branch2/%'`. Как и писал комбинация AL+MP даёт, имхо, самую лучший вариант для любого дерева. А NS умирает если вставить в начало дерева из >10000 элементов.
К сожалению, картинки в формате .jxl пока не поддерживаются ни одним браузером по умолчанию. Но это вопрос времени, потому что с технической точки зрения ему нет равных.
Ой как далеко не факт. Техническое превосходство это не фактор успеха формата.
Добавлю в копилку. Недавно был у нас проект, ничего экстра ординарного, несколько сущностей, UI в виде табличек, требований к дизайну особо не было. Совсем недавно всё это делалось одним человеком на Yii2+bootstrap3 за месяц максимум, и работало надёжно как лопата. Сейчас же всё это считается устаревшим, включая подходы к backend/frontend. Так вот, теперь такой проект пилили 4 месяца 2 отдельных front/back - программиста, всё по современному typescript/nestjs на бэке, spa/vue/quasar на фронте. Естественно всё это с кучей зависимостей, в докерах и т. д, напоминает супер-пупер навороченный мото-культиватор.
По итогу картошку лопатой выкопал один человек за день, а с мотокультиватором двое за четыре)
Я пришел к выводу что лучше всего комбинировать AL+MP, это даёт лёгкое получение всех основных операций, а из недостатков - только сложности с обновлением детей родителя при его перемещении, что обычно не очень частая операция, которая к тому же легко выполняется за счёт индекса.
NS - вообще годится только для маленьких деревьев, так как вставка в начало большого дерева - это дикая боль, пересчитывающее все дерево.
Тут возникает другая проблема, что высота контента может поменяться (например вследствие изменении размера окна), и тогда контент вылезет за зафиксированную скриптом высоту. Со скриптами можно уже и нормально реализовать. Навесив на transitionend - height: auto.
Всё просто - хром делает ставку на avif, у которой сейчас огромный консорциум поддерживающих организаций, в том числе аппаратное. А jpegxl на сколько я помню продвигает только MS в основном.
Почему это логичнее?
Даже во всяких "эксперементариумах" есть специальные комнаты, где даже находиться не комфортно, мозг визуально воспринимает одно, а сила тяжести оказывается совсем не в том направлении, который ощущает мозг.
главное такую батарейку не мять, а то будет смачный "бабах"
+100500. Алгоритм ближайшего соседа используют только ради производительности. В остальных случаях всегда используется сглаживание по всем пикселям что попадают в новую сетку.
У меня обычный Ubuntu server в корпусе microtower, сама хостовая ос занимается функцией файлового хранилища (samba, WebDAV), dlna сервер, web-сервер на пару проектов, и как централизованный доступ к серверам (sshfs). В virtualbox крутится дев-сервер, на нем vscode (code-server), и склонированы все gitы активных проектов. Роутер keenetic рулит vpnами, у провайдера подключен статический IP.
Все это решает проблемы:
1) хранения и доступа к файлам из любого места (не люблю я эти nextcloud, проще через WebDAV/браузер зайти куда надо)
2) среды разработки доступной в любой точке мира из браузера, без конфигурирования.
3) лёгкого доступа к файлам и командной строке различных серверов
И все это без особого оверхеда в железе.
Когда история покупок вернётся в перекрёстке?
Искал как-то ещё более простой редактор svg, в плане просто передвигать, вращать, масштабировать, менять тексты. В итоге свой реализовал.
Странно что про min и max указали, а про clamp ни слова.
Listener из Total Commander тоже очень неплохо выполняет открытие и поиск по большим файлам, как и в FAR он не загружает весь файл в память.
В начале процент и не нужен для MP. MySQL/PG/SQL Server/SQLite - 100% норм индексируют like с процентом на конце, у вас видимо экзотика. А вот в json или массивах точно не стоит это хранить, по крайней мере если хочется нормальный индекс) В лучшем случае это хранить в специализированных типах, типа ltree в pg.
Полнотекстовый поиск тут точно не нужен. Тут вообще можно collate на binary включить.
MP по сравнению с NS - очень легко готовится:
1) чтобы добавить элемент - берём path родителя, и добавляем к нему идентификатор элемента, таким образом получая новый path
2) Чтобы переместить узел просто меняем подстроку пути у всех элементов по like 'path%'
Это что за БД такая, которая не умеет юзать индексы на like с процентом в конце?
По скорости замеры проводил тут.
Полезность nested sets имхо преувеличена.
Materialized Path даёт возможность сделать выборку легко в этом случае: `select * from tree where path like 'branch2/%'`. Как и писал комбинация AL+MP даёт, имхо, самую лучший вариант для любого дерева. А NS умирает если вставить в начало дерева из >10000 элементов.
Причем в нем можно одной кнопкой поднять https, и будет работать даже за nat, через облака кинетика
Ой как далеко не факт. Техническое превосходство это не фактор успеха формата.
Поддерживают. Обычно это тупо видео без контролов с autoplay, но есть поддержка анимированных webp, правда почему-то его редко применяют.
Добавлю в копилку. Недавно был у нас проект, ничего экстра ординарного, несколько сущностей, UI в виде табличек, требований к дизайну особо не было. Совсем недавно всё это делалось одним человеком на Yii2+bootstrap3 за месяц максимум, и работало надёжно как лопата. Сейчас же всё это считается устаревшим, включая подходы к backend/frontend. Так вот, теперь такой проект пилили 4 месяца 2 отдельных front/back - программиста, всё по современному typescript/nestjs на бэке, spa/vue/quasar на фронте. Естественно всё это с кучей зависимостей, в докерах и т. д, напоминает супер-пупер навороченный мото-культиватор.
По итогу картошку лопатой выкопал один человек за день, а с мотокультиватором двое за четыре)
Я пришел к выводу что лучше всего комбинировать AL+MP, это даёт лёгкое получение всех основных операций, а из недостатков - только сложности с обновлением детей родителя при его перемещении, что обычно не очень частая операция, которая к тому же легко выполняется за счёт индекса.
NS - вообще годится только для маленьких деревьев, так как вставка в начало большого дерева - это дикая боль, пересчитывающее все дерево.
1) Размер шрифта можно легко вычислить через measureText
2) Ну а самый простой вариант, это делать все же в svg text, и одной строчкой кода просто корректировать viewBox, согласно длине text.getBBox().
Тут возникает другая проблема, что высота контента может поменяться (например вследствие изменении размера окна), и тогда контент вылезет за зафиксированную скриптом высоту. Со скриптами можно уже и нормально реализовать. Навесив на transitionend - height: auto.
Можно ещё вынести форму куда то вниз перед боди, и использовать только кнопку с атрибутами form и formaction.
Но это все конечно странности...