Bug 34533 - intermittent blank first slide ...
Summary: intermittent blank first slide ...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
3.3.1 release
Hardware: Other All
: medium critical
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 34404
  Show dependency treegraph
 
Reported: 2011-02-21 07:12 UTC by Michael Meeks
Modified: 2011-03-02 00:34 UTC (History)
0 users

See Also:
Crash report or crash signature:


Attachments
fix for libreoffice-3-3 (1.06 KB, patch)
2011-02-22 02:03 UTC, Michael Meeks
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Meeks 2011-02-21 07:12:29 UTC
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.
Comment 1 Michael Meeks 2011-02-22 02:03:17 UTC
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.
Comment 2 Michael Meeks 2011-02-22 03:26:53 UTC
fix committed to libreoffice-3-3, should be in 3.3.2.
Comment 3 Yifan Jiang 2011-03-02 00:34:39 UTC
Verified on SLED 11 and SLED 10.