Gecko:Layers: Difference between revisions

Layer API Proposals

* Accelerated compositing and scaling

* Accelerated composition of content from multiple processes, including untrusted processes that may lack access to native accelerated graphics APIs

* Should have an efficient software fallback

* Support VRAM management; we'd like to be able to discard buffers and re-render them when VRAM is full, including with fine granularity via a tile cache

* Should we build the layer tree if we are not hardware accelerated?

** Roc: child order. i.e. the nth child is beneath n+1th child

Assume we have a webpage with a container containing some web content and a video. This container has a 3d-transform applied to it. What should the layer hierarchy look like?

*** Retained content that's in front of the transformed container (not needed if there is no such content)

Taking a step back, let me write down how I think layout and display lists could/should build and maintain a layer tree.

Implicit layers can also change size, need to be scrolled, etc.

Every layer belongs to a LayerManager. The idea is that a window will provide an associated LayerManager. (Documents being rendered by their own process will probably have their own LayerManagers.) Every layer in a layer tree must have the same LayerManager.

LayerManager::SetRoot sets a layer to be the root layer. This is how you get a layer to be displayed.

Layer is the superclass of all layers. A Layer could be anything that can be rendered into a destination surface. It has methods to set various properties that affect the rendering of a layer into its parent: opacity, transform, filter, etc... (For simplicity I'm only showing 'opacity' here.)

Layers should be referenced counted. The LayerManager holds a reference to its root layer and parent layers hold references to their children.

A RenderedLayer is the basic leaf layer that you can render into using cairo/Thebes.

For scrolling and to enable intelligent reuse of parts of RenderedLayers by other layers...

  class ContainerLayer {

When we go to off-main-thread compositing we'll want to add support for animation and other stuff. For example we might want a YUVSeriesLayerBuilder that can select from a queue of timestamped frames based on the current time. The rendering property setters on LayerBuilder would be extended with animating setters that take a list of timestamped values, or perhaps the parameters of actual transition functions.

Layers have two basic operations:  

CoreAnimation will ask a layer to redraw it's contents at particular timestamp. The layer can choose to do so, or ignore the request.

Here are some observations on WebKit's implementation:

# One for the div - 100x100

  // Interface implemented by 'renderers'. This interface can for example

  // be implemented by Cairo(possibly with cairo-gl), OpenGL, Direct3D or

  }

AppKit supports hosting a layer tree in a NSView using the following technique:

If we set an animating div to have a z-index of -1, we seem to get a large texture and a bunch of tiles?

What should we do to scroll?

Anholt: destination tile cache sounds pretty nice to me, and with APPLE_object_purgeable use the GPU could throw things out of the cache when appropriate (rather than you having to guess).

http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CoreAnimation_guide/Articles/CoreAnimationArchitecture.html#//apple_ref/doc/uid/TP40006655

Having separate trees sort of corresponds to Roc's LayerBuilder infrastructure described above.

CALayer - CALayer is the model class for layer-tree objects. It encapsulates the position, size, and transform of a layer, which defines its coordinate system. It also encapsulates the duration and pacing of a layer and its animations by adopting the CAMediaTiming protocol, which defines a layer’s time space.

[http://developer.apple.com/mac/library/documentation/GraphicsImaging/Reference/CAShapeLayer_class/Reference/Reference.html#//apple_ref/occ/cl/CAShapeLayer CAShapeLayer] - Added in 10.6 presumably provides hardware accelerated rendering of paths

ClutterActor - Every actor is a 2D surface positioned and optionally