[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gfxmenu available in experimental
From: |
Vladimir 'φ-coder/phcoder' Serbinenko |
Subject: |
Re: gfxmenu available in experimental |
Date: |
Tue, 24 Nov 2009 07:43:29 +0100 |
User-agent: |
Mozilla-Thunderbird 2.0.0.22 (X11/20091109) |
Colin D Bennett wrote:
> On Fri, 20 Nov 2009 23:17:51 +0100
> Vladimir 'φ-coder/phcoder' Serbinenko <address@hidden> wrote:
>
>
>> Hello, all. After various delays with various cause I'm proud to
>> announce the availability of Colin's gfxmenu into experimental branch
>> of grub2.
>>
>
> Thanks for keeping things moving forward even while I have not had time
> to do anything on gfxmenu for quite a while.
>
>
>> Known issues with gfxmenu:
>> 1) It's slow. At least in qemu. More things are repainted than really
>> needed
>>
>
> Yes, it is slow. Whether or not it was to best decision at the time, I
> decided during the Summer of Code that I would keep the painting logic
> simple as by always repainting the entire screen whenever anything
> changes. (I wanted to support fancy features like animated
> transitions, backgrounds, and widgets, and I knew that double-buffering
> would be necessary for this.)
>
> It would perhaps be best to keep track of dirty regions and only repaint
> those parts -- however, this gets more complicated when page flipping is
> being used as a double-buffering method.
>
>
I optimised it (pushed to branches/gfxmenu and experimental) and now it
runs pretty fast on qemu with 1024x768 resolution but this amount of
optimisation is far from maximum.
Now the 2 main speed problems are initialising (takes few seconds) and
scrolling in gfxterm (sluggish). Would you have an idea how to speed up
those 2?
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
signature.asc
Description: OpenPGP digital signature