Re: Fwd: Double Buffering Plan

From: James D <jamesgecko_at_gmail.com>
Date: Tue Jun 23 2009 - 08:24:43 CEST

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?
        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

===

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 Tue Jun 23 08:24:56 2009

This archive was generated by hypermail 2.1.8 : Tue Jun 23 2009 - 08:24:56 CEST