From: Dom Lachowicz (domlachowicz_at_yahoo.com)
Date: Fri Dec 12 2003 - 17:04:31 EST
Hi Hub,
I've suggested #1 before when talking with Phearbear
on IRC. I think that he even started on some code too.
IMO, we need something like:
/* only invoked from a "helper class" described below
*/
private void GR_Graphics::beginDraw();
private void GR_Graphics::endDraw();
/* implemented in platform-specific classes */
virtual void GR_Graphics::_beginDraw() = 0;
virtual void GR_Graphics::_endDraw() = 0;
These should have an integer count so that they can be
invoked "recursively", but the actual drawing won't
happen until the last "endDraw()" which will commit
the operation.
Further, I think that we need a "GR_GraphicsLocker"
class. Its purpose is to manage calling beginDraw()
and endDraw() for us. For example:
void FV_View::drawFoo ()
{
// beginDraw() implicitly called
GR_GraphicsLocker lock (getGraphics());
if (!needsToBeDrawn)
return; // endDraw() implicitly called
else {
getGraphics()->drawLine ();
...
}
// endDraw() implicitly called
}
So yes, please do option #1. It will help us all out a
lot.
Best regards,
Dom
--- Hubert Figuiere <hfiguiere_at_teaser.fr> wrote:
>
> 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
__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree
This archive was generated by hypermail 2.1.4 : Fri Dec 12 2003 - 17:10:26 EST