From: Dom Lachowicz (domlachowicz_at_yahoo.com)
Date: Sat Dec 13 2003 - 12:03:15 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.
> 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.
> 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.
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 - 12:02:34 EST