зеркало из https://github.com/mozilla/gecko-dev.git
e2f27ec58a
We introduce a new type of display port, a minimal display port. It is controlled via a property on the content element. When the property is present any other display port specified on the element is ignored and instead the display port rect is computed by assuming 0 display port margins and no alignment (this reuses the existing code for display port suppression). We then add code to set a minimal display port on every scroll frame that is painted that has WantAsyncScroll() when certain prefs are set (the prefs are disabled as of this patch though). We then need to manage removing the minimal display port property when, before this patch, we would have created a regular display port. As well we need to add the minimal display port property when, before this patch, we would have removed a regular display port. In order to do this I audited all sites where we set the display port rect and display port margins property. The changes to the code for handling the removal display ports happens in a later patch. My audit found that all of the places we set a display port want to clear the minimal display port property except: -UpdateSub/RootFrame in APZCCallbackHelper -UpdateDisplayPortMarginsForPendingMetrics in DisplayPortUtils UpdateDisplayPortMarginsForPendingMetrics is basically a fast path of the UpdateSub/RootFrame code. These are the places where we handle calls to RequestContentRepaint from apz. By adding an assert and running it through try server I found that UpdateSub/RootFrame can create a display port in the following cases: -a scroll info layer -a scroll frame with !WantAsyncScroll() (the main thread never creates a display port for a scroll frame with !WantAsyncScroll()) (for example if the main thread creates a scroll id and sends over metadata via nsLayoutUtils::GetRootMetaData, and then the scroll rect changes, that will cause a RequestContentRepaint call) -a few instances that don't fall into the above that happened on try server but didn't reproduce for me locally, so I don't know more about them. It's not very important whether we clear the minimal display port property for these cases or not (the first two cases we don't async scroll the scroll frame at all, the last case seems quite rare). Note that we intentionally do not change the existing behaviour of zero margin display ports set via SetZeroMarginDisplayPortOnAsyncScrollableAncestors as we are aiming for no behaviour changes with this patch (until we flip the pref). A later patch in a different bug handles changing these display ports over to minimal display ports. Differential Revision: https://phabricator.services.mozilla.com/D103855 |
||
|---|---|---|
| .. | ||
| base | ||
| build | ||
| components | ||
| doc | ||
| ds | ||
| glue | ||
| idl-parser | ||
| io | ||
| libxpt/xptcall | ||
| reflect | ||
| rust | ||
| string | ||
| system | ||
| tests | ||
| threads | ||
| windbgdlg | ||
| xpidl | ||
| moz.build | ||
| xpcom-config.h.in | ||