Platform/GFX/layers heuristics

From MozillaWiki
< Platform‎ | GFX
Jump to: navigation, search

Performance considerations:

Having too many layers causes performance and memory overhead, because we are likely to retain more hidden pixels and because it means more IPC synchronization and more quads to composite.

What we would like to be layerized

  • Content that need their own surface to render to, like canvases and video elements.
  • Content that is animated, so that it does not invalidate the rest.
  • Content that scrolls independently of other content for the same reasons as animations.

What we would like to *not* be layerized

  • Content that don't change "often" with respect to one another.

How do we decide layerization?

Display lists

A nsDisplayList is a list of drawing commands that are called nsDisplayItems. These drawing commands are rather high level, see different implementations of nsDisplayItem in nsDisplayList.h

The code that creates layers lives mostly in FrameLayerBuilder.cpp and nsDisplayList.cpp

There are two classes of layerization decisions:

  • there are display items that can force themselves to be layers (see GetLayerState implementations, most are in nsDisplayList.cpp)
  • and there is FrameLayerBuilder deciding what layers to build for a group of display items that didn't ask for their own layer (FrameLayerBuilder.cpp)

The methods to look for are:

  • nsFrameLayerBuilder::BuildContainerLayerFor
  • nsDisplayItem::BuildLayer
  • nsDisplayItem::GetLayerState which is the nsDisplayItem expressing whether or not it needs to have its own layer for its content (LAYER_ACTIVE).
  • nsDisplayItem::TryMerge which tries to merge two items into one so as to reduce the amount of layers

The order of display items

Sometimes display items that are scrolled together are interleaved with items that require an active layer. In these cases the tiems above and below the active layer cannot be merged into one layer even if the active item does not overlap with the one above, because asynchonous scrolling could potentially get the items to overlap.

Open question: can we do something about this? Maybe somehow detect when overlap is not possible?

Display items are generated from the frame tree.

How merging thebes layers work

The code that does that seems to be in the class ContainerState in FrameLayerBuilder.cpp. TODO: explain it!

Our current layerization strategies

TODO!

Display list based invalidation

See https://wiki.mozilla.org/Gecko:DisplayListBasedInvalidation