1,295
edits
Gecko:Layers: Difference between revisions
Jump to navigation
Jump to search
→Open questions
| Line 25: | Line 25: | ||
** Roc: assuming that "container" layers are always formed by compositing together their children, what is the point of having backing store for them? For leaf layers, I assume we would keep them in backing store (as long as clients hold references to them, which may only be as long as one paint cycle). My proposal makes no provision for "faulting in" the contents of discarded layers. | ** Roc: assuming that "container" layers are always formed by compositing together their children, what is the point of having backing store for them? For leaf layers, I assume we would keep them in backing store (as long as clients hold references to them, which may only be as long as one paint cycle). My proposal makes no provision for "faulting in" the contents of discarded layers. | ||
** Jeff: My response to that is: what's the point creating layers for things that we don't want a backing store for? | ** Jeff: My response to that is: what's the point creating layers for things that we don't want a backing store for? | ||
** Roc: so we can do hardware accelerated operations on them | |||
** It seems that after IRC conversation, we currently don't have any argument for having the API support drawing directly into container layers. Whether the rendering of a container layer is cached in a surface is an implementation detail, which may vary based on speed-vs-VRAM tradeoffs. | |||
* How is layer z-order maintained? | * How is layer z-order maintained? | ||