> Блин, вы бы подписывались, что-ли. Если вы - аноним с осциллографом (без
> стрелки :-), то вам лучше бы взять не Х, а что-то проще, типа DirectFB.Вы знаете, у меня нет планов превращать 8-ядерный компьютер с большим монитором в однозадачный "осциллограф" :). Нечто подобное логично смотрелось бы отдельной прожкой в отдельном окошке, где-то сбоку, до кучи. Желательно с нормальными контролами и прочая. Вы что, никогда подобный софт не видели?
Иксы будут тормозить рисовать мало-мальски крупную битмаповую картинку в состоянии по дефолту. С точки зрения написания программы меня не улыбает что я должен что-то там знать о иксах и как их изогнуть чтобы вывод через них перестал тормозить. Особенно если хочется хотя-бы какой-то портабельности программы, например.
В результате такая простая задачка по простому оказываетс не решается. Я или должен для получения нормальной скорости юзать нечто типа SDL, получив таки нечто типа "кроссплатформенного фреймбуфера" (писать заведомо непортабельные программы без веской причины - нехорошо!). Но тогда я окажусь без нативных виджетов из тулкитов и их теминга. Или я могу юзать графический тулкит, но без расстановки кастомных костылей лично иксам - оно на *никсах будет волшебно тормозить. А ставить костыли конкретно иксам - это дополнительная работа и к тому же не портабельно. Программа получится коллекцией костылей. Ну, в тулкитах конечно есть поползновения все больше и больше добра перетянуть на OpenGL, он кроссплатформенный и не тормозит сразу, "по умолчанию". Но для столь простой задачки это пальба из базуки по мухам.
>> 2) В любом случае в DE должен быть графический конфигуратор этого самого.
> Ну да, желательно, но скорее не DPI, а коэффициент масштабирования интерфейса.
Так DPI по сути и является этим коэффициентом. Как по мне - проще всего крутить именно его, особенно если совпадение с точностью до микронов картинки на мониторе с реальными физическими размерами не волнует. А учитывая что матрицы мониторов пекут без особой оглядки на такие вещи (вплоть до не совсем квадратных пикселей, например, с разным соотношением сторон) - оно чаще всего как раз так и есть.
> Но по-умолчанию там должен быть DPI, выдаваемый Х, как наиболее разумный.
Если уж вы про фреймбуферы и вга вспоминаете - я вас огрею вашим же оружием. Вот есть железка. У нее туповатый фреймбуфероподобный видеоконтроллер. Он рисует по принципу "какую битмапу положили в мою память, такую я и вываливаю на экран". К нему по тупой RGB или LVDS шине цепляется не менее тупая RGB панель. Контроллер формирует ей тайминги для каждого кадра. Панель рисует. О том какой там DPI контроллер вообще понятия может не иметь. К нему вообще разные панели подключать можно. Контроллер интересует только число пикселей, не более.
Вопрос на засыпку: откуда при этом X или кто либо еще вообще DPI узнает? А поскольку DE все-таки должен работать в разных конфигурациях - он вообще не должен уповать на то что ему иксы что-то там вернут. Может быть. Если они вообще есть. И если это значение имеет какой-то смысл, а не просто какой-то левый дефолт с потолка. А вот когда у вас в DE контролы и текст такие что их с лупой смотреть надо и не дали удобную рукоятку для оверрайда, так что десятый кегль смахивает на седьмой - вот это уже печальненько получается.
>> Хотя-бы потому что в совеременных системах по умолчанию у иксов конфига вообще нет.
> Я пробовал - можно подправить, если Х некорректно определили. Писал уже об этом.
Можно. Но мне кажется что если некто вкорячивает в систему здоровый переросток с немеряными браузерными движками, JS и прочая - наверное будет логично, если вся эта переросточная хренота с рюшечками и бантиками будет позволять сделать указанную операцию. Иначе на кой хрен она место на винте занимает, если юзеру надо вручную какие-то конфиги колупать?
