Re: RFC Speeding up graphics

From: Dom Lachowicz (
Date: Sat Dec 13 2003 - 12:03:15 EST

  • Next message: Hubert Figuiere: "Re: CVS screwup"

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


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

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

    Do you Yahoo!?
    Protect your identity with Yahoo! Mail AddressGuard

    This archive was generated by hypermail 2.1.4 : Sat Dec 13 2003 - 12:02:34 EST