Closed Bug 624090 Opened 14 years ago Closed 9 years ago

Slow css :hover opacity change

Categories

(Core :: Graphics, defect)

Product:
Core
Component:
Graphics
Platform:
x86
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 710186
Tracking Flags:
Tracking Status
blocking2.0 --- .x+

People

(Reporter: sancus, Assigned: bas.schouten)

References

(
URL
)

Details

(Keywords: perf, regression, Whiteboard: [softblocker][final?]) 

This page: http://www.riftrolebuilder.com/builder/?calling=mage has very unresponsive mouseovers in fx4 beta 8, perhaps some performance improvements can be gleaned from it!
It seems pretty much fine in Chrome 9 beta, so it's not *just* the developer being hurty.
Product: Firefox → Core
QA Contact: general → general
So steps to reproduce are to click on "Equip Archon" and then hover the little rectangles that appear as a result, right?
Yep
If so, then at least on Mac with GL layers (so take with a grain of salt in terms of Windows numbers, given where the time is spent!) I'm looking at:

  3% restyling and reflow
  3% handling the mouse events, running JS, etc
 92% painting (23% under PushGroupForLayer??, images, borders, backgrounds, etc)

Andrei, would you mind pasting the graphics section of your about:support in this bug?

Bas, what do things look like for you on Windows here?

If I disable GL layers, things are noticeably snappier in that the yellow border around the rectangle I hover draws pretty much immediately, but there's still a bit of lag to showing the little pop-up box.

I can't quite sort out what jquery's show() goop does, but I'm willing to assume it's not browser-sniffing or using timeouts less than 10ms or anything like that...
Component: General → Graphics
QA Contact: general → thebes
Adapter Description
NVIDIA GeForce 8800 GTS 512

Vendor ID
10de

Device ID
0600

Adapter RAM
512

Adapter Drivers
nvd3dumx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2um

Driver Version
8.17.12.5721

Driver Date
6-7-2010

Direct2D Enabled
true

DirectWrite Enabled
true

GPU Accelerated Windows
1/1 Direct3D 10
One other thing worth checking: does disabling hardware acceleration make things faster or slower for you?
I managed to figure out what, specifically, is causing the problem. It's an opacity change on the skill divs themselves.

tree.css (line 28):
div.soultree_container table td.active, div.soultree_container table td:hover {
    opacity: 1;
}
tree.css (line 22):
div.soultree_container table td {
    opacity: 0.2;
}

If you remove those lines, it speeds the mouseovers up dramatically. It's the opacity change on :hover that's doing it.
Summary: Slow jquery mouseovers → Slow css :hover opacity change
Also, turning hardware acceleration off does indeed fix the slowness for me.
Same here, and 3.6 doesn't have a problem with it.  Blocking regression, I think!  I have an NVIDIA 260 GTX, driver 8.17.12.6635 (dec 21, 2010).
blocking2.0: --- → ?
Keywords: regression
An xperf profile shows that we spend all the time repainting on Windows too.

We're not retaining layers for the transparent stuff. It's all being drawn into the main page layer via D2D. So it looks like D2D performance issues doing all that drawing.

We're spending a lot of time in gfxContext::PushGroupAndCopyBackground (called by PushGroupForLayer) creating and clearing temporary surfaces. (We can certainly get rid of the cost of clearing surfaces we know we're going to overwrite.) And we spend some more time copying from the main page surface up to the background of the temporary surface; most of that time seems to be cairo_d2d_flush flushing the main page surface. So most of that is probably a regression from bug 363861.

I notice also that we're spending quite a lot of time in cairo_gstate_restore, destroying the source pattern, which destroys a surface.

