See profile data in metabug tracking this bug. Basically, 2/3 of the viewmanager time is spent in/under this function. The main callers are nsWindow::Invalidate and nsViewManager::AddRectToDirtyRegion. Is there anything we can do to speed up this code short of calling it less? If not, can we call it less?

gtk2 or gtk1.2? And is it CPU time or waiting time?

gtk1. Almost all of the time is spent under gdk_region_union_with_rect, which ends up calling through to XIntersectRegion. The time there seems to be mostly spent in malloc (1/8) and the function itself (7/8). So CPU time, not waiting time. Bug 243726 has some thoughts on just reducing the number of calls we make to nsRegionGTK::Union. So maybe that will help, but I figured I'd file this bug too, just in case we can make Union() itself faster too.

Note that with the patch in bug 243726 we almost never call this anymore, because we switched from nsIRegion to nsRegion for the dirty region...

Is this obsolete then?

All I know is we no longer hit this code on that testcase. I don't know what other circumstances may hit this code; the resolution of this bug is up to the module owner now.

GTK1 has been removed on trunk. Please file a new bug if you see this in a recent trunk build. -> WORKSFORME

This is a problem with GTK2 as well, so just because GTK1 is done doesn't mean it's "worksforme".

The test case no longer exists as far as I can tell. Also, there is no longer any such thing as nsRegionGTK. The only remaining call to gdk_region_union_with_rect is in widget/src/gtk2/ nsWindow::SetWindowClipRegion, which appears only to be called from nsWindow::ConfigureChildren, which in turn appears only to be called for stuff to do with plugins. Given all that, I doubt it is still a performance bottleneck, but I'm going to kick this over to Widget:Gtk and leave it open, in case somebody knows different. (If the now-generic ns(I)Region/ns(I)ScriptableRegion code is a performance bottleneck, perhaps a new bug should be filed.)

> The test case no longer exists as far as I can tell. Updated link.

> Updated link. Thanks. Do you happen to remember whether this was about the "replace 1500 images as fast as possible" test, which is the only one that's still slow with my FF8?

It was about the "move the multicolored text around" test.

Hm. That one's not as fast as Chromium on this computer but not visibly slow (.7 seconds or so). I'm kinda thinking this bug should be closed, but I'll let you make the call.

Would need to profile on Linux to say anything useful....

not necessary anymore so please close it