LINUX.ORG.RU

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

 ,


0

2

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

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

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

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

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

★★★★

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

И в чем проблема? Ты говорил про мультикультурность. Я тебе ответил, что Qt6 и GTK4 работают. Другие тулкиты поддерживают целочисленное масштабирование, как GTK3. Проблемы со стороны вяленда нет от слова совсем.

liksys ★★★★
() автор топика

Заголовки окон не должны быть мельче оконного шрифта … ну, хотя бы одного размера тогда уж, но не мельче. Шрифт большого размера в окне с мелким шрифтом в заголовке окна смотрится адски вырвиглазно. Такими настройками шрифтов можно пытать эстетов)).

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

Не использую всратый gtk4. Только gtk3. Вопрос снят?

И да - gtk3 использует мозилла, либреофис, гимп, кикад и еще куча софта. Кусок говна гтк4 - только г(ов)ном. Поэтому не вижу ну ровно ни одной причины переходить на гтк4. Даже разарабы моего любимого wayfire перейдя на gtk4 не убедили - форкнул на момент перехода и пилю свое. Для себя.

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

Вопрос снят?

Нет. GTK3 умеет в масштабирование, но целочисленное. Ему помогает композитор.

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

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

Что такое масштаб в данном случае? Если это dpi экрана, то сделать такое же в X11 не проблема. Я даже не уверен, что это уже не сдалано в каком-нибудь расширении (не слежу за этим). Тем более тулкиты все уже умеют.

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

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

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

zloy_starper ★★★
()

В этих фото прекрасно всё!

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

Ну если тормозит - это всегда можно посмотреть, но зачем это всегда в онлайне держать

Это как индикатор на панели авто, лучше онлайн видеть состояние, чем перегреть машину(в случае пк – посадить аккум)

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

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

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

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

мне не нужно - нативное 3к на экране 14 ноута, нативное 4к на 16" мониторе - идеально. Ну да - прищлось купить 4К монитор вместо древнего FHD. Но зрение дороже - врачи и операции сильно подорожали…

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

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

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

А что там читать, это же основы компьютерной графики.

Есть виртуальный «дисплейный пиксель», называем его dp.

Есть физический размер в пикселах экрана - его называем px.

Объявляем что 1dp == 1px в разрешении 100dpi.

Весь интерфей - оффсеты, размеры - указываются в dp.

K - коэффициент масштабирования, равен DPI экрана / базовый DPI.

И дальше все тривиально - при прорисовке пиксмапа (X, Y)dp пиксмап скалируется до (XK, YK)px. При рендеринге шрифта размер шрифта 15dp скалируется до физического размера 15*K px. При определении размера окна в котором идет прорисовка физический размер окна (X, Y) приводится к виртуальному размеру (X/K, Y/K)

Предположим у нас HiDPI экран 3000x2000px и фактическое разрешение 250dpi. Тогда окно имеет размер 1200x800dp, пиксмап 80x80 превращается в 200x200 экранных пикселов. Шрифт высотой 12dp превращается в 30px, отступ в 5dp преващается в 12px, линия толщиной 1dp прверащается в толщину 2px (ну или 3px), ну а векторный ассет который нужно срендерить в 128x128dp рендерится в 320x320px. И никакие отступы больше не плывут, картинки всегда одного и того же размера относительно текста и т.д.

Это элементарно, Ватсон (ц) - как уже сказано, основы компьютерной графики, всё давно рассказано отцами-основателями, может быть спокойно сделано в тулките - и никакой помощи от дисплейного сервера не нужно. Ну и для улучшения рендеринга растровых ресурсов пиксмапов их ресурсы можно сделать в нескольки размерах, например под 100, 200 и 300dpi и при рендеринге выбирать для скалирования тот пиксмап, который наиболее хорошо подходит для выбранного dpi.

Так что увы и ах - dpi единственная важная метрика.

no-dashi-v2 ★★★★
()
Ответ на: комментарий от zloy_starper

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

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

И в иксах, и в вяленде ты можешь крутить DPI, но влиять это будет только на шрифты

Это проблема тулкитов, не дисплейного сервера (если говорить про дисплейные серверы которые работают по минимуму ожидая от клиентов только пиксмапы). Если сервер умный и отрисовывает команды выскооуровневые, то тулки должен отправлять команды в физических размерах, которые расчитываются исходя из DPI и исходного «базисного» размера.

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