Issue 105354 - No images on 1st slide after open
Summary: No images on 1st slide after open
Alias: None
Product: Impress
Classification: Application
Component: open-import (show other issues)
Version: OOO310m11
Hardware: All All
: P3 Trivial (vote)
Target Milestone: ---
Assignee: groucho266
QA Contact: issues@graphics
Depends on:
Blocks: 99999
  Show dependency tree
Reported: 2009-09-25 11:41 UTC by matthias.mueller-prove
Modified: 2017-05-20 10:06 UTC (History)
3 users (show)

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

this shows how my document looks after opening (255.46 KB, image/jpeg)
2009-09-25 11:42 UTC, matthias.mueller-prove
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description matthias.mueller-prove 2009-09-25 11:41:11 UTC
When I open my presentation in OOo 3.1.1 the images on the title slide do not
load (see attachment). When I move forward and backward the images show up.
Comment 1 matthias.mueller-prove 2009-09-25 11:42:32 UTC
Created attachment 64965 [details]
this shows how my document looks after opening
Comment 2 wolframgarten 2009-09-28 10:18:35 UTC
Reproducible. Pictures in the first page do not get displayed completely.
Comment 3 clippka 2009-10-05 12:55:49 UTC
the actually get painted correctly but it takes some time.

QueueProcessor::ProcessRequests() loops over all slides and hinders the repaint
timer to execute until all slide previews are rendered.
Comment 4 matthias.mueller-prove 2009-10-05 13:50:12 UTC
no update after 1 hour /270 slides
Comment 5 groucho266 2009-10-05 15:46:20 UTC
QueueProcessor::ProcessRequests() has two guards that should prevent it from
blocking the edit view from, well, anything.  Both of which are not triggered
anymore due to changes outside the slide sorter in the not so distant past:

1) The ProcessRequests() method tries to detect in every loop whether the system
is idle.  If not then it exits immediately without creating any preview.  This
is not triggered because the pending loading of images into the edit view is not

2) When the queue contains only entries for slides that are not visible in the
slide sorter then this entries are processed on at a time.  This is not
triggered because the slide sorter pane that created the requests marked all
previews as being visible.

What makes all of this worse is that the slide sorter pane now requests previews
for all slides, not just for the ones.
Comment 6 groucho266 2009-10-05 16:35:07 UTC
Fixed by leaving QueueProcessor::ProcessRequests() after every preview creation.
 This means that there will be situations where previews could be created faster
but will not be.  But the time between subsequent calls to ProcessRequests() in
these situations will not be much longer than 10ms and therefore should not be a

SVN revision of this change is 276691.
Comment 7 groucho266 2009-10-19 10:38:00 UTC
@wg: Please verify.
Comment 8 groucho266 2009-10-19 10:40:14 UTC
Changed owner.
Comment 9 wolframgarten 2009-10-20 13:31:57 UTC
Verified in CWS.
Comment 10 Raphael Bircher 2010-02-08 17:25:18 UTC
Tested with OOo 3.2.0 on Mac OS X 10.5.x works fine

close issue
Comment 11 matthias.mueller-prove 2010-04-14 15:54:56 UTC
Not fixed in MacOOo 3.2.0 (m12 Build 9483) -- waiting for 10 minutes now
Comment 12 matthias.mueller-prove 2010-04-14 16:02:46 UTC
adjust target
Comment 13 wolframgarten 2010-07-05 14:17:30 UTC
Reassigned. Background image of slide master gets not displayed in m84.
Comment 14 groucho266 2010-07-13 16:26:42 UTC
I can still not reproduce this.

There is a good chance that this problem will go away as soon as CWS
renaissance1 is integrated.  The slide sorter has undergone a major
restructuring in that CWS.  For example not all previews are created at once. 
Only the visible ones are.

So, changing target and waiting for integration of CWS renaissance1.
Comment 15 Martin Hollmichel 2011-03-15 11:06:49 UTC
set target to 3.x since they are not release relevant for 3.4
Comment 16 mdxonefour 2011-03-15 11:17:49 UTC
Works for me in a DEV300 m102.