Re: Fwd: Double Buffering Plan

On Mon, 2009-06-22 at 23:24 -0700, James D wrote:
> Hello Marc,
> Round two!
>
> --James
>
> deque<std::pair<buffer, extends>>
> bufferPointer //starts out pointing at mainBufferPointer
> mainBufferPointer //always points to main cairo surface
>
> getBuffer()
> return bufferPointer
>
> setActiveBuffer(buffer)
> remap bufferPointer to buffer
>
> beginBuffering(extends) //The extends are coming from something like
> getClipRect?

>From the cliprects, or "drawing arguments". A DA pointer contains the
extends as well

> if no buffers
> put a new buffer in the stack
> setActiveBuffer(newBuffer)
>
> while no suitable buffer found
> if the extends fit inside this larger or equal sized buffer
> setActiveBuffer(buffer)
> elif extends overlap
> put a new buffer on top of the stack
> setActiveBuffer(newBuffer)
> else
> next buffer
> if no suitable buffer found
> put a new buffer on bufferContainer
> setActiveBuffer(newBuffer)
>
> endBuffering()
> setActiveBuffer(top of the stack)
> if every begin is matched by an end
> while bufferContainer not empty
> pop the bottom
> paint to mainBufferPointer

Looks good to me so far! I think it is time to start hacking this up.
90% of this can go into the generic GR_Graphics* class. Function to
create a new buffer and to actually draw them will probably need to be
platform specific.

Happy hacking!
  Marc

> ===
>
> On Sat, Jun 6, 2009 at 11:15 AM, James D<jamesgecko@gmail.com> wrote:
> > 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 27 21:56:32 2009