Run a slideshow with a very simple title page slide - just some text eg. Press F9/escape/F9 rapidly. I get a blank screen. Adding some debug printfs I get: # working: displayCurrentSlide 0x9adb320 1 1 (slide 0) onFirstPaint - erase etc. 0x9adb7b0 updateHdl updateSlideShow updateSlideShow update => -1 # broken: startShow 0 0x9c02798 displayCurrentSlide 0x9c17718 1 1 (slide 0) updateHdl updateSlideShow update => 0 onFirstPaint - erase etc. 0x93033e0 updateSlideShow update => -1 updateSlideShow update => -1 The method at fault is onFirstPaint - which is called from the first VCL paint event that we get. Unfortunately, these paint events are delivered late, and (in this case) well after we have already got our 'slideshow' to render its contents to the same window. Thus, the maUpdateTimer has triggered just before the onFirstPaint event gets called; so we draw, and discard. Perhaps this only happens with extremely simple first slides though. So - we should not rely on VCL paint events appearing before our timeouts, that is not a given. I'll come up with a patch to defer the first-time screen blanking, to ensure it is truly done, only once, just before we render via 'update' - should be simple.
Created attachment 43639 [details] fix for libreoffice-3-3 Fix for libreoffice-3-3 - robust, I imagine there is just some event ordering issue here. On Unix I would expect to get a configure_notify_event - presumably mapped to some re-sizing event, before I got a paint event - and I assume this is what creates the race. In master, I'd like to defer sending any startUpdateTimer() call until we have got our first paint event, but this may be less reliable, so defer until then.
fix committed to libreoffice-3-3, should be in 3.3.2.
Verified on SLED 11 and SLED 10.