LINUX.ORG.RU

Крыса, иксы и масштабирование

 ,


0

2

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

Предлагаю вам отвлечься от всего мирского и вместе со мной насладиться скриншотами рабочего стола уважаемого @kirill_rrr, который сделал их специально для меня, как убедительную демонстрацию работы дробного масштабирования под иксами, цитирую:

показываешь ему работу дробного масштабирования с отрисовкой на стороне клиента, реализованное в Х11 ещё тогда когда вайланда даже в планах не было да и вообще проблемы HiDPI не стояло

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

Вдохните и выдохните. Эти скриншоты подарят вам спокойствие и умиротворение. Вы поймете, что спорить с людьми о шрифтах, масштабировании, иксах и вяленде нет никакого смысла. Идеал существует, и он перед вами.

★★★★

Проверено: dataman ()
Последнее исправление: dataman (всего исправлений: 3)
Ответ на: комментарий от liksys

Что именно у меня не работает, ну-ка расскажи?

Очевидно расширенные настройки переключения раскладок которые тебе не нужны.

Потому что это базовый концепт UI-строения - называется «режим»

В «базовыом концепте UI-строения» нет ограничения на то какие именно там будут режимы. Гномосеки решили что должно быть всего 2? Или вообще 1? В Кде ограничились 2 + непонятное деление по комнатам, хрен с ним, пусть будет 3. Но нужно то бельше! От того что в конфиге описано обльшее количество режимов безопастность не страдает. Если господин Раскин хочет безопастности пусть предоставит безопастный api для задания режимов а не рассказывает как всё это сложно.

kirill_rrr ★★★★★
()
Ответ на: комментарий от kirill_rrr

Очевидно расширенные настройки переключения раскладок которые тебе не нужны.

Логика уровня «дом -> табурет -> Плутон».

Если господин Раскин хочет безопастности пусть предоставит безопастный api для задания режимов а не рассказывает как всё это сложно.

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

liksys ★★★★
() автор топика
Ответ на: комментарий от liksys

Проблема возникла еще в начале нулевых, когда появились мониторы HD

HD это слегка увеличенный вбок и урезанный по высоте XGA. По состоянию на 2012 год эта проблема волновала примерно вообще никого.

Между тем, вяленда тогда еще в проекте не было.

...а когда появился, там эту проблему не могли решить больше 10 лет.

Да, кажется какие-то пляски вокруг железа.

Не только, и нет, не тестировал. Если оно не работает на амд R на GCN* + radeonsi то это безнадёжно. В линуксах просто нет более качественных дров.

Суть была в том, что гтк3-приложения в кде начинали шакалить шрифты или мылить виджеты стоило чуть потрогать настройки масштабирования, шрифтов или мониторов. Более-менее адекватно работая лишь в 100% и 150% или 200%.

kirill_rrr ★★★★★
()
Последнее исправление: kirill_rrr (всего исправлений: 1)
Ответ на: комментарий от kirill_rrr

HD это слегка увеличенный вбок и урезанный по высоте XGA.

XGA - это 1024x768, а HD - 1920x1080. Это не слегка, по горизонтали это почти в два раза больше. И по вертикали где-то на треть.

По состоянию на 2012 год эта проблема волновала примерно вообще никого.

Если ты сидел в 2012 году на 1024x768 - это не значит, что у остальных людей были точно такие же допотопные дисплеи.

В линуксах просто нет более качественных дров.

То есть проблема всё-таки была с дровами.

Более-менее адекватно работая лишь в 100% и 150% или 200%.

Ну дык лол. В гноме просто приколочен шаг масштабирования, а кеды позволяют его менять более плавно. Но проблема в том, что плавный ход масштаба (как и плавное изменение DPI, кстати) будет приводить к мылу, если у тебя не будет какого-то целого или полуцелого соотношения пикселей. Типа, рисовать один пиксель в четырех квадратом - мыла не будет. Один в полутора - терпимо, потому что соседние полтора дополнят картинку. Остальные дроби будут давать неравномерное разбиение. Эту проблему вообще никак не решить, только увеличением разрешения дисплея.

