Firefox включает полноценную поддержку Wayland

После того, как они перенесли всю отрисовку виджетов на какую то js/css подобную векторную фигню, так ещё и редуцировали большую часть элементов до пустого места? Что то как то слабо верится.

Дело в том, что тупо интерполировать – значит получить мыло. Почитайте, какую эвристику использует та же Windows, чтобы максимально избегать мыла с одной стороны, и артефактов масштабирования с другой.

Но там нет никакой необходимости что то интерполировать! При любой векторной отрисовке где то есть переменная масштаба и её надо просто подправить.

Больше верится что движок рендера писали одни обезьяны, масштабирование поручили другим, документацию забыли, что где крутить думать сложно. А то что проблема должна решаться по-другому - ну это мелочи.

С виндой скорее всего что то другое - виджеты win32 вроде бы не масштабируемые. Но напортачили то они с текстом. Хз как, но видимо просто приняли решение растянуть и не париться. Так проще и точно ничего не сломается по совместимости.

Но там нет никакой необходимости что то интерполировать! При любой векторной отрисовке где то есть переменная масштаба и её надо просто подправить.

Ну вот стоит у вас в CSS border: 1px solid #000000 — что делать при масштабировании 150%?

Если, как предлагают ниже, округлять до ближайшего целого, то тогда пусть имеем две линии: 1 пкс и 2 пкс; при масштабировании 150% вторая станет 3 пкс, а вот первая — 1,5, и округление в любую сторону нарушит оригинальное соотношение 1:2.

Короче, все эти «да можно просто…» — это рассуждения с дивана. Всё всегда кажется простым, если исходить из упрощённых моделей, не учитывающих весь спектр реальных применений. «Гладко было на бумаге».

К слову сказать пиксели в CSS могут быть дробными. Но то как это будет отрисовано - зависит от браузера.

Короче, все эти «да можно просто…» — это рассуждения с дивана. Всё всегда кажется простым, если исходить из упрощённых моделей, не учитывающих весь спектр реальных применений

Лучше конечно ничего не делать, а то перфекционисты будут страдать. А так страдают все, справедливость восторжествовала.

Я себе для ноута просто делал темы с увеличенными размерами для гтк3 и гтк2. Да, неидеально, но это работало. Не ждать же пока упоротые раздуплятся. У них кстати и целочисленное масштабирование кривое, куда им дробное ещё.

Ну вот стоит у вас в CSS border: 1px solid #000000 — что делать при масштабировании 150%?

Написано 1 пиксель? Рисуем 1 писель. Если мы предполагаем что дизайнер знал что делал.

Если мы предполагаем что дизайнер - _удак, тогда нужно подумать. Например рассчитать чему должен быть равен 1 дефолтпиксель на например 96ppi и исходя из этого пересчитать всё в милиметры а затем округлить до ближайшего целого. Но со шрифтами, наклонными и кривыми это плохо работает, так что выбираем подходящий режим субпиксельного сглаживания (а ещё лучше - даём на выбор юзеру) и применяем его на всё а не только текст.

Хотя что то мне подсказывает, что векторная графика на то и векторная, чтобы этот вопрос уже был решён в движке отрисовки. Так что надо просто определиться сколько милиметров эта линия.

Лучше всего конечно не рисовать пикселями векторную графику.

Так как я против думания за разработчика и искуственного урезания функционала - не буду предлагать выпилить из css для интерфейсов пиксельной отрисовки. Но предупреждение об ошибке выдавать нужно (разработчику). А так как некие области очевидно будут заливаться битмапами (в пикселях), то видимо стоит интерполировать со сглаживанием. Размеры области то заданы в милиметрах.

Написано 1 пиксель? Рисуем 1 писель.

И получим отсутствие масштабирования отдельных элементов интерфейса.

Например рассчитать чему должен быть равен 1 дефолтпиксель на например 96ppi и исходя из этого пересчитать всё в милиметры а затем округлить до ближайшего целого.

