Created attachment 50680 [details]
Demo presentation with some graphics.

Hi, 

To me it looks like the first slide works OK in OOo 2.4 (1st release candidate).
In the second slide however, the onions seem sluggish and some of the onions
move behind boxes. This is on athlon an xp 1600+, 512 MB (without
performance-eating virus checker).

I also tested with OOo 2.3.0 on a Pentium III 1GHz, 256 MB. The first slide is
more smooth than what Johan gets with 2.3.1, but worse than what he gets with
2.2. The "customer" bubble gets more to the right but still not in the correct
place (the difference may have to do with screen resolution which is 1024 by 768
on this PC, different than Johan's)

With OOo 2.3.1 on a Turion 64 X2 Mobile, 792 MHz, 2GB, no virus checker, 1280 by
800 pixels, the movement appeared acceptable, but the "customer" bubble wound up
a bit too much to the left and some onions bounced behind boxes. 

Correction: I looked another time and in 00o 2.4 as well, the "customer" bubble
winds up slightly too much to the left.

hm. might be that CWS presfixes12 caused this. please refer to issue 75315 on
how to disable the z order thingie temporarily - does that fix your performance
problems?

Yes, this fixes the problems on 2.3 and 2.4!

And the rest is silence...
What does this SlideshowRespectZOrder property do?
Why was it introduced?
What is the effect of setting it to 'false'?
What are the other effects of setting it to 'false'?
If there are none, why is SlideshowRespectZOrder default 'true'?
And so on, and so on...

@jvromans: sorry, not wanting to leave you in the dark. Quote from Impress.xcs:

<prop oor:name="SlideshowRespectZOrder" oor:type="xs:boolean">
	<!-- OldPath: -->
	<!-- OldLocation: -->
	<!-- UIHints: Slideshow Z order for animations -->
	<info>
		<author>THB</author>
		<desc>Indicates whether the slideshow should respect shape z-order while
animating shapes. Disabling this can improve slideshow performance</desc>
		<label>Enable shape z-order during slideshow animations</label>
	</info>
	<value>true</value>
</prop>

What this means: if you have this enabled, and there's a bunch of shapes on your
slide that are visibly stacked (i.e. slightly overlapping, such that one can
discern which ones are in front of others), and you have one of those shapes
being more in the background animated, the animated shape will remain _behind_
the other shapes (this is the visually correct way to do it, and it's how other
presentation packages implement that). If you _disable_ this, animated shapes
will always be in the foreground, disregarding their z order. Depending on
content and platform, this can be faster, as there's less to render and less to
buffer in background pixmaps.

Generally, things are slower, but not as bad as you describe (see also simonbr's
comments) - this is prolly triggering a worst-case scenario in your X server.
And anticipating something like that, I've added this config item, such that
people can switch back to the old behaviour.

@all: can somebody else confirm this on ATI hardware?

Thanks for the explanation. The way you describe it, this feature seems to be
intended to speed things up. What keeps puzzling me is that, in reality, it
slows down.
When I disable the feature, performance of 2.3 and 2.3 is the same as with 2.2.
With the feature enabled, which it is by default!, performance is slower.
That makes me really wonder why this feature was implemented in the first place,
and --even more-- why it is enabled by default.

@jvromans: nope, this feature was not implemented to speed things up, but to
display animations correctly. In fact, I expected this feature to slow things
down moderately for a few cases (and not at all for simple cases) - and slow
things down considerably for corner cases. You've hit a corner case, and exactly
for people like you I've made this a configurable setting. ;-)

@@all: can somebody else confirm this on ATI hardware?

I see the same behaviour on nVidia, so its not ATI specific.

As a final remark, I hate to have to say that most slide and paragraph animation
effects look ugly due to non-fluid movements, even on very fast hardware with
very much memory and screaming video cards. In fact, the only effect that is
safe to use in a professional presentation is a simple "Appear". 

@jvromans: is this affected by the respectZorder setting?

No, it is independent of the new Zorder hack.

Set to new and change the target.

The performance of the custom animations is really bad.
I tested it with dev300m6.
Please have a look if we can improve the performance.

since we do not have a replacement for thb yet I have to retarget this

Sorry I have to complain, but 3.x ...
I'dd rather not advice the managers/executives employed by OOo-using companies,
to install an older version for giving presentations :-(

@cornouws: you experience this as well?

at any rate, fixing this for 3.0 is pretty easy (although killing the z order
fix again, but something's gotta give) - just change the default value in the
configuration. We can even consider doing that for Linux only.

But I'd first of all like to know the real impact of this regression - how many
people/installations are possibly affected?

@thorsten: Yes, but not severe - setting the ZOrder-prop to false doesn't make
much difference.
My comment is also motivated by the reports from the others and from other
moments that I experienced that the animations in my own presentations are not
reliable.

Also the fact that the "customer" bubble winds up slightly too much to the left
(reported by simonbr first) is a problem. This does not improve with the ZOrder
setting, only by changing the type of animation. (So probably another issue).

You ask (rightly) "how many people/installations are possibly affected?" 
I don't know. Looking at the OOo-forum, you see some expression that support the
feeling of 'we have a problem here'.

Is there a good reference presentation for testing (including explanation on
what results are supposed to bee shown)?

@cornouws: If I get you right, you don't see a "serious regression" in graphics
performance across the board, but a persisting lack of animation speed (since a
number of OOo versions)?

This would be my perception as well, especially for Linux. But that's nothing we
can possibly fix in the (all too short) 3.0 time frame.

@thb: correct: I can't say the regression I see is serious. But since the
performance wasn't that good to start with ... less fluent movements are no good.
BTW: I see no difference between the Linux and Windows versions I have at hand.

With OOo 3.0 the graphics performance has detoriated further. Even with the
"SlideshowRespectZOrder" hack applied the performance is untolerabely slow.

@jvromans: could you elaborate? Again ~everything slower, or something specific?
Note that issue 93945 might be related, it ups framerates again.

2.2: Acceptible, smooth performance, moving objects end up at the right locations.
2.3: Stuttering performance, moving objects do not end up at the right locations.
2.3: w/ SlideshowRespectZOrder: Acceptible, as in 2.2.
2.4: same
3.0: w/ SlideshowRespectZOrder: As 2.3 without the SlideshowRespectZOrder hack.

These are observations.

cl->af: If it is not related to the z-order switch, maybe it is actually the
timing problem you are working/worked on?

With the changes I have made for issue 93945 and issue 94193, the animations
look a lot smoother.

The two issues are fixed in cws impress162 and are scheduled to be integrated
into OOo 3.1.

I can still see the problems of the z-order rendering and the wrong location of
the "customers" shape on slide 1.  There still is a lot of work to do.

Reset assigne to the default "issues@openoffice.apache.org".