Текущее устройство ф.0 позволяет отключать заливку окна (C = 1 - не закрашивать рабочую область при отрисовке окна), т.е. рисуется внешняя рамка и заголовок. Это сделано было с целью убрать моргание (blink) появляю щееся при последовательной отрисовке фона, а поверх него отличающиеся по цвету элементы. Способность полезная, спору нет, однако, имеется недостаток - программисту приходится самому вычислять все пустоты между элементами (кнопки, боксы, бары...) и заливать их ф.13. Получается куча лишних действий и кода, и так в каждой программе.
У меня уже давно идея вертелась в голове - указывать таблицу прямоугольных областей пустот, где фон не должен отрисовываться. Т.е. такой список в каждой строке которого хранится четыре элемента, описывающих крайние углы области пустоты (верхний левый, верхний правый, нижний левый, нижний правый). Опция может включаться флагом, например, можно выбросить градиентную заливку, которую по факту ни одна программа (кроме SETUP) не использует. Указателем на структуру с областями пустот будет служить ESI.
Естественно, при каждом изменение размера окна, эту структуру придется обновлять, но это несложно, так как размеры и расположение для "резинового" окна приходится все равно вычислять. Области пустот могут пересекаться. При заливке фона, перед тем как залить очередной пиксел, код пробежится по этому списку, если координаты будут находиться за пределами описанных областей пустот, то пиксел будет отображен, в противном случае место останется не тронутым, с расчетом на последующую отрисовку пользовательскими элементами.
Плюсы: не нужно высчитывать и отрисовывать ф.13 оставшиеся между элементами пустоты, меньше головной боли для прикладного програмиса.
Минусы: некоторое снижение скорости отрисовки фона для этого режима, за счет добавления лишних проверок.
Области пустоты в окне.
-
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
Mario_r4
И что будет с Fplay и другими программами, которые сами всё рисуют ?
И что будет с Fplay и другими программами, которые сами всё рисуют ?
Идея отличная.
Совместимость со старыми программами будет сохранена?
Совместимость со старыми программами будет сохранена?
Из хаоса в космос
Ничего, они будут продолжать рисовать как раньше - это же выбираемая вещь. Единственно я пока не знаю, что делать в случае аппаратной отрисовки. Можешь ли ты по простому объяснить, что происходит с отрисовкой окон со скинами, при задействовании драйвера?Serge wrote:И что будет с Fplay и другими программами, которые сами всё рисуют ?
Да.Leency wrote:Идея отличная. Совместимость со старыми программами будет сохранена?
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
Mario_r4
Ничего не происходит. Ядро про акселерацию не знает.
Драйвер делает то же, что и ф.73 - выводит битмап на экран. Демки Mesa выводят картинку на месте клиентской области и поэтому заливку фоном не используют. Fplay рисует всё окно в битмап и выводит через ф73 а видео через ф73 или драйвер.
У меня есть некоторые сомнения.
Графическая часть ядра уже сильно запутана, а новый функционал сделает её ещё сложнее. С реализацией тоже не ясно. Сколько прямоугольников можно определять, где их хранить - ядерный malloc не безразмерный.
Ничего не происходит. Ядро про акселерацию не знает.
Драйвер делает то же, что и ф.73 - выводит битмап на экран. Демки Mesa выводят картинку на месте клиентской области и поэтому заливку фоном не используют. Fplay рисует всё окно в битмап и выводит через ф73 а видео через ф73 или драйвер.
У меня есть некоторые сомнения.
Графическая часть ядра уже сильно запутана, а новый функционал сделает её ещё сложнее. С реализацией тоже не ясно. Сколько прямоугольников можно определять, где их хранить - ядерный malloc не безразмерный.
Т.е. 2D ускорения для обычных приложений нет. Но ведь не факт, что в будущем не изменится?Serge wrote:Ничего не происходит. Ядро про акселерацию не знает.
Я спрашивал именно про отрисовку скинованных окон, про вывод через битмап это не коснется вообще.Serge wrote:Драйвер делает то же, что и ф.73 - выводит битмап на экран. Демки Mesa выводят картинку на месте клиентской области и поэтому заливку фоном не используют. Fplay рисует всё окно в битмап и выводит через ф73 а видео через ф73 или драйвер.
В WinAPI такая фича с пустотами есть, чем мы хуже? Насчет запутанности - по моему документация нормально все описывает и у меня лично проблем не было. С прикладной точки зрения отрисовка окна значительно упрощается, и я как ты знаешь не любитель траты памяти (код вывод курсора передает горячий привет ненужному фреймбуферу).Serge wrote:У меня есть некоторые сомнения.
Графическая часть ядра уже сильно запутана, а новый функционал сделает её ещё сложнее.
Не нужен мне malloc - обычное приложение ведь само отрисовывает свое окно. Это будет по реализации подобно "B = 1 - координаты всех графических примитивов задаются относительно клиентской области окна", т.е. ядру особых телодвижений не требуется. Зачем мне копировать данные в область ядра, если код отрисовки окна, в ядре, всегда имеет доступ к исходной области памяти, т.к. все выполняется в одном потоке. Для системной механики оконного стека абсолютно ничего не меняется.Serge wrote:С реализацией тоже не ясно. Сколько прямоугольников можно определять, где их хранить - ядерный malloc не безразмерный.
З.Ы. Мне кажется ты просто не понял о чем именно идет речь.
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
Фича есть, используется редко, когда надо что-то совсем нестандартноеВ WinAPI такая фича с пустотами есть, чем мы хуже?
Я про исходники. Множественное отсечение вообще не подарок. GDI и X server делают CombineRgn(RGN_DIFF) и рисуют оставшиеся прямоугольники. Так же и с отрисовкой курсора. Каждый пиксель не проверяют.Насчет запутанности - по моему документация нормально все описывает и у меня лично проблем не было.
Я не хочу зря расходовать память - жаба придет ко мне ночью и начнет душить меня.Serge wrote:Я про исходники. Множественное отсечение вообще не подарок. GDI и X server делают CombineRgn(RGN_DIFF) и рисуют оставшиеся прямоугольники. Так же и с отрисовкой курсора. Каждый пиксель не проверяют.
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
Будешь каждый пиксель на отсечение проверять ?
Еще раз - если не установлен флаг D (сейчас используется для отрисовки градиента), то будет однократная проверка на установленность флага и все. Для существующих приложение абсолютно ничего не изменится. Если флаг установлен, отрисовка заливки фона перенаправляется в другую процедуру, в которой уже идет контроль каждого пиксела. Как вариант для ускорения можно написать процедуру разбиения на области рисуемых прямоугольников, но тут уже алгоритм сложнее получается. Еще раз - существующие приложения не будут затронуты вообще никак.Serge wrote:Будешь каждый пиксель на отсечение проверять ?
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
А почему не поручить заливку boxlib?
Извините, что влезаю в дискуссию, помимо "Setup" эту заливку использует "Арканойд v 0.3" - это чтобы не забыть поправить потом.
А приложения которым не нужен Box_Lib должны быть лишены такой возможности?SoUrcerer wrote:А почему не поручить заливку boxlib?
Spoiler:
AkyltistЗ.Ы. В общем все как обычно - в 90% случаев, когда предложишь новую полезную вещь, которая старых вещей не затрагивает, начинаются реакционные настроения. Когда сделаешь все успокаиваются и так до следующего раза...
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
Позволит ли новый функционал не рисовать на правой и нижней рамках окна битмапы-тексты-кнопки-..., или лучше этим отдельно заняться?
Я не понял суть идеи. Можно в виде рисунка изложить?lev wrote:Позволит ли новый функционал не рисовать на правой и нижней рамках окна битмапы-тексты-кнопки-..., или лучше этим отдельно заняться?
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
Who is online
Users browsing this forum: No registered users and 14 guests