From: Dom Lachowicz (domlachowicz_at_yahoo.com)
Date: Fri Dec 12 2003 - 18:46:02 EST
Hi Martin,
We really do need something like this.
1) It gets us double buffering and could greatly
reduce flicker
2) It has the potential of speeding things up
significantly for all our platforms, most notably
MacOSX and QNX.
As a fall-back, we can have the "beginDraw()" and
"endDraw()" functions no-op for the time being. This
will have absolutely no affect on anything, really.
I'm really in favor of doing this (and implementing
beginDraw and endDraw properly). I don't think that it
will be destabilizing.
I'll post a patch to the list before committing.
Cheers,
Dom
--- msevior_at_physics.unimelb.edu.au wrote:
> >
>
> 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
> >
>
__________________________________
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 - 18:45:17 EST