There's an awful lot of flushing going on; every time we start using a surface as a source, we have to flush it. And each of the transparent objects on this page has its own temporary surface.
Bas, would using D2D's PushLayer/PopLayer directly avoid flushing?
(In reply to comment #11)
> Bas, would using D2D's PushLayer/PopLayer directly avoid flushing?

That depends, the flush itself doesn't take any time, what's in the pipeline does, depending on what's in there it could help or it could not, I'll look into this.
So, inside the flushes we see a lot of time being spent inside PushLayer and PopLayer, presumably this is related to complex clipping going on. I'm not sure there's much we can do about that.

I should note the page is fast in IE9.
There's border radius in play, would that cause complex clipping?
Should we just not create individual surfaces like this where there's complex clipping, and instead just accelerate the compositing?
An additional cause of the slowdown appears to be that BasicThebesLayer::Paint uses a PopGroupToSource which defaults to using EXTEND_NONE! If I replace this with EXTEND_PAD this improves. We probably want to change the PopGroupToSource implementation to use EXTEND_PAD by default.
(In reply to comment #15)
> Should we just not create individual surfaces like this where there's complex
> clipping, and instead just accelerate the compositing?

If you mean accelerating through layers, we can't do complex clips in layers. If you mean through D2D, the overhead wouldn't be much less than our current approach.

As a matter of fact this is pretty much what we do, for a complex clip D2D creates a 'layer' which is a temporary surface, when you 'pop' that clip it will composite the layer back to the background using the complex clipping region as a mask.

Where the approach you mentioned could help, is if we kept a separate surface around retaining its content, this would essentially be what layers tries to do, but it lacks the ability to do complex clipping.
There also appears to be some odd invalidation behavior here. First I disabled clips to see how things get redrawgn, then when I mouse from one 'power' over to another. The window seems to redraw completely (with the correct content once), and then it seems to redraw the area of the transparent 'tooltip box' again (with clipping disabled this can be seen because the rest of the page now becomes black due to the paint).
_That_ could be due to jquery making several style changes off timeouts or some such.  Someone would have to sort out the details of the jquery calls this page makes and the details of what those calls do to figure that out.  The full-window redraw is a bit odd, though.
I think we need to at least use EXTEND_PAD in PopGroupToSource, but we need to look into this more generally too.
Assignee: nobody → bas.schouten
blocking2.0: ? → betaN+
Whiteboard: [softblocker]
Is there a good reason that this blocks betaN?  If not, it should be moved over to final+.
Whiteboard: [softblocker] → [softblocker][final?]
Is this any better now?
It is not any better in beta 11, in fact!
it is still INCREDIBLY slow on latest nightly (Win 7, HD3850):
Adapter Description ATI Radeon HD 3800 Series
Vendor ID 1002
Device ID 9505
Adapter RAM 512
Adapter Drivers aticfx32 aticfx32 atiumdag atidxx32 atiumdva
Driver Version 8.812.0.0
Driver Date 1-4-2011
Direct2D Enabled true
DirectWrite Enabled true (6.1.7600.16699, font cache 27,31 MB)
WebGL Renderer Google Inc. -- ANGLE -- OpenGL ES 2.0 (ANGLE 0.0.0.541)
GPU Accelerated Windows 1/1 Direct3D 10
On mac we are spending large amounts of time within PushGroupAndCopyBackground, mostly during the CopySurface call.

Forcing nsDisplayOpacity to always create active layers results in very visible performance improvements in this testcase.

Is there any real disadvantage to having active layers (with an accelerated backend) other than the increased vram usage?
There is the increased vram usage :-). There's also extra overhead especially if it means we end up doing component alpha more.

I think we should try to micro-optimize here before we fiddle with the activity heuristics; the latter is a bit of a zero-sum game, we could fix this testcase but probably hurt others.
** PRODUCT DRIVERS PLEASE NOTE **

This bug is one of 7 automatically changed from blocking2.0:betaN+ to blocking2.0:.x during the endgame of Firefox 4 for the following reasons:

 - it was marked as a soft blocking issue for a beta
 - the whiteboard indicated that it might be appropriate for a .x release
blocking2.0: betaN+ → .x+
Searched for opacity-related slowness and found this bug. The slowdown is much worse for me on ptable.com. Click the Isotopes tab, then click an element so that others fan out of it. Hovering between the spawned isotopes only switches their z-index, but the switch is taking greater than a second for me. If the opacity of all the surrounding elements is turned off, switching is immediate.
Michael, that sounds like a separate issue.  This bug is cross-platform (in that it appears at least on Mac and Windows).  The issue you're reporting doesn't seem to be a problem on Mac; I assume you're on Windows.  Can you please file a separate bug?
Just narrowed it down further and simplified testing. No need to go to the Isotopes tab. Just click in the search box to activate it (it'll turn yellow). Then hover around elements. All this function does is apply a CSS outline and it updates just as slowly. This only occurs with hardware acceleration turned on. Laptop with a Quadro FX 1600M and updated NVIDIA drivers. It appears to be the same bug as this as they both update instantly on Windows as soon as hardware acceleration is disabled. Let me know if you still recommend filing separately.
Yes, please file separately.  Again, this bug is a problem on all platforms but yours is Windows-specific; that means they almost certainly need different fixes.
(In reply to comment #25)
> On mac we are spending large amounts of time within
> PushGroupAndCopyBackground, mostly during the CopySurface call.

I've attached a patch to bug 665293 which fixes the Mac part. Hovering the diamonds is fast for me with that patch.
blocking-basecamp: --- → ?
blocking-kilimanjaro: --- → ?
blocking-basecamp: ? → ---
blocking-kilimanjaro: ? → ---
The original testcase is gone. Is there another URL that reproduces the problem on recent versions?
Flags: needinfo?(sancus)
the bug 710186 is about css opacity and hover performance. That bug has a testcase.
i can confirm, that the bug 710186 is still an issue on Macbook pro retina mid 2015, dual gfx, OSX 10.10.5, Nightly 44.0a1 (2015-10-22)
comparing to safari 8.0.8 (10600.8.9), Firefox has a noticable lag between the mousepointer and the hover effect.
Indeed, the testcase in bug 710186 shows pretty clear differences on Windows as well between Firefox/Chrome/Edge. That said, we don't need two bugs open to track the same issue :)

Duping this over to bug 710186 where there's a nice testcase attached.
Status: NEW → RESOLVED
Closed: 9 years ago
Flags: needinfo?(sancus)
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.