И получим артефакты. Например, имеем идущие рядом чёрную линию #1 в 1 пиксель, белую #2 в 1 пиксель и чёрную #3 в 2 пикселя. При масштабировании в 150% они все вместе должны отмасштабироваться в (1 + 1 + 2) * 1,5 = 6 пикселей. Линия #3 масштабируется нацело и займёт 2 * 1,5 = 3 пикселя, и остальные 3 пикселя останутся для линий #1 и #2. Какая из них должна быть округлена в какую сторону? Как решить, отдать белой линии 2 пикселя, а чёрной 1, или наоборот? И что делать с тем, что бывшие одинаковыми линии теперь в 2 раза отличаются по ширине?

интерполировать со сглаживанием

И получим мыло.

Ещё раз повторяю: задача дробного масштабирования интерфейса совсем не настолько тривиальна, как кажется с дивана.

И получим отсутствие масштабирования отдельных элементов интерфейса.
И получим артефакты.
И получим мыло.

А невозможно сначала нарисовать векторную графику в пикселях, а потом отмасштабировать без артефактов. Это можно сделать только достаточно хорошо и это лучше чем вообще никак или плохо.

задача дробного масштабирования интерфейса совсем не настолько тривиальна, как кажется с дивана.

И тем не менее, её надо решить хоть как то ещё 10 лет назад. Вот хотя бы как в винде - это плохо, но хотя бы работает! А тут сидят и жуют сопли над задачей, которая возможно даже не имеет принципиального идеального решения.

По факту gtk2 и xterm всё ещё лучше адаптируются к hidpi (ну, если не учитывать разнокалиберный многомонитор). Хотя gtk3 якобы изначально создавалась в т.ч. для лёгкого масштабирования через векторную отрисовку. Что у них пошло не так?

А невозможно сначала нарисовать векторную графику в пикселях, а потом отмасштабировать без артефактов

Очень даже возможно: целочисленное масштабирование происходит без потери информации. В случае дробного же — да, очень сложно добиться приемлемого результата.

Это можно сделать только достаточно хорошо и это лучше чем вообще никак или плохо.

С этим вроде никто и не спорит. Просто я объяснил, что задача эта далеко не такая простая, как может показаться на первый взгляд.

Надеюсь, что дробное масштабирование таки запилят в GTK. Но сам всё равно продолжу покупать экраны с PPI, позволяющим целочисленное масштабирование, ибо какие бы хорошие ни были эвристики, но всё равно артефактов при дробном масштабировании не избежать.

Очень даже возможно: целочисленное масштабирование происходит без потери информации.

Так целочисленное несостоятельно. Между 1, 2 и 3 находится ~80% существующих мониторов и для них нужно дробное.

но всё равно артефактов при дробном масштабировании не избежать.

Я всё таки думаю что проблема больше высосана из пальца перфекционистами. Ну и раздута до неприличных величин гномосеками, но это уже их личные проблемы... ну да, не совсем только их, потому что они срут всему гтк3+ софту.

Так целочисленное несостоятельно. Между 1, 2 и 3 находится ~80% существующих мониторов и для них нужно дробное.

Почему-то Apple додумалась для всех своих продуктов использовать одинаковую плотность пикселей в рамках линейки, а при переходах увеличивать её на целые коэффициенты, т.е. целевые показатели – плотность пикселей и диагональ, а не разрешение.

При этом ещё раз повторяю, что родная поддержка дробного масштабирования, несомненно, нужна просто ввиду засилья таких мониторов, но то, что такого говна навалом, ещё не означает, что это не говно.

Нет, это не говно. Это просто мониторы и под них надо писать тулкит. То что у эппл есть уникальная возможности ограничить выбор железа только удобным им не значит что все могут поступить так же.

Нет, это не говно. Это просто мониторы и под них надо писать тулкит. То что у эппл есть уникальная возможности ограничить выбор железа только удобным им не значит что все могут поступить так же.

Говно, потому что принуждают использовать алгоритмы масштабирования с артефактами и потерей информации.

Кстати, угадайте, как в MacOS работает нецелочисленное масштабирование.

