381358 - performance regression with XUL and XHTML

Status: RESOLVED FIXED

(Core :: General, defect)

Description

[Daniel Kirsch]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3
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 2.0.0.3 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

Comment 1

[Georg Maaß]

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

[Nickolay_Ponomarev]

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).

Comment 3

[Nickolay_Ponomarev]

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

Comment 4

[Georg Maaß]

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

[(no longer active)]

I didn't see any observable performance problems using the latest trunk.  Can you provide a better testcase?

Comment 6

[Daniel Kirsch]

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

[Daniel Kirsch]

Attachment: 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.

Comment 8

[(no longer active)]

Maybe Jeff can help us here?

Comment 9

[Jeff Muizelaar [:jrmuizel]]

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...

Comment 10

[Daniel Kirsch]

The regression range seems to be:

2007-01-27 works
2007-01-28 shows delay

Tested with the trunk nightlies

Comment 11

[Mike Shaver (:shaver emeritus)]

This isn't slow for me any more, perhaps due to layers?  My CPU isn't even 2.2GHz!

Comment 12

[Daniel Kirsch]

Yes, seems to work again. Thanks for the update!