When we need to create a separate, temporary DrawTarget to draw into and then combine with the current DrawTarget in some way, it can be perf critical to minimize the size of the temporary DrawTarget to the clip extents of the current DrawTarget. For example, when creating a gfxPattern for SVG masks (nsSVGMaskFrame::ComputeMaskAlpha) we use GetClipExtents() to minimize the size of the gfxImageSurface that we draw into. To convert this code to Moz2D without a perf hit we're going to want some way to get the device space clip extents. Right now we have no Moz2D equivalent to gfxContext::GetClipExtents. Is it going to be problematic to implement an equivalent for any of our backends? If so, is there another way that we can figure out how to minimize the size of the temporary DrawTarget?

Right now most of our backends don't have a way to get the ClipExtents easily. So we'd need to add tracking code to each backend that doesn't have this. It would be a big pain to do this since we'd need to paintain our clip stack and things like that. I'm wondering whether we should rather implement a PushLayer function on Moz2D. This shouldn't be too hard and I think we're going to need it anyway.

(In reply to Bas Schouten (:bas.schouten) from comment #1) > Right now most of our backends don't have a way to get the ClipExtents > easily. So we'd need to add tracking code to each backend that doesn't have > this. It would be a big pain to do this since we'd need to paintain our clip > stack and things like that. I'm wondering whether we should rather implement > a PushLayer function on Moz2D. This shouldn't be too hard and I think we're > going to need it anyway. Yes, this would be better.

(In reply to Bas Schouten (:bas.schouten) from comment #1) > Right now most of our backends don't have a way to get the ClipExtents > easily. So we'd need to add tracking code to each backend that doesn't have > this. I see. > I'm wondering whether we should rather implement > a PushLayer function on Moz2D. This shouldn't be too hard and I think we're > going to need it anyway. If such a PushLayer function can't minimize the resulting surface based on the clip extents, how will that help the masking case described in comment 0? Also is this something that could be implemented soon?

I think Bas means that some of the native API's provide a way to do PushLayer without needing to know the size. We should definitely do PushLayer, we need it for converting BasicLayerManager among many others. Unfortunately BasicLayerManager also requires GetClipExtents for the times we try do a PushLayer manually (3d transform, caching the surface). I think we need both to match the current trunk in terms of performance.