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

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

  • art_zh wrote:Mario
    Мог бы и не писать.
    Все равно хабрапиплы всегда будут правы - у этой оськи никогда не будет никаких реально нужных практических применений.
    И сейчас она никому нафиг не нужна.
    Под нее даже и задач никаких специфических не существует.
    И прошу заметить - никогда не существовало.
    Так, одно недоразумение.
    Потому что все равно винда (линукс, qnx) гораздо круче, и отлично работают во всех мыслимых ситуациях.
    Ну, я рад что ты встал на путь истинный и праведный. :mrgreen:
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • Напомнило, как мы в школе ходили гулять к девчёнкам в ругой двор. Приходим как-то раз, они говорят: "Мы кое-что знаем"
    Мы такие: "И что же?"
    "А мы не скажем" и смеются.
    Из хаоса в космос
  • leency
    а тебя-то что конкретно интересует ?
  • As of revision #5154 KolibriOS kernel supports 16bpp VESA modes.
    Last edited by hidnplayr on Mon Nov 03, 2014 6:53 pm, edited 1 time in total.
    "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
    Your code is very useful, but I think you're too quick with removing align4 in some places. I think the performance for vesa20.inc has a higher priority than decreasing the size of the binary code by 5%.

    Dell Inspiron 32bpp SVN r.5150
    Spoiler:
    dell_5150.png
    dell_5150.png (6.89 KiB)
    Viewed 7550 times
    Dell Inspiron 32bpp SVN r.5154
    Spoiler:
    dell_5154.png
    dell_5154.png (7.1 KiB)
    Viewed 7550 times
    Also we need to fix some of the programs that receive data through f.36 and GS.
    Last edited by Mario_r4 on Sun Nov 02, 2014 2:42 pm, edited 1 time in total.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • Mario_r4 wrote:hidnplayr
    Your code is very useful, but I think you're too quick with removing align4 in some places. I think the performance for vesa20.inc has a higher priority than decreasing the size of the binary code by 5%.

    Also we need to fix some of the programs that receive data through f.36 and GS.
    Okay, I only removed "align 4" where it doesn't seem to make any sense.
    If I'm wrong, please show me where or why and I'll be happy to correct.
    Unfortunately, MGB reports seem unstable, and you made a typo labelling both screenshots 5150 :)

    Usage of GS has since long time been discouraged. I'll look into f36, where did you see any problems?
    "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:Okay, I only removed "align 4" where it doesn't seem to make any sense.
    If I'm wrong, please show me where or why and I'll be happy to correct.
    I am very lazy person so I just put align4 everywhere. :mrgreen:
    hidnplayr wrote:Unfortunately, MGB reports seem unstable, and you made a typo labelling both screenshots 5150 :)
    Damn COPY-PASTE! The picture however are right. It's not so noticeable on a Dell Inspiron (core i5), but on slower machines this becomes more apparent. Unfortunately my RoverBook u800 is not working since r.5130. I will be testing 5150 and 5154 on eBox-3300MX and I will post the results later.
    hidnplayr wrote:Usage of GS has since long time been discouraged. I'll look into f36, where did you see any problems?
    Problems exist for MGB and SCRSHOOT for 16 bpp modes. Perhaps there is any program yet.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • btw, here are my test results (from virtualbox, in 800x600x32bpp mode)
    align 4 can actually slow down code because it inserts NOP instructions in some code paths.
    Spoiler:Image
    Image
    PS: more is better.
    "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
  • eBox-3300MX 32bpp SVN r.5150
    Spoiler:
    ebox_5150.png
    ebox_5150.png (6.85 KiB)
    Viewed 7621 times
    eBox-3300MX 32bpp SVN r.5154
    OOPS...
    Spoiler:
    IMGP9031.jpg
    IMGP9031.jpg (908.73 KiB)
    Viewed 7621 times
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • Mario_r4 wrote:eBox-3300MX 32bpp SVN r.5154
    OOPS...
    What happened? System crashed/hung after loading RDC driver?
    Just tested on my eBox, everything OK (32bpp and 16bpp modes work fine)

    EDIT: Looks like I spotted the problem, expect a fix soon ;)
    "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
  • please try again with #5157
    "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
  • Mario_r4 wrote:Also we need to fix some of the programs that receive data through f.36 and GS.
    f36 works correctly, but f73 (blitter) is not yet implemented 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:please try again with #5157
    Yes, it's work fine. Thanks, great job and I withdraw my objections about align4.
    Spoiler:eBox-3300MX 32bpp SVN r.5150
    ebox_5150.png
    ebox_5150.png (6.85 KiB)
    Viewed 7565 times
    eBox-3300MX 32bpp SVN r.5157
    ebox_5157.png
    ebox_5157.png (6.96 KiB)
    Viewed 7565 times
    eBox-3300MX 16bpp SVN r.5157
    IMGP9035.jpg
    IMGP9035.jpg (99.69 KiB)
    Viewed 7565 times
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • hidnplayr wrote:
    Mario_r4 wrote:Also we need to fix some of the programs that receive data through f.36 and GS.
    f36 works correctly, but f73 (blitter) is not yet implemented in 16bpp mode.
    I'm not sure about the correct operation f36. You can see in the picture the colors displayed on the screen and the colors obtained in f36 not conform to the format. The application expects that the color will be in the format 24bpp, but the current code simply copies 16bpp to 24bpp.

    I think it is better to do the conversion 16bpp to 24bpp at the kernel level - it will solve the problem for many applications.
    Spoiler:
    IMGP9040.JPG
    IMGP9040.JPG (243.93 KiB)
    Viewed 7563 times
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • Who is online

    Users browsing this forum: No registered users and 2 guests