Re: Fwd: Double Buffering Plan

From: James D <jamesgecko_at_gmail.com>
Date: Sat Jun 06 2009 - 20:15:52 CEST

Hi Martin,

Yeah, something like that. Though as enjoyable as recursion is, uwog
said that we didn't want to have situations like having one large table
buffer and a bunch tiny buffers for each cell of the table. Table cells
*should* be able to use startBuffering and end up with the same buffer
the larger table uses. Additionally, I think we're only buffering
certain runs, which also makes recursion somewhat less appealing.

The static things are just representing the data structures and
pointers.

I'll defiantly be messing with Valgrind once I get something implanted
to see what sort of speed/memory tradeoff there is.

 --James

On Sat, 2009-06-06 at 20:13 +1000, Martin Sevior wrote:
> ---------- Forwarded message ----------
> From: Martin Sevior <msevior@gmail.com>
> Date: Sat, Jun 6, 2009 at 7:53 PM
> Subject: Re: Double Buffering Plan
> To: James D <jamesgecko@gmail.com>
> Cc: "J.M. Maurer" <uwog@uwog.net>, abiword-dev <abiword-dev@abisource.com>
>
>
> Hi James,
> This is really interesting! Do you envision something like:
>
> pG->startBuffering();
>
> ...
> ... Code, code code
> ....
>
> pG->endBuffering();
>
> Can these be nested so that things only drawn when the endBuffering()
> level drops to zero?
>
> What do the static methods do? Why do they need to be static?
>
> In any case, it very interesting indeed! Provided we're make sure we
> don't leak, I'd choose an algorithm that uses memory to gain speed if
> you have that choice.
>
> Cheers
>
> Martin
>
>
> On Sat, Jun 6, 2009 at 5:26 PM, James D <jamesgecko@gmail.com> wrote:
> >
> > Hello Marc,
> >
> > Is this along the lines of what you wanted with The Plan (tm)? Is it
> > too narrow? Is anything obvious overlooked?
> >
> > Thanks,
> > --James
> >
> > /* Add startBuffering and endBuffering to everything that needs to be double
> > buffered. This will stack buffers which overlap.*/
> >
> > static bufferContainer //It seems like this should be a map (extents
> > and buffers).
> > //It would make it easier to deal with
> > overhanging letters.
> > //Or it could be a FIFO, if we don't mind extra memory
> > //usage by redraw runs creating new buffers.
> > static bufferQueue //a list of the extents
> > static bufferPointer //starts out pointing at mainBufferPointer
> > static mainBufferPointer //always points to main cairo surface
> >
> > getBuffer()
> > return bufferPointer
> >
> > startBuffering(extents) //The extents are coming from something like
> > getClipRect?
> > if no buffer in bufferContainer
> > put a new buffer in bufferContainer
> > remap bufferPointer to new buffer
> > elif for each buffer in bufferContainer
> > see if extents fit inside buffer
> > if extent found
> > remap bufferPointer to new buffer
> > if no extents found
> > put a new buffer in bufferContainer
> > remap bufferPointer to new buffer
> >
> > endBuffering()
> > make bufferPointer point back at the same location as mainBufferPointer
> >
> > // Run at the end
> > printBufferQueue()
> > for buffer in bufferContainer
> > pop
> > paint to mainBufferPointer
> >
> > //Is there any advantage to keeping the queue around for multiple render cycles?
> > clearBufferQueue()
> > //wipe the stack and start anew
Received on Sat Jun 6 20:16:15 2009

This archive was generated by hypermail 2.1.8 : Sat Jun 06 2009 - 20:16:15 CEST