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

Kernel-side graphics support
  • lev wrote:Возможно функция дырозаполнения сможет учитывать все рамки окна и косвенно повлияет и на другие функции рисования.
    Нет, моя идея подразумевала лишь добавление списка прямоугольных областей пустоты в заливке фона. То что ты предлагаешь никак не связано с моей идеей. Границы областей пустоты это по сути границы элементов, которые отрисовываются после заливки фона. Тупо составляется список этих областей и скармливается ф.0, а она уже ориентируясь по ним заливает или не заливает фон по определенным областям.

    Вообще, то что ты предлагает уже делается, но только для всего окна - происходит отсечка и ничего не рисуется за пределы окна. Выводить все через PutPixel это будет очень медленно работать. В общем вопрос простым способом не решается. Тупо повторно выводить рамки - будет моргание (blink), хоть это тоже метод решения, но в случае когда нет порчи границ это лишняя отрисовка, на которую тратится время.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • Serge wrote:
    В WinAPI такая фича с пустотами есть, чем мы хуже?
    Фича есть, используется редко, когда надо что-то совсем нестандартное
    Ну у нас-то не как у них :) Здесь, может быть, наоборот, часто будет использоваться.

    Тут ещё неизвестно, что быстрее получится: для варианта Mario нужен будет только один системный вызов, а если рисовать множество прямоугольников самому, то, соответственно, несколько системных вызовов.
    Наверное, быстрее всего было бы сразу рисовать всё в буфер, и выводить его одним системным вызовом, но, к сожалению, например, box_lib не умеет рисовать компоненты в буфер. То есть, я имею в виду: залили буфер нужным цветом, нарисовали в буфер компоненты, вывели буфер на экран.
    Mario_r4 wrote:В общем все как обычно - в 90% случаев, когда предложишь новую полезную вещь, которая старых вещей не затрагивает, начинаются реакционные настроения.
    Тот, кому это не нужно, просто не будет это использовать, а вот те, кому нужно, будут только рады.

    Реализация этой идеи могла бы помочь избавиться от лишнего кода.
    : Например, для того, чтобы избавится от мерцания в fNav(список теперь совсем не мерцает), мне потребовалось около килобайта дополнительного несжатого кода. Если попытаться это оптимизировать, то код будет совсем нечитаемый. А вот если бы у меня была возможность использовать пока ещё идею Mario, то -1K кода и +читаемость\понятность, возможно, в зависимости от реализации, это было бы даже быстрее.
    Mario_r4 wrote:Вообще, то что ты предлагает уже делается, но только для всего окна - происходит отсечка и ничего не рисуется за пределы окна.
    А неужели так сложно при отсечении учесть ещё и window.BORDER_SIZE?
  • 0CodErr wrote:А неужели так сложно при отсечении учесть ещё и window.BORDER_SIZE?
    Наверное можно, но нужно перерабатывать код ядра под новые границы. К сожалению это будет не просто, потому что много зависимого друг от друга кода. Меняешь одно место и нужно корректировать несколько других, чтобы тупо не "разъехалось".
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • Who is online

    Users browsing this forum: No registered users and 6 guests