710186 - Poor performance while dealing with transparent elements (CSS) with hardware acceleration on Windows

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect)

Description

[Aleksander Nowodziński]

Attachment: A page for testing purposes

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20100101 Firefox/8.0
Build ID: 20111104165243

Steps to reproduce:

OS: Windows 7 Professional 32 and 64 bit (two different ones)
PCs: 
- Athlon X2 3.0, 4GB RAM, NVidia 9600GT
- Intel Core2Duo 1.4, 2GB RAM, Intel GM945

Problem: On both PC's Firefox is extremely slow while hovering an array of transparent elements (opacity < 1) with :hover opacity set to 1.

1. Open sample bug minefield http://nowodzinski.pl/pub/ff8opacitybug.html (also in attachment)
2. Resize the browser window to see the whole page
3. Move cursor over some elements of an array



Actual results:

1. The browser doesn't follow the hover under the cursor.
2. The faster the cursor moves, the delay grows. Some of the elements are even omitted.
3. The more transparent elements are visible on the screen, the worse is the performance (try reducing windows size to see the difference)
4. High CPU usage 

*This performance bug disappears if using Linux OS*
*This performance bug disappears if using e.g. border-color as :hover. It is strictly an opacity-related bug"


Expected results:

1. Each element of an array should get opacity: 1 immediately when hovered.
2. There should be no hover delay
3. The delay (if any) should be screen-size independent

Comment 1

[Marek Raida]

It is related to HW acceleration. 
I see the same issue on HW accelerated NVidia card / Layers, after switching it off, it becomes much much better...

Comment 2

[Aleksander Nowodziński]

(In reply to Marek Raida from comment #1)
> It is related to HW acceleration. 
> I see the same issue on HW accelerated NVidia card / Layers, after switching
> it off, it becomes much much better...

I've already tested it on laptop with integrated Intel card. The result is exactly the same. However if running ff8opacitybug.html on linux OS (the same PC) - there is no problem. Therefore I suppose it isn't strictly hardware-related.

Comment 3

[Matthias Versen [:Matti]]

confirming with  Mozilla/5.0 (Windows NT 6.1; rv:11.0a1) Gecko/20111212 Firefox/11.0a1 SeaMonkey/2.8a1 and a GeForce 310M

This works fast in Opera11 on the same system

Comment 4

[Alice0775 White]

Tested with force HWA enabled.
user_pref("mozilla.widget.render-mode", 6);
user_pref("gfx.font_rendering.directwrite.enabled",true);
user_pref("gfx.direct2d.force-enabled",true);
user_pref("mozilla.widget.accelerated-layers",true);
user_pref("layers.accelerate-all", true);
user_pref("layers.use-d3d10", true);

Cannot reproduce:
http://hg.mozilla.org/mozilla-central/rev/92339b84d089
Mozilla/5.0 (Windows; Windows NT 6.1; WOW64; en-US; rv:2.0b2pre) Gecko/20100715 Minefield/4.0b2pre ID:20100715145415
Reproduce:
http://hg.mozilla.org/mozilla-central/rev/e1d7fd5255fd
Mozilla/5.0 (Windows; Windows NT 6.1; WOW64; en-US; rv:2.0b2pre) Gecko/20100715 Minefield/4.0b2pre ID:20100715152722
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=92339b84d089&tochange=e1d7fd5255fd

Comment 5

[Alice0775 White]

In local build:
built from d290d2b97416 : can reproduce
built from 047895d6fda3 : cannot reproduce

Triggered by landing of
d290d2b97416	Robert O'Callahan — Bug 564991. Part 25: Introduce a 'has active layers' flag on frames, which times out, and use it for 'opacity'. r=mats,sr=dbaron

Comment 6

[Attila Soki]

this issue still exists on mac os x.
Firefox uses 100% CPU while moving the mouse over the elements.

Firefox 13.0a1 (from 2012-02-23)
OS X 10.6.8
MacBook Pro 2.66 Core i7

Graphics
        Vendor ID
        0x10de

        Device ID
        0x a29

        WebGL Renderer
        NVIDIA Corporation -- NVIDIA GeForce GT 330M OpenGL Engine -- 2.1 NVIDIA-1.6.40

        GPU Accelerated Windows
        1/1 OpenGL

        AzureBackend
        quartz

Comment 7

[(mostly gone) XtC4UaLL [:xtc4uall]]

While I can repro the Issue on Firefox 18/19/20, Nightly is WFM. Tested on Win7 though so others should check against MacOS/Linux.

Comment 8

[Attila Soki]

no change on mac. testcase still using 100 % cpu (one core)

FF 21.0a1 (2013-01-24)
Mac OS X 10.8.2
HW: MacBook Pro 2.66 Core i7, NVidia GT330M & Intel HD Graphics
tried with both GFX Cards, found no difference, CPU is 100% while moving the cursor.

Comment 9

[Alice0775 White]

I can reproduce the 100% cpu usage while moving the mouse over the elements in Nightly21.0a1 with clean profile.
.
http://hg.mozilla.org/mozilla-central/rev/98ea4d294369
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20130124 Firefox/21.0 ID:20130124054158

  Graphics

        Adapter Description
        ATI Radeon HD 4300/4500 Series

        Adapter Drivers
        aticfx64 aticfx64 aticfx32 aticfx32 atiumd64 atidxx64 atiumdag atidxx32 atiumdva atiumd6a atitmm64

        Adapter RAM
        512

        ClearType Parameters
        Gamma: 2200 Pixel Structure: RGB ClearType Level: 50 Enhanced Contrast: 50

        Device ID
        0x954f

        Direct2D Enabled
        true

        DirectWrite Enabled
        true (6.1.7601.17789)

        Driver Date
        11-16-2012

        Driver Version
        8.970.100.7000

        GPU #2 Active
        false

        GPU Accelerated Windows
        2/2 Direct3D 10

        Vendor ID
        0x1002

        WebGL Renderer
        Google Inc. -- ANGLE (ATI Radeon HD 4300/4500 Series)

        AzureCanvasBackend
        direct2d

        AzureContentBackend
        direct2d

        AzureFallbackCanvasBackend
        cairo

Comment 10

[(mostly gone) XtC4UaLL [:xtc4uall]]

Arrg, now *I* didn't pay Attention: this is WFM with HWA off (GDI/Cairo), but that is the Case in Firefox 8 too. With HWA on it's still janky ....
Sorry about the Noise :-/.

Comment 11

[Markus Stange [:mstange]]

This is a great testcase. We redraw most of the page when a single box is quickly hovered and then unhovered, which makes it good for testing drawing performance.

I haven't profiled it on Windows yet, but I think the two problems are:
 - PushGroupAndCopyBackground is slow with D2D (Bas is working on improving that)
 - The rounded rectangles are drawn with a rounded clip + rectangular fill, instead of a rounded path fill.

Comment 12

[Markus Stange [:mstange]]

(In reply to Markus Stange [:mstange] from comment #11)
> We redraw most of the page when a single box is quickly hovered and then unhovered

This is because we layerize the opacity too eagerly (bug 1217748), which causes the rest of the page to be lifted into a different layer. This is the sole reason why the testcase is a little slow on OS X (though much less so than with D2D).

Comment 14

[Guilherme Lima]

I say this is WFM on Win7 with HWA on Nightly.