Bug 104363 - desktop-background properties performance ...
Summary: desktop-background properties performance ...
Status: RESOLVED FIXED
Alias: None
Product: SUSE LINUX 10.0
Classification: openSUSE
Component: GNOME (show other bugs)
Version: Beta 1
Hardware: Other All
: P5 - None : Normal
Target Milestone: ---
Assignee: E-mail List
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-08-12 11:44 UTC by Michael Meeks
Modified: 2006-02-16 09:23 UTC (History)
1 user (show)

See Also:
Found By: Other
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---

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

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Meeks 2005-08-12 11:44:08 UTC 
On my machine the gnome-desktop-background-properties dialog took 10-15 seconds
to start - the last 10 or so of which I had a visible, but mangled-looking
partially rendered window.

It was substantially faster the 2nd time - quite probably the thumbnailing &
(worse) seeking to find the desktop backgrounds is the problem.

Why is that not asynchronous ?
Comment 1 Mark Gordon 2005-08-24 22:02:32 UTC 
Less mangled lately; the window itself is rendered just fine for me, while it
waits to load/thumbnail the images.  Or is that what you mean by mangled? If
that is what you mean by mangled, isn't that asynchronous enough for you? Or is
it that you want the images rendered one at a time as they become available? I'm
seeing them all at once, once they arrive.
Comment 2 Michael Meeks 2005-08-25 10:02:11 UTC 
Hi Mark, I want to have a responsive window that (re-)renders it's contents
while the (substantial on cold-start) delay of thumbnailing the backgrounds happens.
ie. this means the thumbnailing needs to either happen in a background thread
asynchronously, or - that some incremental, idle load thing needs to happen I guess.
Comment 3 Michael Meeks 2005-08-25 15:16:30 UTC 
to see the issue - just obscure the window forcing a re-paint while it's doing
the  slow load (ones instinct when anything is slow anyhow: switch desktop).

One rather simple fix would be to make the toplevel window insensitive while
loading, add a progress bar - and just spin the gtk+ mainloop a bit after
thumbnailing each image (and update the progress bar).
Comment 4 Federico Mena Quintero 2005-09-22 15:41:47 UTC 
Are you sure this is not a duplicate of bug #117163?  That one is the
"repainting the desktop is slow" bug.
Comment 5 JP Rosevear 2006-01-24 21:26:59 UTC 
I cannot reproduce this problem.  Michael, are you still seeing it?
Comment 6 JP Rosevear 2006-02-16 04:25:50 UTC 
Michael?  The latest gtk2 should contain a fix for bug 117163.

* Fri Feb 03 2006 - federico@novell.com
- Added gtk2-117163-cairo-repeat-pattern-workaround.diff as a fix for bug #117163.
  In this bug, the desktop gets repainted very slowly due to bugs in Cairo and XRENDER.
  The workaround uses a faster code path in GTK+.
Comment 7 Michael Meeks 2006-02-16 09:23:05 UTC 
well - it was fast for me this time :-) possibly it was something unrelated last time.