liksys ★★★★
() автор топика
Последнее исправление: liksys (всего исправлений: 1)
Ответ на: комментарий от shdown

Но в swaybar нет полноценной поддержки трея.

Выпилили чтоль?

kneedeep
()
Ответ на: комментарий от liksys

а HD - 1920x1080.

У здоровых людей 1920x1080 это fullHD, а HD это 1280х720. SD это 480р, а низкое качество это 360р и ниже.

То есть проблема всё-таки была с дровами.

Да, кде не осилили совместимость с дровами... Практически ни с какими дровами. У самих дров нет проблем с работой на этом железе.

В гноме просто приколочен шаг масштабирования

Ну так и где вменяемое масштабирование в вайланде, если половина вайланд-клиентов работает через жопу.

Но проблема в том, что плавный ход масштаба (как и плавное изменение DPI, кстати) будет приводить к мылу,

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

Остальные дроби будут давать неравномерное разбиение.

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

Эту проблему вообще никак не решить, только увеличением разрешения дисплея.

Именно поэтому она решена на 90% в кде6-вайланд? Там есть мыльцо, но это недоработка разработчиков а не принципиальные недостатки.

kirill_rrr ★★★★★
()

Я немного не пойму. Тебе не хватило всех тех простыней текста, что ты выдал под новостями про Xlibre чтоль? А то непонятно вообще, зачем нужно было вообще вот это всё постить, если ты сам писал в своё время, что тебе в целом всё равно, кто, и чем пользуется. Я понимаю, что побайтить, это дело святое, но честно, ты уже как-то заббал с этой темой.

Minerva
()
Последнее исправление: Minerva (всего исправлений: 1)
Ответ на: комментарий от Minerva

Я же написал в посте. Скрины - шедевр, который не хочется терять.

На самом же деле это просто наглядная демонстрация. Когда с тобой спорят про гуи - просто попроси собеседника показать свой десктоп. И если там будет что-то подобное скринам, диалог можно больше не продолжать: у человека нет ни вкуса, ни чувства эстетики, ни знания матчасти по графике, и он банально не понимает, о чем ты с ним говоришь.

liksys ★★★★
() автор топика
Последнее исправление: liksys (всего исправлений: 1)
Ответ на: комментарий от Minerva
...если отвечаешь одержимым
То вы сразу неотличимы
macrohard ★★★
()
Ответ на: комментарий от bloody_enterprise

Есть морды к mpv.

Есть. Выкинул. Потому как божественный mpv будучи завернут в богомерзкую морду начинает жрать ресурсы не меньше какого-нибудь vlc.

Qui-Gon ★★★★★
()
Ответ на: комментарий от liksys

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

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

Qui-Gon ★★★★★
()
Ответ на: комментарий от Qui-Gon

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

bread
()
Ответ на: комментарий от bread

Произвольно крутить DPI нельзя.

Как говорят в народе - умеючи можно и.. лингам сломать. Поэтому крутить надо настолько насколько нужно. По крайней мере в моем мате десктопе переход на вейланд с икса ничего особо не поменял - все регулируется ровно тем же самым. Но беда в том что каждый тулкит да еще и каждый клиент вносит свои коррективы ибо по своему интерпретирует настройки. Скажем я сижу на мате и все что касается gtk3 шоколадно-вафельно отрабатывется настройками мате - а вот с QT приходится отигрывать переменной QT_FONT_DPI. И тут тоже - какое-то приложение позволяет менять шрифты в настройке и там эта настройка нафиг не нужна, а какое-то хардкодится на какую-нибудь сраную 10 или 8 в фонте и там только так.

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

Но это все понемногу уходит в прошлое вместе с убогими FHD и меньше экранами.

Qui-Gon ★★★★★
()
Ответ на: комментарий от Qui-Gon

