performance regression with XUL and XHTML




12 years ago
3 years ago


(Reporter: daniel, Unassigned)



Windows XP

Firefox Tracking Flags

(Not tracked)




(1 attachment)



12 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv: Gecko/20070309 Firefox/
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 but very slow with current XULRunner nightlies. I've created a testcase

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


12 years ago
Version: unspecified → Trunk

Comment 1

12 years ago
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. 

Comment 2

12 years ago
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).
Keywords: regression
Summary: Performance XUL and XHTML → performance regression with XUL and XHTML

Comment 3

12 years ago
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 build (WinXP, athlon 1.47Ghz, Matrox Millenium G450 display adapter).

Comment 4

12 years ago
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. 

Comment 5

9 years ago
I didn't see any observable performance problems using the latest trunk.  Can you provide a better testcase?
Keywords: testcase-wanted

Comment 6

9 years ago
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.

Comment 7

9 years ago
Created attachment 424792 [details]

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.

Comment 8

9 years ago
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...
Ever confirmed: true

Comment 10

9 years ago
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!
Last Resolved: 8 years ago
Resolution: --- → FIXED

Comment 12

8 years ago
Yes, seems to work again. Thanks for the update!
Keywords: testcase-wanted
You need to log in before you can comment on or make changes to this bug.