We seem to be getting some very, very large layers when using D3D9 or D3D11 layers and OMTC. (8192x8192) These take a long time to draw in software and when zooming we draw them continuously. This is very expensive and makes it very slow. We'll need to investigate further to see what we can do here.

This would be an interesting case for anyone interested in learning about our invalidation code :) When we have animated transforms we attempt to pre-render them (render areas outside of the visible region) under the assumption that the transform will make the remainder visible before it's invalidated. We also attempt to draw transformed content at device resolution to avoid quality loss when scaling. The combination of these two factors can result in really large layers, and if we invalidate too often then we haven't gained anything from doing all this extra rendering. It looks like some of the time we manage to zoom without invalidations, but other times it flickers horribly. There's probably quite a few small bugs/inefficiencies there. In this particular case the transformed content consists entirely of <img>'s, so we could probably optimize these to ImageLayers and avoid this entirely. That won't fix similar pages that include content other than images within the transform though.

(In reply to Matt Woodrow (:mattwoodrow) from comment #1) > This would be an interesting case for anyone interested in learning about > our invalidation code :) > > When we have animated transforms we attempt to pre-render them (render areas > outside of the visible region) under the assumption that the transform will > make the remainder visible before it's invalidated. > > We also attempt to draw transformed content at device resolution to avoid > quality loss when scaling. > > The combination of these two factors can result in really large layers, and > if we invalidate too often then we haven't gained anything from doing all > this extra rendering. > > It looks like some of the time we manage to zoom without invalidations, but > other times it flickers horribly. There's probably quite a few small > bugs/inefficiencies there. > > In this particular case the transformed content consists entirely of > <img>'s, so we could probably optimize these to ImageLayers and avoid this > entirely. That won't fix similar pages that include content other than > images within the transform though. How hard will it be to optimize these to ImageLayers? Is it feasible to do this in a way we can uplift this to Aurora?

(In reply to Matt Woodrow (:mattwoodrow) from comment #1) > This would be an interesting case for anyone interested in learning about > our invalidation code :) > > When we have animated transforms we attempt to pre-render them (render areas > outside of the visible region) under the assumption that the transform will > make the remainder visible before it's invalidated. Is this Windows specific? Or could it be what we're also seeing in bug 1043700 (there is animation, the horrible flashing, and invalidation)?

It's not windows specific, I was testing it on OSX. Unsure if it's related, we'll see what Markus finds out.

I tested out converting all images into ImageLayers and we perform really well. Doing it properly is a bit tough, need to think about how it will work.

Is this intended to cover bug 1037230 as well (OOM crashes, presumably from the large layers), or is this just about the speed of software rendering?

(In reply to David Major [:dmajor] from comment #6) > Is this intended to cover bug 1037230 as well (OOM crashes, presumably from > the large layers), or is this just about the speed of software rendering? I strongly suspect this will resolve this issue.

Hmm, large surfaces/masks/layers in GFX seem to be an issue that is cropping up in different places (bug 1034593 had a huge mask in cairo, for example) - is there some more general system of either mitigations or warnings that can help us deal with those?

[Tracking Requested - why for this release]: This makes Bing maps completely unusable for me (with or without hardware acceleration)

Bing maps is an important website, tracking.

Matt, Bas, is this right for one of you, or should I see if Markus can take care of it?

This should already be fixed, by bug 1049450.

Confirmed with nightly 0818. Hooray!

This bug is a duplicate, right? Anyway, untracking it since we tracked bug 1049450.

(In reply to Milan Sreckovic [:milan] from comment #11) > Matt, Bas, is this right for one of you, or should I see if Markus can take > care of it? As Matt said, this was duped by bug 1049450 and fixed there :-).