Не будет. Интерфейсы нарисованы таким образом, чтобы соответствовать определенному стилю. При увеличении шрифтов всё разъезжается. При этом часть элементов не масштабируются в соответствии с DPI - в частности, иконки, как на сабжевых скринах. Мне все равно на проблемы гнома, но даже в кедах этот эффект будет заметен.

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

Нет, всё ровно наоборот. В вяленде параметр масштабирования передается прямо в приложение, и приложение применяет масштаб до рендеринга, поэтому никакого мыла нет. А то, что ты описал - это работа масштабирования в иксах (если быть точным, то xrandr --scale индивидуально на экран). Иксы масштабируют картинку после рендеринга, отсюда и мыло в иксах.

Параметр же DPI в иксах общий на все мониторы. При большом везении твои мониторы одинаковы (или он у тебя один), но тулкиты не опираются на DPI как на универсальную метрику масштаба.

liksys ★★★★
() автор топика
Последнее исправление: liksys (всего исправлений: 2)
Ответ на: комментарий от Qui-Gon

Все современные тулкиты умеют это делать. Берешь любое приложение на Qt5+ или GTK3+ - и оно будет это уметь, причем без привязки к конкретному композитору. Если тулкит заявляет поддержку fractional scale, то оно будет работать так, и никак иначе.

А если не умеет - композитор, внезапно, ничего масштабировать не будет. По идее, тут зависит от композитора, но вот как ведут себя кеды: https://i.ibb.co/B2Gy241m/image.png

Короче, описанной тобой проблемы не существует.

liksys ★★★★
() автор топика
Ответ на: комментарий от liksys

В иксах один глобальный DPI прибит гвоздями к серверу. Проблема возникла еще в начале нулевых, когда появились мониторы HD, и ее так и не смогли нормально решить.

Когда во второй половине нулевых FullHD-мониторы стали более-менее распространены, проблему решили (как уже здесь упоминали):

https://wiki.debian.org/XStrikeForce/HowToRandR12

С 21 августа 2007 года RandR 1.2 (DPI per Monitor) в Debian Testing.

Напомню, (без двух недель) ровно год назад: XLibre 25.0 -- первый выпуск форка X.Org Server (комментарий).

gag ★★★★★
()
Последнее исправление: gag (всего исправлений: 1)
Ответ на: комментарий от kirill_rrr

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

liksys ★★★★
() автор топика
Последнее исправление: liksys (всего исправлений: 4)
Ответ на: комментарий от gag

проблему решили (как уже здесь упоминали)

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

liksys ★★★★
() автор топика
Ответ на: комментарий от Ololo_Trololo

По моему они наоборот это и принесли, им его не надо.

daniyal
()
Ответ на: комментарий от liksys

Как уже сказал, год назад приводил ссылку: https://flak.tedunangst.com/post/forbidden-secrets-of-ancient-X11-scaling-technology-revealed

Человек сел, написал маленькую программку для теста. Хотел, чтобы радиус окружности был один дюйм в независимости, на каком мониторе отображается окно. Для неверующих приложил линейку прямо к экрану.

Т.е. продемонстрировал, с какой лёгкостью тулкит может масштабировать рендеринг в зависимости от DPI конкретного монитора. И всё благодаря RandR 1.2, который стал отдавать настоящие физические размеры монитора (получаемые из его EDID), из которых и вычисляется реальный DPI.

gag ★★★★★
()
Ответ на: комментарий от gag

Как уже сказал, год назад приводил ссылку

Как я уже сказал, это не является решением проблемы. Именно поэтому этот вброс оказался никому не интересен. На твою ссылку я приведу ссылку, в которой детально разбирается происходящее, ознакомься: https://lobste.rs/s/ceylzx/forbidden_secrets_ancient_x11_scaling

Человек сел, написал маленькую программку для теста… Т.е. продемонстрировал, с какой лёгкостью тулкит может масштабировать рендеринг в зависимости от DPI конкретного монитора.

Между рисованием простой окружности и рисованием целого интерфейса - огромная пропасть. Какая именно - разбирается по моей ссылке выше.

