From: msevior_at_physics.unimelb.edu.au
Date: Sat Dec 13 2003 - 16:53:17 EST
>
>> 1. We have the the ability to record XP graphics
>> operations in some sort
>> of FIFO buffer.
>>
>> 2. If the beginGraphic() operation is called we
>> increment a member
>> variable in the graphics class to record the level
>> of nesting. Call this
>> m_iNest.
>>
>> 3. If m_iNest > 0 when XP calls are made on the
>> graphics class, the call
>> and all it's parameters are recorded in the FIFO
>> buffer.
>>
>> 4. if endGraphic() is called m_iNest is decremented.
>> If m_iNest == 0 after the decrement the FIFO buffer
>> is executed and all
>> the graphics operations are performed in the
>> sequence they were recorded.
>>
>> This does give us the ability to glob many complex
>> operations into one
>> fast run. It will substantially reduce flicker.
>
> Yes.
>
>> I can imagine placing beginGraphic()... endGraphic()
>> calls around
>> piecetable manipulations in the fv_View methods (and
>> elsewhere) much like
>> we do beginAtomicGlob() endAtomicGlob(). Then big
>> complex operations are
>> rolled into one set of manipulations.
>
> Precisely.
>
>> A potential problem is if we have several views of
>> the one document open.
>> The views that are not active will not get the
>> globbing. I suspect we can
>> live with this as it will just make other views
>> flicker like they do now
>> rather than have the flicker free operation of the
>> globbed graphics
>> operations.
>
> I don't see how this would happen. Each view would
> have its own graphics class, with its own graphics
> "FIFO". The globbing would (should) happen atomically
> for each view/graphics class, so we wouldn't see any
> flicker for any of them.
>
Right but the other views won't get the "beginGraphic()/endGraphic()"
commands. Anyway, I'm not too worried this. It can be solved and is not
too much a of big deal if it's not.
>> Another potential problem is if the graphics windows
>> is scrolled in the
>> middle of a set of globbed graphics operations.
>> fv_View::_ensureInsertionPointIsOnScreen() could do
>> this as could user
>> manipulations of the scroll bar. I think we'll need
>> to lock scrolling out
>> while m_iNest > 0 and make sure this does not screw
>> up other assumptions
>> (like m_iYOffset, m_iXOffset in fv_View being
>> different from the actual
>> offset in the graphics classes.)
>
> Maybe. We'll look into this when the time comes.
>
_ensureInsertionPointIsOnScreen() is almost always called at the end
of all the manipulations but I think there can be corner cases where it's
called in the middle. If it is we'll get totally screwed. I agree it's
best to solve this after the main issues are fixed. We should look out for
it though.
>> Finally implementing the graphics FIFO will require
>> something like a set
>> of graphics changeRecords to remember what each
>> requested operation was
>> and what the parameters of the operation were. This
>> will be a significant
>> amount of work...
>
> No, this isn't what we're suggesting at all. This was
> Hub's suggestion #2. We're suggesting #1 instead.
> Probably, all of our operations will be drawn into an
> offscreen buffer. At _endPaint(), we copy the
> offscreen buffer onto the screen via a BltBlt() type
> of operation.
>
Oh! Now I get it. Very nice. I can also use this to really speed up
interactive dragging of frames and text.
I'm eager to see the code and help out now.
Martin
> Dom
>
> __________________________________
> Do you Yahoo!?
> Protect your identity with Yahoo! Mail AddressGuard
> http://antispam.yahoo.com/whatsnewfree
>
This archive was generated by hypermail 2.1.4 : Sat Dec 13 2003 - 16:52:39 EST