Оптимизация ядерной графики

Kernel-side graphics support

POLL Ваше мнение об оптимизации GUI ядра

Total votes: 68
Оставить как было
24%
16
Убрать только CGA и VGA, оставить VESA1.2
7%
5
Оставить только VESA2-режимы (без изменения)
10%
7
Разделить 24 и 32bpp графику в условно-компилируемые блоки
26%
18
Оставить в ядре единственный 32bpp-режим
32%
22

  • since #5161 the blitter should also work in 16bpp mode.
    "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." Albert Einstein
  • hidnplayr wrote:since #5161 the blitter should also work in 16bpp mode.
    Blitter code probably still can be optimized. On the other items, the difference between 32bpp and 16bpp on eBox is not so great. For example, the output images f7 hasn't such failure in performance, as f73.
    Spoiler:
    ebox_5157_32bpp.png
    ebox_5157_32bpp.png (6.96 KiB)
    Viewed 7792 times
    ebox_5161_16bpp.png
    ebox_5161_16bpp.png (6.73 KiB)
    Viewed 7792 times
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • Mario: feel free to experiment with this blitter code, I dont like it at all and chose the lazy copy-paste-patch method for this.
    I want to get back to playing with this 86duino and network code now :)
    "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." Albert Einstein
  • hidnplayr wrote:Mario: feel free to experiment with this blitter code, I dont like it at all and chose the lazy copy-paste-patch method for this.
    I want to get back to playing with this 86duino and network code now :)
    I think it makes sense to wait fix for r.5130.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • hidnplayr
    Serge has fixed the problem r.5130. Here are the results of tests on RoverBook U800.
    Spoiler:RoverBook U800 32bpp SVN r.5129
    rb_5129_32bpp.png
    rb_5129_32bpp.png (4.32 KiB)
    Viewed 7744 times
    RoverBook U800 32bpp SVN r.5165
    rb_5165_32bpp.png
    rb_5165_32bpp.png (4.33 KiB)
    Viewed 7744 times
    RoverBook U800 16bpp SVN r.5165
    rb_5165_16bpp.png
    rb_5165_16bpp.png (4.06 KiB)
    Viewed 7744 times
    P.S. Now you can think about the 8-bit modes. :wink:
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • Mario_r4 wrote:P.S. Now you can think about the 8-bit modes. :wink:
    There is also 15 bpp :wink:

    I am personally quite satisfied with the available video modes now.
    I believe almost all VESA2.0+ compatible cards have at least one 16, 24 or 32bpp mode.
    "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." Albert Einstein
  • Ух как много интересных новостей по поводу 16(15)bpp.
    Могу ли я попросить обновить в вики описание графических функций касательно (8), 16, 24, 32bpp?
  • А чего там обновлять? Для приложений ничего не изменилось, не считая того что нужно учитывать возможность режима 16bpp при прямой работе с видеопамятью через регистр GS. Однако работа через GS это скорее системный хак, чем нормальное явление, просто так быстрее считывать данные для скриншутера.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • Mario_r4,
    жаль, признаю, тот самый случай, когда я совершенно не понимаю сути происходящего,
    мне показалось, что fn73 уже может работать не только с 32bpp
  • pascualle wrote:мне показалось, что fn73 уже может работать не только с 32bpp
    Она как раз задумывалась товарищем Serge, чтобы выводить от приложения исключительно 32bpp - так как упрощенный код без кучи проверок работает быстрее ф.65 (которая как раз поддерживает всякие разные bpp).
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • Mario_r4 wrote:Она как раз задумывалась товарищем Serge, чтобы выводить от приложения исключительно 32bpp - так как упрощенный код без кучи проверок работает быстрее ф.65 (которая как раз поддерживает всякие разные bpp).
    Скорость ни при чём: viewtopic.php?p=31993#p31993. Функция 65 написана неправильно, её можно существенно ускорить, чтобы она не отличалась от 73, но, видимо, никому не нужно.
    Сделаем мир лучше!
  • CleverMouse wrote:Скорость ни при чём: viewtopic.php?p=31993#p31993. Функция 65 написана неправильно, её можно существенно ускорить, чтобы она не отличалась от 73, но, видимо, никому не нужно.
    Почему не нужно? Просто некоторые вещи либо забываются (я всего лишь человек, да, а не суперпрограммист с идеальной памятью как ты), либо не критичны для текущего использования. И вообще правило, что любой код можно оптимизировать никто не отменял. У меня сложилось мнение, что Serge сделал ф.73 в основном из-за скорости, возможно я и ошибся в своих оценках.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • pascualle wrote:Mario_r4,
    жаль, признаю, тот самый случай, когда я совершенно не понимаю сути происходящего,
    Во видишь - добрый и вежливый человек все сразу доступно объяснил.
    Spoiler:Вот я не добрый и не вежливый. :wink:
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • Mario_r4
    Не столько из-за скорости, сколько из-за отсечения. + ещё зарезервирован ebx для ROP.
  • Who is online

    Users browsing this forum: No registered users and 4 guests