liksys ★★★★
() автор топика
Последнее исправление: liksys (всего исправлений: 1)
Ответ на: комментарий от liksys

Как я уже сказал, это не является решением проблемы.

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

gag ★★★★★
()
Ответ на: комментарий от gag

Да я уже обрисовывал ее. Это пост, который игнорируется всеми иксофанбоями:

Давай лучше ты скажешь мне, как в иксах решить следующую проблему: у меня есть два монитора: один 4K, второй 1080p. Диагональ монитора 1080p немного меньше, чем у 4K. Я хочу, чтобы интерфейс на мониторе 4K отображался с двухкратным увеличением, а на мониторе 1080p увеличения быть не должно. Естественно, не должно быть мыла, лесенок и прочих радостей.

liksys ★★★★
() автор топика
Ответ на: комментарий от liksys

Иксы масштабируют картинку после рендеринга, отсюда и мыло в иксах.

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

gag ★★★★★
()
Ответ на: комментарий от gag

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

Не получает и не использует.

Во-первых, DPI != масштабирование. Цитирую себя же: DPI - это количество пикселей в дюйме. Берем текстовый процессор. У него есть страница A4 контента и элементы интерфейса. DPI монитора должен соответствовать реальности, чтобы виртуальный дюйм совпал с реальностью при распечатке страницы. Если интерфейс выглядит слишком маленьким, тебе нужно его отмасштабировать. Ты меняешь DPI монитора, и получаешь потерю соотвествия масштаба контента реальной странице A4.

Во-вторых, не существует единого консенсуса о том, как X-клиентам следует интерпретировать показания DPI, полученные от иксов.

Как я уже говорил: Сжатие в сетевой прозрачности иксов можно сделать расширением, но никто не сделал. Индивидуальное дробное масштабирование на дисплей можно сделать, но никто не сделал. Починить фундаментально окна, чтобы хоткеи в системе монопольно не перехватывались открытым меню можно, но никто не сделал. В иксах всё можно сделать. Все расширения простые, всё можно исправить, но никто не сделал. Потому что если чего-то нет в иксах - то это нинужно.

liksys ★★★★
() автор топика
Последнее исправление: liksys (всего исправлений: 1)
Ответ на: комментарий от liksys

Не получает и не использует

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

Во-первых, DPI != масштабирование.

Поэтому я не говорил, что DPI монитора нужно менять.

Ты меняешь DPI монитора, и получаешь потерю соотвествия масштаба контента реальной странице A4.

