LINUX.ORG.RU

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

 ,


0

4

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

Предлагаю вам отвлечься от всего мирского и вместе со мной насладиться скриншотами рабочего стола уважаемого @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 ★★★★
()
Ответ на: комментарий от no-dashi-v2

Вот это все конечно уже более приемлемо. Но зачем такие сложности? Зачем нужен какой-то виртуальный пиксель и коэффициент масштабирования?

Все нормальные люди измеряют размер шрифта в пунтках. И в X-ах он изначально задавался в пунктах. Понятно, что при 96 dpi 14 пунктовый шрифт будет рисоваться в 18 с копейками пикселях. И не каждому такое будет комфортно видеть в интерфейсе. А при 186 dpi уже 8 пунктовый шрифт будет занимать 20 с лишним пикселей. У меня например для HiDPI монитора выставлен шрифт интерфейса 9 пунктов.

Оффсеты, размеры и прочее тоже указываем в пунктах (или мм), в чем проблема? Ну можно в темах еще какой-нибудь динамический коэффициент задать. А тулкиты все рисуют в пикселях, учитывая dpi. По сути в нормальных тулкитах все это было в прошлом веке сделано. Не учли только, что можно использовать несколько экранов с разными dpi.

Вобщем то с распространением HiDPI мониторов X-ы из прошлого века с чуть более свежими тулкитами наконец-то могут нормально прорисовать и интерфейс и контент. И тут вяленд городит какие-то уродливые костыли, которые будут востребованы только, пока в небытие не уйдут убогие мониторы с 96 dpi.

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

Это, конечно, выглядит наиболее «прямым» решением проблемы. Но выглядит дико. А если в системе 4 монитора с разными dpi? Рисовать 4 одинаковых окна с учетом разных dpi?

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

Но зачем такие сложности? Зачем нужен какой-то виртуальный пиксель и коэффициент масштабирования?

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

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

Ну какие есть варианты? Либо мыло, либо кратный объем работы при прорисовке, такова се ля ви.

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

Qui-Gon ★★★★★
()

Более того. Некогда люди, работали в псевдографике и не жаловались, а теперь все довольны gui в системе.

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

но он не нужен по итогу. давно не пользуюсь

А я так думал когда экспо распробовал. Но потом понял, что за время анимации появления успевал кликнуть нужное окно на самой классической панели а-ля ХР. В большинстве случаев, не всегда конечно.

а если половина окон фаерфоксы или либреофис - то всеравно приходится открывать превьюшки

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

Зачем???

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

Или вот я открываю пакет вкладок. Могу размахнуться и положить на 4 ядра 20 вкладок на 40 потоков. Результат предсказуем? Нет, может ещё и память перегрузить и всё станет не плохо а очень плохо. На основе чего реулировать скорость их открытия?

Аналогично: запускаю длительную фоновую задачу, а то сразу несколько. Держать окно перед глазами чтобы следить за ней, или достаточно графика в прямоугольничке 20х40 в дальнем углу экрана?

сфига ли мне держать на панели какую-то графическую хрень которая сама будет жрать батарею тоолько в путь

А зачем столько? Ну 1, ну 2%... И потом, в автомбилях есть тахометр и указатеь температуры ОЖ не потому что на них нужно постоянно смотреть. Напротив, очень и очень редко. Но это важно и они просто должны быть.

Ежели что-то заглючило зашумело затупило ... и там вполне себе можно запустить htop, gputop или что там еще надо с последующим киллом.

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

даже мигающий курсор - будят графический адаптер из psr/panel replay тем самым вызывают адовый ужор и нaгрев

Только в очень плохой графической системе. Софтовый рендер и тот самый примитивный и устаревший Х11 такой хренью не страдает. Он на тех самых кортекс-А53 или атоме софтовым рендером с простыми задачами справляется эффективней чем взрослая видеокарта со всеми своими вуланами и ДжиЭлями.

