All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>
To: Colin D Bennett <colin@gibibit.com>
Cc: The development of GNU GRUB <grub-devel@gnu.org>
Subject: Re: gfxmenu available in experimental
Date: Tue, 24 Nov 2009 07:43:29 +0100	[thread overview]
Message-ID: <4B0B8091.6060104@gmail.com> (raw)
In-Reply-To: <20091120145415.1bedabbc@svelte>

[-- Attachment #1: Type: text/plain, Size: 1563 bytes --]

Colin D Bennett wrote:
> On Fri, 20 Nov 2009 23:17:51 +0100
> Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com> 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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 293 bytes --]

  reply	other threads:[~2009-11-24  6:44 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-20 22:17 gfxmenu available in experimental Vladimir 'φ-coder/phcoder' Serbinenko
2009-11-20 22:54 ` Colin D Bennett
2009-11-24  6:43   ` Vladimir 'φ-coder/phcoder' Serbinenko [this message]
2009-11-21 12:26 ` Robert Millan
2009-11-21 19:04   ` Vladimir 'φ-coder/phcoder' Serbinenko
2009-11-21 15:43 ` Robert Millan
2009-11-21 18:07   ` Robert Millan
2009-11-21 18:17   ` Colin D Bennett
2009-11-21 18:24     ` Felix Zielcke
2009-11-26 18:18       ` Colin D Bennett
2009-11-21 18:40     ` Robert Millan
2009-11-27 11:42 ` Felix Zielcke

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B0B8091.6060104@gmail.com \
    --to=phcoder@gmail.com \
    --cc=colin@gibibit.com \
    --cc=grub-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.