Special-case resolution-scaled ThebesLayers and translation-only transforms in ContainerLayerOGL

RESOLVED DUPLICATE of bug 607653

Status

()

defect
RESOLVED DUPLICATE of bug 607653
9 years ago
9 years ago

People

(Reporter: cjones, Assigned: cjones)

Tracking

unspecified
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(fennec2.0b3+)

Details

For containers that are scaled by a factor of C that have ThebesLayers drawn with resolution (C, C), we absolutely must remove the intermediate fbo or we're going to get fuzzy text caused by resampling the thebes layer's texture.  (This works in basic layers because the gfxContext ends up annihilating the two scales.)  Almost every paint on mobile will hit this case.  This might also help with bug 586683, not sure.

In http://hg.mozilla.org/mozilla-central/file/41aded65fb6c/gfx/layers/opengl/ContainerLayerOGL.cpp#l163, we create a temporary fbo whenever a child layer is transformed.  For layers that are only translated, we can skip this and just adjust childOffset by the container's translation.  This is going to hurt on mobile where basically every paint will have at least one container with a translation.

It also might be possible to eliminate the temporary fbo for scale-and-translate-only transforms by playing games with the child's offset and quad, but I haven't thought this through.  We'll probably want that optimization for mobile too.
tracking-fennec: --- → ?
This is more or less fixed by bug 599507, but we could probably improve it to pass the transform down when there are multiple children (and no opacity) and possibly handle transformed clipped layers too.
Depends on: 599507
Nice!  That helps a lot.

Is there a fundamental reason why we can't get the GL backend to only create a temporary fbo for the same cases the basic backend will --- http://mxr.mozilla.org/mozilla-central/source/gfx/layers/basic/BasicLayers.cpp#1121 --- ?
The main difference is that cairo uses a matrix stack, and clipping is relative to the current transform matrix. For us to get the equivalent in GL, we'd need to implement something similar or modify child layers' clip rects to be transformed correctly.

The latter wouldn't be too hard, I believe ContainerLayers are the only ones that obey clipping, so we'd just need logic to transform the current clip rect by aTransform in ContainerLayerOGL::Render.
(In reply to comment #3)
> The latter wouldn't be too hard, I believe ContainerLayers are the only ones
> that obey clipping, so we'd just need logic to transform the current clip rect
> by aTransform in ContainerLayerOGL::Render.

This is pretty hard though, we could no longer use scissor rects to do this. We'd have to intersect the geometries and then draw a more complex shape while recalculating the texture coordinates. Pretty tricky, although not impossible.

We're always going to be stuck with this situation for group opacity though.
(In reply to comment #0)
> For containers that are scaled by a factor of C that have ThebesLayers drawn
> with resolution (C, C), we absolutely must remove the intermediate fbo or we're
> going to get fuzzy text caused by resampling the thebes layer's texture.  (This
> works in basic layers because the gfxContext ends up annihilating the two
> scales.)  Almost every paint on mobile will hit this case.  This might also
> help with bug 586683, not sure.

Hm, can you explain why this doesn't/you think it won't happen with GL as well?  If you have a texture of the right resolution, and it's drawn to a screen-size rect of the right size, you'll end up with 1:1 pixels and will get no resampling.  In any other case, we'd have to resample, and the same would be true whether we use a FBO or not (or with basic layers even).

Orr... now that I read this again, the problem is:

ContainerLayer - scaled by C, resolution 1.0
  ThebesLayer - scaled 1.0, resolution C

?  That seems like a somewhat broken state, why don't we have:

ContainerLayer - scaled by 1.0, resolution 1.0
  ThebesLayer - scaled by C, resolution C

regardless of bug 599507?
(In reply to comment #5)
> ContainerLayer - scaled by C, resolution 1.0
>   ThebesLayer - scaled 1.0, resolution C
> 
> ?  That seems like a somewhat broken state, why don't we have:
> 
> ContainerLayer - scaled by 1.0, resolution 1.0
>   ThebesLayer - scaled by C, resolution C
> 
> regardless of bug 599507?

I don't understand what you think is broken; your first example is exactly what resolution-scaling was designed for.  The use case for resolution is, draw thebeslayers with resolution C in the content process, then in the chrome process, scale the container of the shadow layers by C.  Setting a scale on the thebeslayers themselves in the content process is ickier because that requires cooperation from layout, requires recomputing the visible region, clips, etc.  The current design is nice and simple.

Yes, the resolution API designed with cairo in mind.  GL layers behave differently in ways that are going to be expensive on mobile, and for bug 599507 and other things we want it to act more like cairo.  This is one of those things.
Assignee: nobody → jones.chris.g
tracking-fennec: ? → 2.0b3+
Removing the intermediate fbo for simple transforms should also fix this bug, which bug 607653 is doing.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 607653
You need to log in before you can comment on or make changes to this bug.