А взбесить железо можно и просто подёргав мышкой если там буст такой агресивный а откат частоты медленный. Тут бороться надо не с функционалом софта а с настройками энергопотребления. Вот у меня классический cpufreq и я занизил частоту таймера и задрал порог повышения частоты. Внезапно оказывается что 300-400Мгц более чем достаточно чтобы audacity дрючил 1 полное ядро своей пляшущей полоской громкости. Нагрузка есть, но она пляшет между ядрами короткими интервалами и не превышает порога поднятия. vlc при софтовом воспроизведении 720р аналогично, 2-2,5 ядра, но на минимальной частоте!

Вот смысл во всех этих современных гибридных 24-ядерниках если простейший системный мониторчик, просыпающийся 1 раз каждые 250-500мс может превратить их в тыкву а любая древность 10-20-и летней давности вообще не видела подобной нагрузки?

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

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

И вот на этом месте ты получаешь огромные проблемы с совместимостью всего софта, что был написан до твоего соглашения. Так что увы и ах, но проблему так просто не решить - иначе за 35 лет существования иксов, и за 15 лет насущности самой проблемы, она таки была бы решена.

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

Это проблема тулкитов, не дисплейного сервера

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

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

Вполне себе впилось. Даунскейлить в два раза из 3x это лучше, чем мылить из 1x в 1.5x.

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

Подозреваю, что виртуальные пиксели там потому, что понятие «пункт» программистам обычно неизвестно. Я вот только сейчас посмотрел в википедию и обнаружил, что пункт это условная единица высоты, в разное время и в разных странах менявшаяся между 0.3473 и 0.3759 мм. Субмикронная точность, конечно, удивляет, особенно учитывая что началась эта история в 18 веке, подозреваю что последние две цифры туда приписали уже задним числом, когда оценивали историческую величину уже спустя 150-200 лет. А так же удивляет то что попытка замены этой величины с 0.3759 на 0.3750 почти 100 лет назад столкнулась с некими проблемами. Казалось бы, кого может волновать изменение высоты букв на 1/100 мм (для обычных шрифтов которые порядка 10 пунктов, или на 1мм для букв высотой в 37см).

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

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

В html/css эту проблему давно решили четверть века тому назад - приходится лишь мириться с дробными пикселями. В qt6 используется аналогичный подход и они портируются на кучу устройств. GTK всю историю пытался косплеить винду с ее целочисленной арифметикой, создавая нормальным людям проблемы на ровном месте и перекладывая их решение со своей больной головы на здоровые.

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

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

Мне оно как раз известно. Но оно привязано к физическому размеру, что не всегда хорошо.

no-dashi-v2 ★★★★
()

Красота в глазах смотрящего. Мои глаза перестали видеть после этого…лдвоадоавдлавл

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

Предъявите определение пожалуйста

Красота — это эстетическая категория, означающая совершенство, гармонию и гармоничное сочетание качеств объекта, которые вызывают у наблюдателя чувство эстетического наслаждения

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

Красота - это вполне практическая и довольно точная эволюционная настройка. Те кому казалось красивым бесполезное или вредное - вымерли. Те кому не казалось красивым полезное - вымерли.

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

Гармония, эстетика и всякая метафизика тут вторичны. Так пытаются дать определение явлению те, кто не понимают о чем оно.

LightDiver ★★★★★
()
Последнее исправление: LightDiver (всего исправлений: 2)

В Wayland приложение вообще может получить DPI экрана, на котором отображается?

Допустим, у меня есть условный LibreOffice Writer, в котором отображён лист бумаги. У LO Writer вообще есть шанс отобразить этот лист так, чтобы ширина изображения листа на экране в миллиметрах соответствовала реальной ширине листа в миллиметрах? Или сиди гадай, какой масштаб в реальности соответствует 100%?

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

Вот у меня классический cpufreq и я занизил частоту таймера и задрал порог повышения частоты. Внезапно оказывается что 300-400Мгц более чем достаточно чтобы audacity дрючил 1 полное ядро своей пляшущей полоской громкости. Нагрузка есть, но она пляшет между ядрами короткими интервалами и не превышает порога поднятия. vlc при софтовом воспроизведении 720р аналогично, 2-2,5 ядра, но на минимальной частоте!

