Re: [PATCH] GSoC #07 VBE double buffering (vs r1885)

[Colin D Bennett]

On Mon, 06 Oct 2008 22:02:46 +0300
Vesa Jääskeläinen <address@hidden> wrote:

> Andy Goth wrote:
> > "Colin D Bennett" <address@hidden> wrote:
> > Requiring full-screen repaints is an architectural design that
> > might need rework to undo later.  Or might not, depending on how
> > you implement it.  The interim approach you choose now should be
> > informed by foresight.
> [...]
> Hi,
> 
> I would like to thank Andy for his comments on the topic. I do share
> the same concern about designing double buffering to work properly
> without making hasty implementation first. We can use non-buffered
> solution as a first stage "hasty implementation" and design good
> enough solution to handle double buffering well.
> 
> Dirty rectangles for every buffer (two in double buffer case) might be
> the best approach here. I think there is some kind of dirty rectangle
> implementation on gfxterm so that could be used as a base for this
> work. After that it could be improved to increase performance but the
> main point being that there has to be proper framework to make it
> work properly.
> 
> Usually the slowest step is to transfer image data from main memory to
> video memory (and usually the slowest is to read from video memory to
> main memory and then save it back to video memory). If we can optimize
> memory copies between video and main memories we are on good track to
> solve speed problem.

I agree that a dirty region repaint management system will provide
better performance, but I certainly do not have time to implement it
now.  IMO that would take a lot of work.

I *am* interested in getting high performance, but
(1) I simply don't have time to do it myself right now, and 
(2) gfxmenu seems plenty fast to me--I have run Lua-driven full screen
animations as a desktop background for gfxmenu, and it worked
fantastically. The menu system performs decently even on my
ultra-low-power-but-low-performance-too Via C3 system.

Granted, the gfxterm terminal is nearly unusable right now, but I think
its performance can be improved significantly through a few relatively
minor changes.

Regards,
Colin

signature.asc
Description: PGP signature