From: msevior_at_physics.unimelb.edu.au
Date: Fri Dec 12 2003 - 17:37:09 EST
>
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
fp_TextRun.cpp::_draw(...)
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.
Martin
> 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
> http://www.figuiere.net/hub/
> 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