Re: RFC Speeding up graphics

Date: Sat Dec 13 2003 - 16:53:17 EST

  • Next message: Tomas Frydrych: "commit (HEAD): misc"

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

    > Dom
    > __________________________________
    > Do you Yahoo!?
    > Protect your identity with Yahoo! Mail AddressGuard

    This archive was generated by hypermail 2.1.4 : Sat Dec 13 2003 - 16:52:39 EST