Ты подходишь к энергобережению технологиями прошлого века, на как нвидия прям. Минимальная частота жрет тоже овердохрена. Для максимального сбережения нужны глубокие C-states - то есть по сути обесточивание определенных узлов ядра и обвязки. Чем больше обесточишь - тем меньше оно будет жрать, но тем больше тебе потребуется вкачать в это ядро если ты решишь разбудить его снова. Плюс временной лаг - тебе понадобилось ядро - его надо включить, активировать кэш, и через какое-то время оно будет готово к работе. И зачастую выгоднее разбудить ядро на какой-то не минимальноя частоте, быстро обсчитать задачу и отправить его обратно в C10 чем стабильно кочегарить его на минимальной частоте но в состоянии C0. А с современными 24 ядерниками надо еще разабраться какое из ядер использовать - а тут уже у линукса все достаточно х-во. С арм все как раз более-менее, там изначально были кластеры ядер разной производительности и жручести - да и сами процы арм всеже ориентированы на линукс а не на венду - и все относительно неплохо. Ну а поделки интеля склёпанные по быстрому на коленке от полной безисходности работают пока отвратно - тут да, не поспоришь. Но дело опять же не в частоте, а в том что интеловский little-big (а затем и амд-шный) - по сути маркетологический высер,мол вот мы сделали экономичный процессор на 20 часов батареи (в реальности 6) потому что там есть энергоэффективные ядра. Ну да - на практике ОС будет крутить ваши задачи в основном на больших - но они там есть зуб даем.

Но в общем-то наверное если заморочиться то можно через cgroup закинуть твои коньки и мониторы на самые кастрированные LP ядра интела или на младшие кортексы в арм и заставить их эксклюзивно крутиться там - но по мне так проще не держать бяку вообще.

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

В Wayland приложение вообще может получить DPI экрана, на котором отображается?

Разумеется.

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

А в чём смысл это обсуждать, если для каждого человека это вопрос того, что он вообще хочет от системы? Тем более если он его вообще использует в ней DE или даже ту же графику, а не сидит туи тыкает. Тут так много пресловутого «но», что я даже расписывать это не хочу. Суть моей претензии в том, что ты транжиришь слишком много текста для человека которому «всё равно/плевать на фанатиков иксов». Даже тред с прогоном тут отдельный завёл. Всё что я вижу, это чистое желание потыкать лишний раз клавиатуру на тему того, какое Иксы УГ, и что определенные люди не правы, ведь они смеют иметь другое мнение. Я бы понял, если бы это делалось с определенной систематикой, с целью показать развитие Вяленого, и тд. Лишний раз даже снобство можно было бы потерпеть, а так, весь тред просто ни о чём вообще.

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

«всё равно/плевать на фанатиков иксов»

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

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

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

Ты подходишь к энергобережению технологиями прошлого века, на как нвидия прям. Минимальная частота жрет тоже овердохрена. Для максимального сбережения нужны глубокие C-states

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

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

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

Непоняно почему засыпание должно быть долгим, трудным и очень энергозатратным процессом и что мешает к ультрасложному ядру с огромными кешами прикрутить сбоку микроскопическое скалярное in-order ядро-дублёра на 10К транзисторов, эффективное в дежурном режиме порядка 50Мгц и способное работать месяцами от пальчиковой батарейки. В конце концов почти никто не пишет софт для работы с регулярными глубокими С-состояниями.

а затем и амд-шный

АМД хитрые, они смогли придумать такой little-big, что он вообще не little-big. Есть логически совершенно одинаковые ядра, только одни оптимизированы для более низких частот и тупо не разгоняются до высоких, а другие для высоких и ловят на себя задачи как только разгонятся. Всё это неплохо работает методом естественной сортировки планировщиком-дураком из прошлого века.

но по мне так проще не держать бяку вообще.

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

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

Нет, не вызывает. Оно (точнее, они - «скриншоты») может быть скучным, уже надоевшим и однообразным. Но вот твой скриншот при просмотре требует закрыть его поскорее. Если ты это не видишь и до сих пор продолжаешь настаивать, что всё с ним всё ок - у тебя проблемы.

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

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

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

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

Это психическое, лечиться надо.

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

А по мне - проще взять незамороченный процессор где всё просто работает даже если это много ест в режиме простоя и не показывает ААА-производительности,

