Confirmed users
699
edits
Gecko:CrossProcessLayers: Difference between revisions
→Important cases on fennec
| Line 66: | Line 66: | ||
** Single screen layer: decoding needs to be done in content process (?). Possibly better parallelism for SW-only decoding. Content process controls frame rate allocation for multiple videos. Harder to adjust frame rates across browser/content because relies on OS for CPU scheduling. | ** Single screen layer: decoding needs to be done in content process (?). Possibly better parallelism for SW-only decoding. Content process controls frame rate allocation for multiple videos. Harder to adjust frame rates across browser/content because relies on OS for CPU scheduling. | ||
** Container layer: can extract video layers from content container and schedule centrally. Browser (decoding thread) decodes all videos. Possibly more efficient with HW accelerated decoding b/c can batch commands for several videos. Easier to allocate frame rates across all visible videos. | ** Container layer: can extract video layers from content container and schedule centrally. Browser (decoding thread) decodes all videos. Possibly more efficient with HW accelerated decoding b/c can batch commands for several videos. Easier to allocate frame rates across all visible videos. | ||
* '''canvas''': For write-only canvases, it seems best to keep backing memory in VRAM. But this makes synchronous reads expensive and it's not clear how updates would be published from content process w/o access to GPU. For read/write canvases, probably better to store in shared system memory. Could potentially switch backing store at runtime, but shmem-only seems a simpler first approach. | |||
* '''CSS transforms and SVG filters''': scheduling work browser/content probably needs to be viewed as distributed optimization problem. For SW-only transforms/filters, probably want to do as much work as possible in content process. Unclear for HW acceleration, but that's future work. | * '''CSS transforms and SVG filters''': scheduling work browser/content probably needs to be viewed as distributed optimization problem. For SW-only transforms/filters, probably want to do as much work as possible in content process. Unclear for HW acceleration, but that's future work. | ||
* '''Animations''': cjones doesn't know enough to comment on this. | * '''Animations''': cjones doesn't know enough to comment on this. | ||