This commit modifies AsyncPanZoomController to scroll immediately for any keyboard
scrolls when the pref, "general.smoothScroll" is disabled.
MozReview-Commit-ID: 3lfRMOCC7er
--HG--
extra : source : 9e9480d318f92811828756267c4b4fb7ea2fcf1b
When a compositor is recreated, either from a driver reset or a GPU process crash, the
focus sequence number in content persists, and when APZ is recreated, content will have
a higher sequence number.
There are two ways of handling this: either resetting all of content's focus sequence
numbers to zero to match the new focus state, or updating the new focus state to the
latest sequence number in content.
This commit does the latter by detecting when the focus state was newly created and
syncing it's sequence number to content if content is ahead.
MozReview-Commit-ID: GkIp7AWyaFw
--HG--
extra : source : b6339570bbd8576447f128359278868fb6d1d8e7
This is an imperfect workaround. Ideally we'd want layout to determine the
correct color here: If the pushed layer will end up on something mostly opaque
in the outer layer, the font smoothing background color should be transparent
(or even a color that approximates that opaque content), and if the pushed
layer will end up on transparency in the outer layer, the appropriate font
smoothing background color for the outer layer should be used when drawing text
in the pushed layer.
This workaround causes us to lose subpixel AA in background tabs that have the
overflow mask applied to them. For those, using the font smoothing background
color in the pushed layer was the right choice.
MozReview-Commit-ID: FPufh04EVp3
--HG--
extra : rebase_source : 7a6cb73255bdb7f1b8aba7df60ebe61171275da4
This patch ensures that we push clips in WR for each display item,
reflecting the display item's clip chain as computed in Gecko. A display
item will often share part or most of its clip chain with other display
items, so we try to reuse the corresponding WR clip ids as much as we
can instead of defining new duplicated clips.
MozReview-Commit-ID: LkBh8LIpQ4J
--HG--
extra : rebase_source : 5af1de0931f1d059e98b5c66b15988961503e114
This regenerates the cargo lockfiles and FFI bindings header. It also revendors
the third_party/rust libraries.
MozReview-Commit-ID: ID0YhoIH6cz
--HG--
extra : rebase_source : 7c22828a831eafcf527f2c3baf8d4d012db8f9a4
Previously, the WebRenderBridgeParent for each content layer tree would use the
same WebRenderAPI instance as the top-level WebRenderBridgeParent for that window.
However, in order to make the namespacing changes work we now need to use a
separate WebRenderAPI instance for each WebRenderBridgeParent. The content
WebRenderAPIs are cloned from the parent one, so that they all share the same
backend, but can allocate resource IDs in distinct namespaces.
MozReview-Commit-ID: 7VTFL8F09n7
--HG--
extra : rebase_source : 2da1d03abc23bd7852e4b12fe133889bd80cad53
In theory the upstream API change should allow us to share the same WR renderer
instance across multiple WebRenderAPI instances. For now however I retain the
existing behaviour of one WR instance for each WebRenderAPI instance, but keep
track of the document id in a new DocumentHandle struct. The C++ side keeps
a pointer to this DocumentHandle struct instead of the raw RenderApi.
MozReview-Commit-ID: I9pCKOY1OYx
--HG--
extra : rebase_source : 7b0ae2ccb2692a76045371ac165468c7f7539b40