Только незамороченные процессоры жрут и греются. Замороченные сильно лучше.

АМД хитрые, они смогли придумать такой little-big, что он вообще не little-big.

Они сделали правильный little-big - как на арме. Процессоры логически одинаковые под одинаковую систему команд, просто одни литл другие биг. Разница как я понимаю в основном в размере кэша и количестве юнитов распараллеливающих инструкции. Ну как в арм собственно. А интел сделали как дебилы - они сделали биг ядра с поддержкой avx512,а литл - без оной. Понятно что ОС в общем случае ни х-м ни рылом с какими инструкциями скомпилированы твои приложения - а отправка avx512 кода на литтл ядро гарантирует дамп illegal instruction, поэтому интел сделав это говно не придумал ничего лучшего как запретить инструкции avx512 на биг ядрах но саму хардверную реализацию сохранил - она там есть, она жрет транзисторный бджет и гадит - но использовать ее нельзя. И это до сих пор так - не знаю как там с пантерлейком правда может уже выравнялись но не уверен.

Вторая тупорылость интелов - они сделали LP ядра. Идея классная - у тебя есть ядра на uncore - то есть по сути ты можешь полностью обесточить все кроме uncore и эти дохленькие ядрышки будут обеспечичать твои хардверные прерыания и в общем позволять твоему компу в реальном простое жрать минимум. НО!!!! при этом у интела есть концепт boot-CPU. Это тот CPU который нельзя заоффлайнить потому что на него всеми биосами и кртвосами вешается управление прерываниями и всем вот этим - и это гвоздями прибитое ядро 0. То есть мть вашу - жручее P ядро, и это никак нельзя переназначить. То есть одни инженеры придумали как сделать офигенно автономную вещь - но клуб дебилов помножил на ноль их усилия.

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

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

Да - тут очень вдохновляли вести про чудесный пантерлейк который как лунар но только лучше. Почитал отзывы владельцев Xiaomi Book Pro 14 2026 на пантере - маркетологи интела как всегда врут, и преуспели только в искусственных тестах. По факту пантера живет в реальных сценариях ну чуть-чуть лучше arrow - ну ровно на столько на сколько позволяет улучшенный техпроцесс транзисторов. Архитектура - такое же говно.

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

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

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

Ну дизайнеры и маркетологи - это наши любимые говноеды. Но тут какбы все немного не в том - скорее те кто гвоздями прибил эту адвайту и материал дизайн к г(ов)ному и не позволяет более это убожество менять. Дефолт надо сказать и во времена гнома 2 был весьма убог - но gnomelook.org позволяло внестти в эту серость и убогость немного красоты. Но - no more. Жричодали и нахваливай.

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

Еще раз: проблема в гтк.

Ну да, у вайланда то проблем нет, он же не софт. Все проблемы у пользоватлей.

его попатчить, проблема исчезнет.

Но его разумеется никто не пропатчит.

Потому что от моих слов «не тормозит»

Ответь на 2 простых вопроса: у тебя андроид рисует анимации между действиями, например конкретно анимацию появления контуров кнопки при нажатии на неё в системном приложении «настройки»? Да/нет. Если да, то скажи, ожидание этой анимации длительностью в полсекунды это тормоза или нет?

Ты снова врёшь

Всё работает кросскомпозиторно и для каждого композитора приложение не должно изобретать уникальную логику мусштабирования.

А вот здесь я попросил тебя перечислить фичи

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

потому что мы с тобой насчитали целых 13%

Это глобально!!! ПРИНЦИПИАЛЬНО!!! На фоне этого не имеет никакого значения то что ты в очередной раз натянул сову на глобус откопав редкой маргинальности экран, отсутствующий в продаже даже на авито, не то что новый.

Да, от хреново распечатанных текстов и плохих печатных шрифтов напрягаются глаза. С подключением.

Сходи к окулисту. У 99% населения в последние 8000 лет с этим не было никаких проблем.

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

Это техническое. После 2003 года любой дизайн должен заменяться на любой другой в 3-4 клика на любых микроконтроллерах с хотя бы 128Мб оперативной памяти. Это не просто, это проще чем прибить всё гвоздями.

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