Re: RFC Speeding up graphics

Date: Fri Dec 12 2003 - 17:37:09 EST

  • Next message: Dom Lachowicz: "Re: RFC Speeding up graphics"


    Hi Hub,
           On unix I don't see a need for this for purposes of speed. The
    heart of the drawing processing in abiword is

    The code there to set up the graphics class is absolutely neceesary
    because it only gets called when the it changes. (ie A font is different
    on a line, or has become bold or changes size.) I can't see your proposals
    changing this because you'll have to do it anyway.

    There might a case for this for other purposes. For example AbiWord looks
    funny sometimes because we always do a clearscreen on a run of text that
    changes (before it changes) then if there is some complex operation that
    occurs we see flicker while the the program works out what changes are
    needed then draws to the screen.

    If we could pipeline all this (the clearscreen and redraw) into one stream
    of operation we would significantly reduce the amount of onscreen flicker.
    I guess this is most apparent when we manipulate large tables.

    Even given that, I'm rather afraid of making these changes. I can see them
    being very de-stabilizing. Can we wait till the 2.3 development cycle? Are
    they absolutely necessary for OSX? I just don't personally have a lot of
    extra cycles to make these large-scale changes to the code base without
    significantly decreasing what will be available for 2.2.

    I suspect the case for Windows is even worse.

    Maybe the changes aren't as invasive as I think. I'd really like to see a
    proposed patch before committing it.


    > Hi,
    > While porting AbiWord to MacOS X, I found out a few performance
    > problems, mostly due to MacOS X Core Graphics layer, but also to some
    > design issues in the GR_Graphics class and its use, in the Abi
    > framework.
    > The main problem is that for each graphics operation we need:
    > -to setup a graphic context (costly)
    > -setup the graphic properties (line size, etc) and clipping
    > -do our stuff
    > -reset everything
    > All of this, at least on MacOS X, but I'm sure that it does too on
    > other platforms, it is *costly*. I actually found myself some huge
    > bottleneck elsewhere to reduce the overhead, but there is still too
    > much IMHO.
    > I thought about a solution and found actually 2 that would work for
    > any platform, with both pros and cons.
    > Solution 1, probably the preferred one:
    > -Surround any drawing with startDraw()/endDraw() calls (everywhere in
    > XP code)
    > -implement these 2 methods to do the setup pre and post draw.
    > (GR_Graphics subclass)
    > Pro:
    > -simple and efficient
    > -minimum platform work (initial can be empty implementations)
    > Cons:
    > -need to track any drawing
    > Solution 2, the smarter but more complex:
    > -Implement all the drawing operation in XP land (GR_Graphics) to stack
    > them up in a graphic pipeline
    > -Implement in GR_Graphics::sync() culling of the whole graphic pipeline
    > -Make sure we call sync() after each drawing (not each operations)
    > Pro:
    > -much smarter and elegant
    > -can be really efficient
    > Cons
    > -large platform rework effort
    > -complex and probably harder to debug
    > What are your opinions ? If no one object, I'm going to spend time on
    > solution 1 as I really need to speed up graphics.
    > Hub
    > --
    > AbiWord maintainer - Lille, France
    > GPG fingerprint: 6C44 DB3E 0BF3 EAF5 B433 239A 5FEE 05E6 A56E 15A3

    This archive was generated by hypermail 2.1.4 : Fri Dec 12 2003 - 17:43:04 EST