Это может быть важно при предпросмотре документа (но, например, увидеть A2 целиком на 24" всё равно не выйдет). В остальных случаях важнее, чтобы было просто хорошо видно.

В иксах всё можно сделать. Все расширения простые, всё можно исправить, но никто не сделал.

Всегда есть конкретные причины. Проблема в том, чтобы их узнать. Потому что то, что публично озвучивают всегда может быть отговоркой/оправданием, а не реальной причиной (которая может быть коммерческой тайной корпорации).

gag ★★★★★
()
Ответ на: комментарий от gag

В примере продемонстрировали

Помимо примера (сферического, в вакууме, и по полочком разобранного по моей ссылке), не продемонстрировано ничего. Иксы существуют 35 лет. Проблема масштабирования актуальна последние 15 лет. Пока вяленд был спорной игрушкой, а иксы активно развивались, решения в них так и не было предоставлено. Поэтому я говорю: в реальности тулкиты не используют эту информацию. Более того, они не знают, как ее нужно использовать, и не могут использовать настолько эффективно, как с вялендом. Я еще раз советую тебе прочитать вышеприведенную ссылку.

Поэтому я не говорил, что DPI монитора нужно менять.

Если DPI не нужно менять, то у тебя не остается способов изменить масштаб в иксах поэкранно. Возвращаемся к необходимости fractional scaling, который реализован в вяленде.

Это может быть важно при предпросмотре документа

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

которая может быть коммерческой тайной корпорации

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

И я еще раз возвращаюсь к моей проблему:

у меня есть два монитора: один 4K, второй 1080p. Диагональ монитора 1080p немного меньше, чем у 4K. Я хочу, чтобы интерфейс на мониторе 4K отображался с двухкратным увеличением, а на мониторе 1080p увеличения быть не должно. Естественно, не должно быть мыла, лесенок и прочих радостей.

Ну? Будут какие-то практические советы по иксам, а не пустые теоретизирования? Вяленд прямо сейчас проблему решает. Иксы - нет, и никогда не могли.

liksys ★★★★
() автор топика
Последнее исправление: liksys (всего исправлений: 7)
Ответ на: комментарий от liksys

по полочком разобранного критиками

Кроме обычной дискуссии ничего конкретно сформулированного пока не заметил.

Пока вяленд был спорной игрушкой, а иксы активно развивались, решения в них так и не было предоставлено.

Вэйленд запустили в разработку вскоре после релиза RandR 1.2. Зачем улучшать тулкит сегодня, если вот-вот уже завтра будет совершенно новый «лучший» протокол? Довольно типично, к сожалению.

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

Не вижу как.

интерфейс на мониторе 4K отображался с двухкратным увеличением

Интерфейс - это что конкретно: всё наполнение окна или нет?

И с двукратным увеличением по отношению к чему?

gag ★★★★★
()
Ответ на: комментарий от gag

Кроме обычной дискуссии ничего конкретно сформулированного пока не заметил.

Конкретика начинается буквально с первого комментария. Плохо читал, иди перечитывай.

Вэйленд запустили в разработку вскоре после релиза RandR 1.2.

Дежурно напоминаю, что иксы продолжали активно развиваться даже после запуска разработки вяленда. Что же касается тулкитов, то твоя теория заговора разбивается о банальный Qt: он развивался независимой сторонней компанией, и продолжал совершенствоваться всё это время. Им было наплевать на эти терки разработчиков вяленда с иксами, им нужно было, чтобы всё просто работало. Вот только Randr 1.2 не решал и не решает проблему масштабирования: его там нет, а DPI всё еще один на весь сервер.

Не вижу как.

Слева экран 100x100 пикселей. Справа экран 200x200 пикселей, который хочет масштабирование x2, чтобы работать как 100x100. Для приложений появляется относительная система координат: нужно ли при переходе с левого окна в правое продолжать считать в пикселях, или считать в неких юнитах, которые представляют собой квадрат 2x2 пикселя? А если наоборот? А как приложению позиционировать свое окно, по относительной сетке монитора, или по абсолютной? Что считать абсолютной сеткой - натуральную пиксельную, или виртуальное после машстаба? А элементы как позиционировать внутри окна?

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

Интерфейс - это что конкретно: всё наполнение окна или нет? И с двукратным увеличением по отношению к чему?

Всё содержимое монитора. Например, панель задач у меня в кедах на мониторе 1920x1080 занимает 20 пикселей в высоту. Шрифты подобраны соответственно. Рамки окна, весь дизайн интерфейса подогнан для 1920x1080. На 4k я хочу просто зум относительно того, как это срендерено в пикселях на 1920x1080. То есть 40 пикселей панель, шрифт в два раза больше, скругления пропорциональные и так далее.

В иксах существует ровно два способа сделать это. Способ первый: рендерить интерфейс в 1920x1080, и на втором мониторе апскейлить его до 4k - получится тот масштаб, который мне нужен, но в жутком мыле, потому что xrandr --scale делает апскейл ПОСЛЕ рендеринга. Способ второй: Подогнать DPI таким образом, чтобы на 4K всё рендерилось в нужном мне масштабе, после чего снова использовать xrandr --scale для достижения нужного масштаба на мониторе 1920x1080, и получить лесенку с выкинутыми пикселями.

If you are using «–scale 0.5» you send one frame-buffer-pixel to four real pixels, and it adds a bilinear filter making it blurry. If you are using «–scale 2» you render 4 frame-buffer-pixels for one physical pixel, leading to (1) an useless overload the graphics card and (2) because of the bilinear filtering it is blurry and worsens the result. With –filter nearest you can avoid the blurriness, however the result is much better, but still unacceptable for reading fonts or graphics design.

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

При этом вяленд никакой особой магии не делает, помимо правильно расставленных соглашений о том, как те или иные вещи должны работать. Просто протокол разработан с учетом опыта иксов. Во времена иксов никто не предполагал, что что-нибудь понадобится масштабить и у нас будут настолько большие разрешения, как 4K и 8K. И скейлинг в иксах - это буквально костыль, чтобы хоть как-то жить с единой координатной сеткой.

liksys ★★★★
() автор топика
Последнее исправление: liksys (всего исправлений: 4)
Ответ на: комментарий от liksys

Вот только Randr 1.2 не решал и не решает проблему масштабирования: его там нет, а DPI всё еще один на весь сервер.

Один на весь сервер — это значение ресурса Xft.dpi. Это не специальный протокол, это соглашение между тулкитами.

С появлением RandR 1.2 можно было выработать соглашение для per-output dpi. Но тулкиты его не выработали. А виноватым теперь называют «иксы».

iliyap ★★★★★
()
Ответ на: комментарий от iliyap

С появлением RandR 1.2 можно было выработать соглашение для per-output dpi.

Нельзя, RandR с DPI никак не связан и никак бы ему не помог. Идем на сайт X.org и читаем всю имеющуюся там информацию про RandR, проверяя каждую ссылку. Смотрим спецификацию RandR 1.2 - ноль упоминаний DPI. Смотрим самую свежую - 1.6 - и снова ноль упоминаний DPI.

Один на весь сервер — это значение ресурса Xft.dpi. Это не специальный протокол, это соглашение между тулкитами… А виноватым теперь называют «иксы».

Причину, по которой отдельного DPI на дисплей так и не завезли, я обяснял в предыдущем посте - потрудись перечитать его внимательно. Иксы не обеспечивали должного уровня гибкости на уровне протокола.

liksys ★★★★
() автор топика
Последнее исправление: liksys (всего исправлений: 2)
Ответ на: комментарий от liksys

Да не нужна там особая поддержка dpi. Xft.dpi это же просто именованный ресурс, а не специальная поддержка. Можно было бы использовать именованные ресурсы, например, HDMI-1.dpi и LVDS-1.dpi. Либо можно использовать именованные свойства видеовыходов, появившиеся в RandR 1.2, например с именем DPI у каждого видеовыхода. Нужно просто соглашение между тулкитами, сервер уже поддерживает все нужное для реализации соглашения.

iliyap ★★★★★
()
Ответ на: комментарий от iliyap

Да не нужна там особая поддержка dpi.

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

например с именем DPI у каждого видеовыхода

Еще раз: DPI != масштабирование. Еще два: проблема не с DPI или масштабом, а с пиксельной сеткой.

liksys ★★★★
() автор топика
Последнее исправление: liksys (всего исправлений: 1)

Я пытался жить с этим на 5к мониторах год но в итоге плюнул и купил 32" 2к - теперь кнопки не разъезжаются и весь софт работает как и положено.
Увы, даже не дробное масштабирование по прежнему в лялихе боль если нужна Ява (она сама по себе прекрасно масштаируется но всякие костыли типа авт/свт ей что мешают) и вывод растра в нативном разрешении (в том же гимпе выводить графику в 1:1 а не 1:хз сколько сегодня ибо там то учитывается скейлинг то нет)

rukez ★★★★★
()

@mittorn у тебя есть какие-то конструктивные аргументы, помимо невероятно интеллектуальных реакций? Я весь внимание.

liksys ★★★★
() автор топика
Последнее исправление: liksys (всего исправлений: 2)
Ответ на: комментарий от liksys

На примере qt:
QT_SCREEN_SCALE_FACTORS='2.0;1.0'
ну, или если у fullhd чуть меньше диагональ - '1.9;1.0'
Ну и qt автоматически должен читать DPI из xrandr и выставлять этот фактор, опция переопределения существует для отладки:
https://qthub.com/static/doc/qt5/qtdoc/highdpi.html (проверял в qt6 - тоже работает)

mittorn ★★★★★
()
Ответ на: комментарий от liksys

Да как-то не сильно хочется что-то доказывать. Единственное что wayland здесь лучше умеет - может масштабировать отдельное окно или его область композитором. Смысла от этого немного т.к для не умеющего в масштабирование окна всё равно будет мыло. Разве что способ сделать более плавным перетаскивание между мониторами. А нормально отрендерить интерфейс с нужным DPI (или масштабом) - всё равно задача тулкита и если он этого не имеет - в иксах будет мелкое окно, а в wayland - мыло. Оба случая одинаково противны.
Смысла в отдельном (от DPI) масштабе мониторов я тоже не вижу. это просто лишняя настройка. Разве что сделать dpi float, но его целочисленность тоже никому не мешает

mittorn ★★★★★
()
Последнее исправление: mittorn (всего исправлений: 1)
Ответ на: комментарий от liksys

XGA - это 1024x768, а HD - 1920x1080

Наброс всё толще, я не верю что так легко СЛУЧАЙНО перепутать HD и FullHD

будет приводить к мылу, если у тебя не будет какого-то целого или полуцелого соотношения пикселей.

Самое глупое, что можно придумать это масштабировтаь уже отрендеренное изображение

mittorn ★★★★★
()
Последнее исправление: mittorn (всего исправлений: 1)
Ответ на: комментарий от mittorn

Отлично. Теперь сделай так, чтобы я мог перетащить приложение из монитора в монитор, и масштабирование менялось динамически. Без перезапуска приложения, разумеется. И для GTK-программ тоже.

liksys ★★★★
() автор топика
Последнее исправление: liksys (всего исправлений: 2)
Ответ на: комментарий от mittorn

Да как-то не сильно хочется что-то доказывать.

Ну разумеется, кто бы сомневался.

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

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

Смысла от этого немного т.к для не умеющего в масштабирование окна всё равно будет мыло.

Не будет. Я выше кидал скриншот с жавой: окна не масштабируются сами по себе.

liksys ★★★★
() автор топика
Ответ на: комментарий от mittorn

не верю

Твои проблемы.

Самое глупое, что можно придумать это масштабировтаь уже отрендеренное изображение

То есть то, что делают иксы.

liksys ★★★★
() автор топика
Ответ на: комментарий от liksys

В qt оно меняется динамически. То, что оно не делает этого в gtk - проблема сугубо gtk. Патч, её исправляющий можно найти в одном из тредов по ссылкам выше, но апстрим конечно же его не возьмёт, ведь зачем тогда wayland?

mittorn ★★★★★
()
Ответ на: комментарий от liksys

Я выше кидал скриншот с жавой: окна не масштабируются сами по себе.

Видимо, поведение конкретного DE. А в иных DE бывало иное (и в винде тоже)

mittorn ★★★★★
()
Ответ на: комментарий от mittorn

В qt оно меняется динамически.

Каким образом? Ты передаешь масштаб через переменную окружения.

апстрим конечно же его не возьмёт, ведь зачем тогда wayland?

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

Видимо, поведение конкретного DE. А в иных DE бывало иное (и в винде тоже)

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

в каких таких условиях иксы делают мыло, кроме случая когда их сами попросили?

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

Ну и заодно тебя тоже спрошу, а то все иксофанбои либо сбегают в ужасе, либо просто уводят обсуждение во флуд.

у меня есть два монитора: один 4K, второй 1080p. Диагональ монитора 1080p немного меньше, чем у 4K. Я хочу, чтобы интерфейс на мониторе 4K отображался с двухкратным увеличением, а на мониторе 1080p увеличения быть не должно. Естественно, не должно быть мыла, лесенок и прочих радостей.

Я готов использовать иксы, если кто-то предложит мне решение моей проблемы прямо сейчас ^ Ну?

liksys ★★★★
() автор топика
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.