Issue 106432 - Presentation mode shows 1st slide black on x86 with m2
Summary: Presentation mode shows 1st slide black on x86 with m2
Status: CONFIRMED
Alias: None
Product: Impress
Classification: Application
Component: ui (show other issues)
Version: OOO320m2
Hardware: All Solaris
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-10-29 13:21 UTC by wolframgarten
Modified: 2017-05-20 11:08 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this issue.
Description wolframgarten 2009-10-29 13:21:54 UTC 
On the new x86 sunRay server start the OOO320_m2 in
.../openoffice-versions/interim-versions/ooo320/latestoffice. Take an impress
with 2 slides. At least after the 2nd start the first slides comes up completely
in black, second slide works. does not depend upon the slide content.
Comment 1 groucho266 2009-10-30 16:31:32 UTC 
May be related to issue 81368.
Comment 2 groucho266 2009-11-04 10:01:01 UTC 
The black screen is caused by a call to SlideshowImpl::onFirstPaint(), which
cames at an unfortunate time: the slideshow has already painted its background
and then painted it on the screen.  After that the canvas paints only areas that
have changed (like the little clock symbol in the lower left).  The
onFirstPaint() method is called after that, probably because the full screen
window of the slide show has become visible.  All the, up to this time, correct
window content is erased.  The screen becomes black.

This looks like a timing problem.  That it is reproducible only on x86 SunRay is
just a coincidence.

There are several ways to fix this.  One is not to paint the screen black at
all.  This would also remove the flickering on the start of the slide show
(screen is painted white, then black, then with the background of the first slide).
Comment 3 thb 2009-11-04 12:14:05 UTC 
Hmmm - so, this is how this is supposed to work: SlideShowView::paint() FWIK is
where all screen refresh events are signalled to, so it's quite surprising that
someone else called slideshow's SlideView::paint()/SlideView::update() - that
would be the first thing to check, where that call is coming from on your sunray
setup.

Regarding the amount of painting on startup - sd is responsible for the whole
window background, see also the SlideShowView's clear() method - so FWIR, the
reason to actually paint to the _vcl_ window in the first place was to avoid the
flicker (vcl paints white by default), and the slideshow sometimes took a
noticeable moment to come up with the slide content - but then again, maybe just
disabling the vcl white paint would be the better idea.

Messy place to be actually, and FWIW also a constant source for pain in the old
slideshow ...
Comment 4 thorsten.ziehm 2009-11-12 08:14:35 UTC 
Change the target of this issue to OOo 3.3 (like all other issues in CWS slideshow2.
Comment 5 groucho266 2010-07-07 16:16:06 UTC 
Changing target.
Comment 6 Martin Hollmichel 2011-03-15 11:06:55 UTC 
set target to 3.x since they are not release relevant for 3.4
Comment 7 Marcus 2017-05-20 11:08:18 UTC 
Reset assigne to the default "issues@openoffice.apache.org".