Hi,
on this topic there was a parallel discussion on
dev@gsl.openoffice.org so I'm forwarding my answer here too. I suggest
that before further talk everyone who had seen the problem in
>=DEV300_m29 (where the new DrawingLayer got integrated) should
retest it with >=DEV300_m52 (where issue 83553 and related issues got
fixed).
Begin forwarded message:
From: Herbert Duerr <du...@sun.com>
Date: August 25, 2009 9:10:54 AM GMT+02:00
To: dev@gsl.openoffice.org
Subject: Re: [gsl-dev] New implementation of drawinglayer may lead
to performance downgrade?
Hi Yanmin,
the excessive reformats where the core of the problem. That it
happened even when nothing was going on (except so seemingly
innocent actions as just moving the mouse) was the symptom that I
reported. Because there is quite a difference between "symptom" and
"root cause" and I prefer to update the issue summary to the root
cause of the problem as soon as it is fully understood. Other
developers prefer to keep the summary line exactly as provided by
the issue reporter. I disagree with this but there is nothing I can
do except to lead by example.
AFAIK the root cause of the problem was that the new DrawingLayer
relied on EditEngine to do the formatting and it didn't keep the
results. So every time it measured something the DrawingLayer
reformatted it and measured it. Since our underlying text processing
is outstandingly fast this problem wasn't noticed for quite a while.
The solution consisted of course in keeping the formatted result.
And of course the DrawingLayer likes to keep it converted to a bag
of BasePrimitives. Doing it this way the measurements only need to
be done once and the base primitives cache the results. So this is
the reason why I think that the cached results may benefit your case:
- they avoid that EditEngine is requested to do reformats over and
over
- they avoid that the same thing is re-measured over and over
=> drawinglayer::primitive2d::getB2DRangeFromPrimitive2DSequence is
now usually called much less than the gazillion times it was called
between OOO310 and DEV300_m52
So, there is good reason to expect that the particular problem you
are seeing is solved in newer DEV300 builds. Please retest the
problem. Don't take issue summaries verbatim if they were solved by
developers who don't update their issue summary lines to the root
cause of the problem.
On Aug 25, 2009, at 6:09 AM, yanmin wrote:
Hi Herbert,
maybe the fix against "excessive reformatting in textboxes" (
http://www.openoffice.org/issues/show_bug.cgi?id=83553) is the one
you are
looking for. The fix for that got into DEV300_m52.
It seems the performance bug reported by ssue 83553 is raised while
mouse
moving because of expensive textbox reformatting. But the performance
problem I mensioned happens when creating a new presentation. And the
function
drawinglayer::primitive2d::getB2DRangeFromPrimitive2DSequence which
is called heavily by S*drobject::RecalcBoundRect* takes 29% time
during the
new presentation process from our profiling data. So a developer is
suspicious that the problem is caused by the code change of
drawinglayer or
S*drobject*.
On Aug 24, 2009, at 12:16 PM, Christian Lippka wrote:
you forgot to state in which version you see the performance
problem.
I think that there was already a performance fix in the area of
RecalcBoundRect but I cc'ed Armin to tell us if this is true and in
which version it is fixed.
---
Herbert Duerr
du...@sun.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@gsl.openoffice.org
For additional commands, e-mail: dev-h...@gsl.openoffice.org