Области пустоты в окне.

Kernel-side graphics support
  • Mario_r4
    И что будет с Fplay и другими программами, которые сами всё рисуют ?
  • Идея отличная.

    Совместимость со старыми программами будет сохранена?
    Из хаоса в космос
  • Serge wrote:И что будет с Fplay и другими программами, которые сами всё рисуют ?
    Ничего, они будут продолжать рисовать как раньше - это же выбираемая вещь. Единственно я пока не знаю, что делать в случае аппаратной отрисовки. Можешь ли ты по простому объяснить, что происходит с отрисовкой окон со скинами, при задействовании драйвера?
    Leency wrote:Идея отличная. Совместимость со старыми программами будет сохранена?
    Да.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • Mario_r4
    Ничего не происходит. Ядро про акселерацию не знает.
    Драйвер делает то же, что и ф.73 - выводит битмап на экран. Демки Mesa выводят картинку на месте клиентской области и поэтому заливку фоном не используют. Fplay рисует всё окно в битмап и выводит через ф73 а видео через ф73 или драйвер.

    У меня есть некоторые сомнения.
    Графическая часть ядра уже сильно запутана, а новый функционал сделает её ещё сложнее. С реализацией тоже не ясно. Сколько прямоугольников можно определять, где их хранить - ядерный malloc не безразмерный.
  • Serge wrote:Ничего не происходит. Ядро про акселерацию не знает.
    Т.е. 2D ускорения для обычных приложений нет. Но ведь не факт, что в будущем не изменится?
    Serge wrote:Драйвер делает то же, что и ф.73 - выводит битмап на экран. Демки Mesa выводят картинку на месте клиентской области и поэтому заливку фоном не используют. Fplay рисует всё окно в битмап и выводит через ф73 а видео через ф73 или драйвер.
    Я спрашивал именно про отрисовку скинованных окон, про вывод через битмап это не коснется вообще.
    Serge wrote:У меня есть некоторые сомнения.
    Графическая часть ядра уже сильно запутана, а новый функционал сделает её ещё сложнее.
    В WinAPI такая фича с пустотами есть, чем мы хуже? Насчет запутанности - по моему документация нормально все описывает и у меня лично проблем не было. С прикладной точки зрения отрисовка окна значительно упрощается, и я как ты знаешь не любитель траты памяти (код вывод курсора передает горячий привет ненужному фреймбуферу).
    Serge wrote:С реализацией тоже не ясно. Сколько прямоугольников можно определять, где их хранить - ядерный malloc не безразмерный.
    Не нужен мне malloc - обычное приложение ведь само отрисовывает свое окно. Это будет по реализации подобно "B = 1 - координаты всех графических примитивов задаются относительно клиентской области окна", т.е. ядру особых телодвижений не требуется. Зачем мне копировать данные в область ядра, если код отрисовки окна, в ядре, всегда имеет доступ к исходной области памяти, т.к. все выполняется в одном потоке. Для системной механики оконного стека абсолютно ничего не меняется.

    З.Ы. Мне кажется ты просто не понял о чем именно идет речь.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • В WinAPI такая фича с пустотами есть, чем мы хуже?
    Фича есть, используется редко, когда надо что-то совсем нестандартное
    Насчет запутанности - по моему документация нормально все описывает и у меня лично проблем не было.
    Я про исходники. Множественное отсечение вообще не подарок. GDI и X server делают CombineRgn(RGN_DIFF) и рисуют оставшиеся прямоугольники. Так же и с отрисовкой курсора. Каждый пиксель не проверяют.
  • Serge wrote:Я про исходники. Множественное отсечение вообще не подарок. GDI и X server делают CombineRgn(RGN_DIFF) и рисуют оставшиеся прямоугольники. Так же и с отрисовкой курсора. Каждый пиксель не проверяют.
    Я не хочу зря расходовать память - жаба придет ко мне ночью и начнет душить меня.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • Будешь каждый пиксель на отсечение проверять ?
  • Serge wrote:Будешь каждый пиксель на отсечение проверять ?
    Еще раз - если не установлен флаг D (сейчас используется для отрисовки градиента), то будет однократная проверка на установленность флага и все. Для существующих приложение абсолютно ничего не изменится. Если флаг установлен, отрисовка заливки фона перенаправляется в другую процедуру, в которой уже идет контроль каждого пиксела. Как вариант для ускорения можно написать процедуру разбиения на области рисуемых прямоугольников, но тут уже алгоритм сложнее получается. Еще раз - существующие приложения не будут затронуты вообще никак.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • А почему не поручить заливку boxlib?
  • Извините, что влезаю в дискуссию, помимо "Setup" эту заливку использует "Арканойд v 0.3" - это чтобы не забыть поправить потом.
  • SoUrcerer wrote:А почему не поручить заливку boxlib?
    А приложения которым не нужен Box_Lib должны быть лишены такой возможности?
    Spoiler:Akyltist
    Спасибо, учту.

    З.Ы. В общем все как обычно - в 90% случаев, когда предложишь новую полезную вещь, которая старых вещей не затрагивает, начинаются реакционные настроения. Когда сделаешь все успокаиваются и так до следующего раза...
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • Позволит ли новый функционал не рисовать на правой и нижней рамках окна битмапы-тексты-кнопки-..., или лучше этим отдельно заняться?
  • lev wrote:Позволит ли новый функционал не рисовать на правой и нижней рамках окна битмапы-тексты-кнопки-..., или лучше этим отдельно заняться?
    Я не понял суть идеи. Можно в виде рисунка изложить?
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • Who is online

    Users browsing this forum: No registered users and 5 guests