Priority changed. Can you add a few examples which ones are "jerky"? Thanks in
advance.
Reassigned.

So far all of them are, in both previews and slideshows. It
is most obvious when it goes to slide one from a blank screen.
A sample would show you nothing that you can't see already. I
doubt it could be a problem with this machine. It has very
good graphics performance with every program ever run on it.

It looks like the effects are done by copying small portions
of the next slide to the screen. This often makes edges appear
ragged during transitions. I suppose that approach might have
been taken to accommodate machines with little RAM and older
video cards. It doesn't do so well here though.

I did check on the web and found a post from someone else
having this problem with version 1.1.4.

I tried to get a screenshot of the ragged edges, but couldn't so far.
I found two other posts on the web today saying that the slide shows 
are jerky.

Hi,

I too am having the problem with jerky slide transitions in impress in the OOo 2
beta. The screen seems to flicker as the old slide stays in view while the next
one is loading up.  I have a Windows XP Home SP2 laptop, with 256 megs of ram
and an ATI 7500 mobility graphics card.  The CPU is a Pentium 4 2.0 Mhz.  

I have played with the memory settings in OOo, but none seemed to make any real
difference.

Please ask if you want any more info. (I also have OOo 1.1.3 on my system and
the slide shows run perfectly - if that is any help - if nothing else, it
demonstrates that my box is able to run slide shows without any problems)

set to new.

I think with the transition wipe Left or wipe right you see the jerky behaviour.
Please have a look if we can make the transitions a bit softer.

General performance should be much improved for CWS presfixes03 (should get
integrated into m94 or somesuch - will try to note that here, then).

What's left is especially the slide wipe performance that's lacking, because the
screen update algorithm is up 'till now a lot dumber than for OOo1.x: most of
the time, I copy the whole screen to the front, instead of only the small area
that's changing for the wipe. The jaggies folks are seeing are just display
artifacts (aka 'tearing'), it's the screen's raster scan beam being faster than
the blit to the screen, such that the monitor displays the new content in the
upper part, and the old content in the lower part of the screen (thus, vertical
wipes should look better).

Some user feedback.

Just installed OOo_1.9.95 and tested Impress. Slideshow transitions are now
functioning smoothly when a .odp file is used. At first I used a Powerpoint file
- but the transitions - while much better than with the Beta build - still ran
jerkily. I saved the same document as a .odp file and tried out the slideshow
again - and it ran fine - very, very slightly jerkily - but not enough to be
irritating IMHO.  

I did not change any settings in OOo, just left everything at default and I have
not changed anything else system-wise since installing the Beta build.

@allroad: That's encouraging to hear. I have currently no idea about the
different behaviour between ppt and odp; maybe the second run of the ppt, or
another run after a reload, would have resulted in the same, acceptable performance?
Generally speaking, we should now store ppt's animations and slide transitions
literally as-is in odp, or, to be more precise, exactly as we've _imported_ the
ppt. Thus, that difference in behaviour currently escapes me; you should
consider adding those two documents to this issue.

Created attachment 25457 [details]
Original .ppt file imported into Impress

Created attachment 25458 [details]
.odp version of .ppt file with the same name

Created attachment 25459 [details]
.ppt file used for slide show testing in Impress

thb, I've just been experimenting with .ppt and .odp files - the .odp is a .ppt
file saved as .odp.  As a .ppt file, the slide show runs fine.  The .odp slides
ran OK until I got to the 11 or 12th of the 20 or so slides, then the slideshow
slowed down a lot and became very jerky.  To attempt to resolve this I went into
Ooo Tools>Options Openoffice.org View and selected Use OpenGL and Object refresh
during interaction: Result-the odp slideshow ran as well as the ppt original. 

Note: I then de-selected Object refresh during interaction and reran the odp
slideshow with results very close to those of the original ppt file - ie fine. 
odp files would seem to prefer OpenGL.  I did not select use Optimized output
under the Use OpenGL option.  I have attached both files for you to experiment
with. Whoops! Attached the .ppt file twice.

Final thing. MS Office 2000 was used to create the original .ppt file.

@mbu: Please use this issue for your performance improvements.

restricted update area for clipped sprites to the affected area, instead of
submitting the complete sprite area.

set target to OOo 2.0 after QA approval by TZ

.

re-open issue and reassign to cgu@openoffice.org

reassign to cgu@openoffice.org

*** Issue 48070 has been marked as a duplicate of this issue. ***

I'm running an Athlon XP @ 2.0 GHZ with a gforce fx 5900xt and have the same
problems when running in Open GL mode.  While issues I had with the fade
transition (ie, the transition would occur twice) have been cleared up, some
things with the box transition for example show which splashes in the black area
as the transition occurs.  When in non-opengl mode, it runs fine, but is
slightly slower.  Compared to MS Powerpoint, it is still slower when viewing
virtually every transition but has improved a long ways over the past few builds
(last build I did this to was 19.m91 so I will see if m95 improves this)

I just checked the fade transition and it still runs slower in impress than it
does in powerpoint without graphics accelleration but when graphics acelleration
is enabled in powerpoint, powerpoints transition are much, much smoother.
The box transition problems I had are solved since m91 as well.  If the effects
can be opengl accellerated or improved in performance so that they run smoothly
at 1280x1024, Impress will be one step closer to being the better presentation
engine and creation tool.

I correct the status of this task => resolved/fixed

Verified in cws presfixes06

*** Issue 45196 has been marked as a duplicate of this issue. ***

Integrated in src680m106