Confirm
586
edits
Changes
→FAQ: add some q's and a's
; What platforms is APZ currently enabled on? [2014-01-14] : As of January 8, 2014, APZ is currently enabled in all B2G processes that are not the root process (i.e. this includes all browser content and Gaia apps). It is also enabled on Firefox Metro (when running in metro mode).
; How does APZ impact the onload event? Will this impact user perceived performance? [2014-01-28] : In general APZ shouldn't really impact the onload event. We might be painting a larger area now but if the app is well-behaved and doesn't trigger a lot of paints the impact from this should not be very large. If there are reports of delayed onload because of APZ, it would be useful to get profiles with and without APZ enabled to compare.
; If the onload event is delayed due to a long page, should we expect regressions in constructing long pages/elements after load? [2014-01-28] : By this I assume you mean dynamically generating DOM nodes and inserting them after the load event has fired. As this would also trigger repaints, and again since we are painting a larger area it will be slower. The more repaints that are triggered, the slower it will be. I don't think it matters much whether the nodes are inserted before or after the load event, except that if you're doing it via script rather than in the HTML itself it's more likely to accidentally trigger reflow by querying some layout property.
; I've heard we're expecting scroll performance to generally be better everywhere. Granted there are some exceptions with things like sticky headers which we will be resolving soon. Are there any other times we would see a performance regression when it comes to scrolling and FPS? [2014-01-28] : Average FPS should be better with APZ, but because we don't have tiling yet we might see some jank when the painted content is uploaded to the compositor, because it is a large buffer that needs to be copied over. This may show up as a regression depending on how you measure it. Note that currently input events still need to be processed on the Gecko thread in the root process before they are used by APZ, so scrolling isn't 100% asynchronous. This might be a source of poor scrolling performance, if the root process' Gecko thread is busy - however this should be no worse than without APZ so I wouldn't call it a regression.
; Do you have any suggestions on ways to architect our apps/tests to take advantage of APZ? [2014-01-28] : I think I've run into a few apps on B2G where the body element is not scrollable but all the scrollable content lives inside another overflow:scroll div. (I think this might be the case in the settings app, actually). This is undesirable because while we ensure the body's content is always layerized and ready to scroll right away, other scrolling subdocuments may not be. This is required to prevent allocating massive amounts of memory. What happens is that as soon as you start scrolling the subdocument it will be layerized and you can scroll it async, but there is still a small latency involved. I think Chris Lord filed a bug about this for the settings app. Other than that, just minimizing the number of paints would help - try to use animations and such that can be done in the compositor as much as possible (BenWa can provide more info on this if you need it).
