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

[Vesa Jääskeläinen]

Andy Goth wrote:
> "Colin D Bennett" <address@hidden> wrote:
>> First make it work, then make it rock.
> 
> I certainly do appreciate that, but...
> 
>> my plan is to avoid complicated dirty-region repaint strategies 
>> at first.
> 
> 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.
> 
> Full-screen repaint approach that will require rework later:
> 
> - One function draws everything in sequence.  It gets called every frame.
> 
> Full-screen repaint approach that will be easy to integrate into a partial 
> update scheme:
> 
> - A separate function exists for drawing each logical unit of the screen.
> - Every frame, one function calls all the separate functions in sequence.
> 
> Or something like that.

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.

Thanks,
Vesa Jääskeläinen