Bug 104363

Summary:	desktop-background properties performance ...
Product:	[openSUSE] SUSE LINUX 10.0	Reporter:	Michael Meeks <mmeeks>
Component:	GNOME	Assignee:	E-mail List <gnome-bugs>
Status:	RESOLVED FIXED	QA Contact:	E-mail List <qa-bugs>
Severity:	Normal
Priority:	P5 - None	CC:	federico
Version:	Beta 1
Target Milestone:	---
Hardware:	Other
OS:	All
Whiteboard:
Found By:	Other	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

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.