Говно, потому что принуждают использовать алгоритмы масштабирования с артефактами и потерей информации.

Так, стоп, это мониторы существуют чтобы разработчикам тулкита было удобно писать код, или это наоборот, разработчики тулкита пишут код чтобы работать на мониторах?

Кстати, угадайте, как в MacOS работает нецелочисленное масштабирование.

Даже не интересно. Я не собираюсь покупать ничего у эппл по другим причинам.

Так, стоп, это мониторы существуют чтобы разработчикам тулкита было удобно писать код, или это наоборот, разработчики тулкита пишут код чтобы работать на мониторах?

Ни один из приведённых вариантов не противоречит тезису «Мониторы, принуждающие использовать дробное масштабирование, — говно, и лучше бы все ориентировались на некую стандартную плотность пикселей, а не разрешение».

Даже не интересно. Я не собираюсь покупать ничего у эппл по другим причинам.

Из «не собираюсь покупать» не следует «не интересно». Ну как хотите.

Ни один из приведённых вариантов не противоречит тезису «Мониторы, принуждающие использовать дробное масштабирование, — говно, и лучше бы все ориентировались на некую стандартную плотность пикселей, а не разрешение

А нет. Не сошлись...

Вот допустим если бы GTK3 контролировал хотя бы 51% всего десктопного софта на всех платформах, я бы ещё как то понял необходимость выкинуть ВСЕ созданные до этого мониторы и срочное производство и покупку новых, заточенных исключительно под целочисленное масштабирование.

Но к счастью это даже близко не так. Поэтому мониторы это просто мониторы, а говно - тулкит, который не может на них работать.

не следует «не интересно»

Следует. Потому что бессмысленно интересоваться тем, что нужно протестировать, но ты точно не будешь.

Вот допустим если бы GTK3 контролировал хотя бы 51% всего десктопного софта на всех платформах, я бы ещё как то понял необходимость выкинуть ВСЕ созданные до этого мониторы и срочное производство и покупку новых, заточенных исключительно под целочисленное масштабирование.

Вы всё ещё пытаетесь представить дело так, будто бы я как-то оправдываю отсутствие дробного масштабирования в GTK, хотя я уже несколько раз говорил, что оно должно быть, и плохо, что его нет.

При этом это нисколько не противоречит тому, что такие мониторы — всё равно говно, с тулкитом с дробным масштабированием или без.

При этом это нисколько не противоречит тому, что такие мониторы — всё равно говно, с тулкитом с дробным масштабированием или без.

Ну не знаю. Это то же самое, что заявлять что говно все здания с высотой этажа кроме 2300 и 4600мм. Или все машины, с двигателями между 80 и 160 лошадей или весом от 1250 до 2350кг. Ну это просто бред.

А особенно бред потому, что важен не ppi, видимый угол 1 пикселя в зависимости от расстояния до монитора. Идея стандартизовать ppi в целочисленных ступенях просто лишена физико-биологического смысла для человека-пользователя.

Это то же самое, что заявлять что говно все здания с высотой этажа кроме 2300 и 4600мм. Или все машины, с двигателями между 80 и 160 лошадей или весом от 1250 до 2350кг

В приведённых примерах различия в разумных пределах не приводят к неудобствам, а в случае мониторов — приводят, ибо даже с поддержкой дробного масштабирования то тут, то там вылезают косяки. Мне они сразу в глаза бросаются, и развидеть их потом сложновато.

а в случае мониторов — приводят

Нет, ведь мониторы на 120-140ppi это уже стандарт для кучи ноутов, а вин7 (и куча ДЕ в линуксах) отлично на них работали. Так что да, дробное масштабирование в линуксах так себе, но мне кажется сами виноваты потому что сами себе сделали геморроя.

Так что да, дробное масштабирование в линуксах так себе, но мне кажется сами виноваты потому что сами себе сделали геморроя.

