User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:18.104.22.168) Gecko/20070309 Firefox/22.214.171.124 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.9a5pre) Gecko/20070520 I've created a simple page using both XUL and XHTML elements. I've added some hover effects with CSS. The performance is acceptable with Firefox 126.96.36.199 but very slow with current XULRunner nightlies. I've created a testcase http://www.birgin.de/test/bugzilla/welcome/welcome.xul Hover over the yellow buttons and the text below. The hover effect is delayed by nearly half a second on a 2,2 Ghz AMD winXP machine! Reproducible: Always
dito on Mac: ------------ fast hover with ancient: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414 snail hover with actual nightly: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a5pre) Gecko/20070526 SeaMonkey/1.5a So there is somewhere a platform independent performance relevant regression.
As I said in the newsgroup, it would be helpful to figure out the regression window. Also, it might help to have a minimized testcase (preferably as a bugzilla attachment, since otherwise there's a chance the testcase will be gone by the time someone will need it).
Summary: Performance XUL and XHTML → performance regression with XUL and XHTML
BTW, are you testing trunk and 2.0.0.x on the same machine? Sometimes there are hardware-dependent gfx bugs - f.e. the testcase is very slow even here on a 188.8.131.52 build (WinXP, athlon 1.47Ghz, Matrox Millenium G450 display adapter).
The Mac tests are done on the same machine and the Windows tests of Daniel are made on an other machine but both test on the same other machine.
I didn't see any observable performance problems using the latest trunk. Can you provide a better testcase?
I can still reproduce the problem with the latest trunk nightly although performance is much better compared to the current 3.6 release and the delay is very low now. The problem seems to be caused by a stretched image beeing positioned behind elements that change their font-weight on hover. The bug seems not to be related to XUL as a testcase provides similar results in html only.
Created attachment 424792 [details] Testcase The testcase shows the problem when hovering over the elements on the left. They are highlighted with a short delay. The elements on the right highlight immidiately. The difference is, that they don't change their font size. The delay is hard to see with the latest trunk on a fast machine but is still recognizable.
Maybe Jeff can help us here?
When we hover over the bolding items, we reinvalidate the entire page. Presumably the scaled image makes this slow. On OS X we also seem to be rescaling the image each time as well. We can probably do better...
Status: UNCONFIRMED → NEW
Ever confirmed: true
The regression range seems to be: 2007-01-27 works 2007-01-28 shows delay Tested with the trunk nightlies
This isn't slow for me any more, perhaps due to layers? My CPU isn't even 2.2GHz!
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Yes, seems to work again. Thanks for the update!
You need to log in before you can comment on or make changes to this bug.