From: Johan Björk (phearbear_at_home.se)
Date: Sat Dec 13 2003 - 03:44:10 EST
Dom Lachowicz wrote:
>As a further follow-up, I think that it would probably
>be good if *all* of our drawing operations happened
>through this class. That is, all of the drawing
>routines inside of GR_Graphics became protected, and
>only called from either:
>
>1) A subclass
>2) This "lock" class
>
>This would be beneficial so that no drawing operations
>could ever happen outside of the "lock".
>
>Another, less-clean alternative could include a
>"locked()" check inside of every drawing operation. I
>think that the former option is infinitely preferable
>to the latter one.
>
>If there are no objectsions, I will implement this
>over the weekend.
>
>Dom
>
>
>
I sorta have this done already, but i've been really busy at the
military lately, I would attach a patch but cvs access seems down.
It works supernice for me with offscreen buffers and such, no flickering ^_^
It still has a few problems which I havn't had time to fix, anyway, when
I wake up tomorow I'll see if I can upload the patch if anyone is interested
/Johan
>--- Dom Lachowicz <domlachowicz_at_yahoo.com> wrote:
>
>
>>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
>>
>>
>
>
>__________________________________
>Do you Yahoo!?
>Protect your identity with Yahoo! Mail AddressGuard
>http://antispam.yahoo.com/whatsnewfree
>
>
>
This archive was generated by hypermail 2.1.4 : Sat Dec 13 2003 - 04:12:43 EST