Он везде так себе. Прям совсем современные версии Windows с дробным масштабированием не видел, но в 7 были косяки периодически. MacOS вообще не умеет нативно в дробное масштабирование и действует точно так же, как GNOME: масштабирует до ближайшего целого сверху, а затем скейлит вниз композитором до нужного.

В вин7 было всего 3 варианта: 1, 1,25 и 1,5. А вот косяков вообще не было. В вин8+ косяки появились, потом починились, потом снова появились.

Следует. Потому что бессмысленно интересоваться тем, что нужно протестировать, но ты точно не будешь.

Не следует. Для «интересно» достаточно любознательности, желания получения знаний, которые необязательно будут практически применяться. Людям может быть интересна тема чёрных дыр, и вовсе не потому что они собираются отправиться к оной.

Вот только экран макбука это не чёрная дыра. Чтобы понять как он выглядит ИРЛ надо посмотреть на него ИРЛ, и желательно пару десятков часов в разных окружениях.

По факту gtk2 и xterm всё ещё лучше адаптируются к hidpi

Это ну вообще не так. Применение темы с большими размерами элементов не является универсальным решением, ибо в программах могут быть захардкожены определённые размеры, и получите адовую мешанину. Сам тулкит должен уметь умножать размеры на коэффициент, а растр — растягивать со сглаживанием, иначе получите разнобой. Попробуйте какой-нибудь Anydesk с такой темой запустить.

Если в программе что то захардкожено - тулкит тут в принципе бессилен.

А с растяжением растра - согласен, это единственный рабочий выход и пора прекратить искать филосовский камень или ждать новых мониторов, надо просто сделать не хуже чем в винде и начать работать.

Если в программе что то захардкожено - тулкит тут в принципе бессилен.

С чего бы это? Захардкожены значения размеров, которые всё равно обрабатываются тулкитом, поэтому тот волен увеличить их все на произвольный коэффициент.

А если захардкожены пиксели через какой нибудь «вывести прямоугольник 10х20» в обход тулкита? Наверняка существует способ сделать так, что масштабирование всё поломает и наверняка этим способо кто то пользуется и приличного решения просто не будет.

А если захардкожены пиксели через какой нибудь «вывести прямоугольник 10х20» в обход тулкита?

А куда он это выводит в обход тулкита? Если на канвас, то масштабируется как растр. Если прям своя отрисовка, то тогда да, не выйдет — но много ли вы встречали подобных приложений, да ещё и не умеющих в масштабирование самостоятельно?

но много ли вы встречали подобных приложений, да ещё и не умеющих в масштабирование самостоятельно?

Да встречал изредка. Но тут мы возвращаемся к тому же вопросу: ИЛИ приложение изначально расчитано на масштбаирование, в т.ч. через векторные линии в css, ИЛИ тулкит и ВМ ничерта с этим сделать не смогут - только в лоб растянуть и замылить растр.

ИЛИ приложение изначально расчитано на масштбаирование, в т.ч. через векторные линии в css, ИЛИ тулкит и ВМ ничерта с этим сделать не смогут - только в лоб растянуть и замылить растр.

Если приложение захотело нарисовать кнопку, для чего расположило прямоугольник шириной 50 пкс и толщиной линии 2 пкс, в котором поместило текст 12 пкт — ничто не мешает тулкиту умножить все эти значения, например, на 2, и получить тем самым двукратное масштабирование. Так что в подавляющем большинстве случаев всё прекрасно целочисленно масштабируется без потери качества.

Мы вроде бы уже сошлись на том, что между 96 и 182 ppi есть чёртова туча мониторов, на которых надо как то работать. Короче или рисовать линии в милиметрах, или смириться с тем, что линия толщиной 3,475 пикселя это нормально несмотря на весь полагающийся при этом блюр, радугу и настройки субпиксельного сглаживания.

Почитайте, какую эвристику использует та же Windows, чтобы максимально избегать мыла с одной стороны, и артефактов масштабирования с другой.

Что мешает увеличивать все размеры в CSS до ближайшего целого? Им CSS вообще для чего? Только чтобы ломать мозг разработчикам тем? Браузеры масштабируют нормально уже сто лет как.