Apache OpenOffice (AOO) Bugzilla – Issue 80363
cws dxliberate01: Delayed preview of Animations and Transitions
Last modified: 2017-05-20 11:08:53 UTC
With cws dxliberate01 a delay in preview of custom animations and slide transitions has been introduced. To reproduce: - create an empty presentation - draw any object (e.g. square) at the first slide - select the object and apply a custom animation (e.g. venetian blind) - press "Play" button for the custom animation -> There is a short delay (2-3 Seconds) before the preview is played. This problem depends on the installed hardware and drivers. We've seen this problem on ATI X1400, ATI X1650 and NVIDIA GeForce3 Ti200 cards. Older cards (Radeon 9000, X300) seem to work. I could track down the problem on my own system to the ATI driver option "Sync to vertical Blank" if this is set to "Always" all is ok. If this is left at "wait for Application" (what is the default), the delay ocures.
On my system (NVIDIA Geforce3 Ti 200, WinXP Home) the error depends on the hardware acceleration settings in Tool > Options > OOo > View. Is it checked, I get a delay till the window change to preview. Then the effect is not played automatically. The effect only plays, if I move the mouse inside the preview. Moving is necessary, only placing the mouse inside the preview is not enough. When I uncheck hardware acceleration, then the preview works, but slide transition has other errors. With hardware acceleration checked the slide transition starts with a delay, the next transitions are OK then. When uncheck hardware acceleration, the presentation starts immediately, but the slide transitions are not smooth.
Taking the issue. Well, we've had similar problems before, that could be tracked down to the fact that some drivers , when asked for certain information, perform an internet connection (or at least try to). I'm not sure this applies here, since especially the behaviour regina describes sounds decidedly weird. Could all of you who see this issue check the following: is the effect one-time only, i.e. do subsequent previews or slideshows in the same office instance show up quicker? Is there any difference in behaviour between window-mode and fullscreen slideshow (select window mode in Slideshow->Slideshow Settings)? And finally: there are actually _two_ DirectX-based canvas implementations now, one using the age-old DirectX5 API, and another based on DirectX9. You can force OOo to use _exactly_ one of those by various ways, the simplest being to move/rename all of the following dlls in the <office>/program dir: directxcanvas.uno.dll (DX5), directx9canvas.uno.dll (DX9) and vclcanvas.uno.dll (the VCL-based, old implementation) _except_ the one you want to test against. Does selecting either the DX9 or DX5 variant make any difference here?
I guess at least the behaviour as reported by regina would be a stopper for CWS dxliberate01...
for me the behaviour is visible for all previews in a office instance (every time I klick on play I see the delay). The delay is independent from Windowed or Fullscreen mode. (The delay ocures at the start of the presentation. Once the presentation has started, all other effects are without delay) Only directx9canvas.uno.dll causes the delay (directx5 and vlc are ok)
Here my testing results: With directx9canvas.uno.dll: In full screen mode, delay for start of presentation; the following transitions have normal speed and they are smooth. In window mode normal start. Preview with delay in starting and effect after mouse movement as described. With directxcanvas.uno.dll: No difference between fullscreen mode and window mode. The start of the presentation is normal, the transitions are smooth. But those effects, which work on single letters have great errors. After finish the presentation, you can not scroll in the slide pane. Preview starts normal, but the effects don't play right. With vclcanvas.uno.dll: Presentation starts normal, but the transitions are not smooth. Preview starts normal. After finish the presentation, you can not scroll in the slide pane. Concerning driver: It's the NVIDIA driver version 5.6.7.3, date 07.04.2004
Besides being out of time for 2.4, I'd like to monitor this for some time before jumping to conclusions. For 2.4, dxcanvas support will be built-in (i.e. no extension necessary anymore), thus I'd expect a bit more feedback. Generally, one can of course disable HW accel, to avoid those issues. Specifically, one can blacklist certain devices (dxcanvas will then silently refuse working on those, falling back to vcl canvas). I'll announce details about this when 2.4 RCs are out.
A bit late, but still: here's a little howto for blacklisting a specific DirectX driver/card combination - http://wiki.services.openoffice.org/wiki/Canvas#Configuration I'll happily receive blacklist entries for 3.0 - fixing this issue here properly is unfortunately not possible in the 3.0 time frame, as I'd need to somehow centrally retrieve the driver info once during application start. Retargetting to 3.x
@af: Thanks for taking a look. I'd lean towards a wontfix here, there's really not much we could do; pulling dxcanvas during startup to hide this latency is surely also not really popular ...
Reset assigne to the default "issues@openoffice.apache.org".