TileCoord is a (very slightly) better name for this unit in my opinion, and I'd
like to add a TileBuffer unit in the future which might get confused if there
is an unprefixed Tile unit.
--HG--
extra : rebase_source : 968f508f2195c12fd4840e2415130b1b36fd3e29
Patch author is Takuro Ashie <ashie@clear-code.com>
Use wl_display to get EGLDisplay on Wayland because some drivers doesn't support EGL_DEFAULT_DISPLAY.
For example Intel's driver causes crash without this patch.
MozReview-Commit-ID: ILtRJrW6MDs
--HG--
extra : rebase_source : a513bfa3c1fc408743bd5b4aed6e416f4d8cc0d7
Original patch author is Takuro Ashie <ashie@clear-code.com>
NS_NATIVE_EGL_WINDOW is exported by Gtk toolkit code and provides both X11 window
handle for X11 Gtk backend and EGL window handle for Wayland backend.
MozReview-Commit-ID: DEmlaLL7zGY
--HG--
extra : rebase_source : 4e3fb33e68472d61cbc8c555347d4b10343e2628
This function is no longer used since we introduced TransactionWrapper class in
bug 1451469.
MozReview-Commit-ID: FGxi6thbxcP
--HG--
extra : rebase_source : ef5628f8bffb5c1fedf6de80056d4ebba41a9edf
With non-WebRender, the composite is triggered unconditionally when we receive
the transaction from the content side, so we never needed this. The previous
patch adds the composite for the equivalent WebRender codepath, but it's better
to do it explicitly in NotifyLayersUpdated as well. The reason for this is that
with WebRender, this code runs on the updater thread which is not the same as
the compositor thread - so the composition that is scheduled from
WebRenderBridgeParent upon receiving the transaction might happen before the
scroll offset update is actually applied. Triggering a composition from
NotifyLayersUpdated should be a no-op in the cases where a composition is already
scheduled, but in cases where it has not been scheduled, it will schedule one
to ensure the scroll offset update gets composited properly.
MozReview-Commit-ID: Luf76J6QDkr
--HG--
extra : rebase_source : a130f1cf22973910767e96c69962d8b621c0d368
This is mostly just refactoring to make the code more understandable. However,
there are a couple of functional changes:
- If we have scroll offset updates we now schedule a composite instead of
sending the DidComposite right away. This is needed because we want to
actually composite the scroll offset change.
- If there are WebRenderParentCommands provided, we process them and update the
epoch in a single transaction, instead of splitting it across two transactions
for no good reason.
MozReview-Commit-ID: 2HCa19EGxUD
--HG--
extra : rebase_source : f7cdc1b46fbca96b2124582f29c791f8944c1fc9
With non-WebRender, the composite is triggered unconditionally when we receive
the transaction from the content side, so we never needed this. The previous
patch adds the composite for the equivalent WebRender codepath, but it's better
to do it explicitly in NotifyLayersUpdated as well. The reason for this is that
with WebRender, this code runs on the updater thread which is not the same as
the compositor thread - so the composition that is scheduled from
WebRenderBridgeParent upon receiving the transaction might happen before the
scroll offset update is actually applied. Triggering a composition from
NotifyLayersUpdated should be a no-op in the cases where a composition is already
scheduled, but in cases where it has not been scheduled, it will schedule one
to ensure the scroll offset update gets composited properly.
MozReview-Commit-ID: Luf76J6QDkr
--HG--
extra : rebase_source : 3e8cc6c9cd6fb79ab1f7ec3d1e38a34a2c7f6011
This is mostly just refactoring to make the code more understandable. However,
there are a couple of functional changes:
- If we have scroll offset updates we now schedule a composite instead of
sending the DidComposite right away. This is needed because we want to
actually composite the scroll offset change.
- If there are WebRenderParentCommands provided, we process them and update the
epoch in a single transaction, instead of splitting it across two transactions
for no good reason.
MozReview-Commit-ID: 2HCa19EGxUD
--HG--
extra : rebase_source : e5643b83914b47889e4bde6c0f8658fedb3d54fc
This is to accommodate non-networking fd usage (IPC transports, various
databases, .xpi files, etc.), so it's separate from Necko's existing
manipulation of the fd limit, which is tied into Necko's internal limits
on how many sockets it will try to poll at once.
Note that resource limits are inherited by child processes, so this needs
to be done only in the parent.
This patch also removes similar code used on Solaris and Mac OS X. The
Mac case (bug 1036682) refers to fd use by graphics textures, which
shouldn't be consuming fds anymore (even transiently) as of bug 1161166.
MozReview-Commit-ID: 2uodrkW5sUn
--HG--
extra : rebase_source : 5306f4995000459b89bed048ecafba3c262bbbdf
Right now GLContextProviderEGL requires the widget to have a valid
EGLSurface when creating a non-offscreen GLContext. This patch falls
back to a dummy pbuffer surface or EGL_NO_SURFACE if supported, allowing
the GLContext creation to succeed. This will give us some more flexibility
on Android where the widget surface is not always readily available.
Additinally, we use the fallback surface any time MakeCurrent() is
called without a valid surface. This is needed to allow things like
Compositor shutdown when there is no widget surface available.
MozReview-Commit-ID: 1kbLIGNiOkV
Right now GLContextProviderEGL requires the widget to have a valid
EGLSurface when creating a non-offscreen GLContext. This patch falls
back to a dummy pbuffer surface or EGL_NO_SURFACE if supported, allowing
the GLContext creation to succeed. This will give us some more flexibility
on Android where the widget surface is not always readily available.
Additinally, we use the fallback surface any time MakeCurrent() is
called without a valid surface. This is needed to allow things like
Compositor shutdown when there is no widget surface available.
MozReview-Commit-ID: 1kbLIGNiOkV
We are going to re-enable the assertion with a proper fix in bug 1459775.
MozReview-Commit-ID: 2jy6vIImqD
--HG--
extra : rebase_source : ce81b8b2f7dfb47f7db07e820989a65eac38859a
The majority of this patch is just plumbing. The interesting parts are
in WebRenderLayerManager and APZUpdater/WebRenderScrollData. Unlike
ClientLayerManager, which updates the FrameMetrics on the client side
and sends the modified version over to the compositor, this WR version
just sends the update info over to the compositor, which then applies
the update to the metrics saved in APZUpdater before triggering the
hit-testing tree rebuild.
MozReview-Commit-ID: 4latUMa8RFw
--HG--
extra : rebase_source : d0aeaf5a9c8107bbcaf8b0da6d68a0f47f455be5
This allows frames to be generated by the render backend thread even
while the scene builder thread is busy with a long scene build. The
GenerateFrame transaction also contains APZ and OMTA information, so
this allows the user to scroll and view OMTAnimations during long scene
builds.
MozReview-Commit-ID: KG5YC2KwIaH
--HG--
extra : rebase_source : 3ba559aa22a3a036a3b3a034ea20caacdc8c864a
Read more information from the printing device to setup the unwritable region.
Translate the printing context's coordinate system so that the point (0,0)
refers to the top-left of the physical paper instead of the top-left of the
printable region.
MozReview-Commit-ID: 9ei2FgEUDyO
--HG--
extra : rebase_source : c2e2715f47499538035101a285152eca2aba3202
This ensures that only people with qualified hardware can flip prefs to
enable WebRender on beta and release. Nightly users will still be able
enable WebRender on unqualified hardware.
MozReview-Commit-ID: E5sgzZhuX4p
--HG--
extra : rebase_source : a4e85e71e4d85b5d9f1e17c1413ca9690349f75a
Move from nsStyleColor::CalcComplexColor to StyleComplexColor::CalcColor.
MozReview-Commit-ID: FkYovvPZLc8
--HG--
extra : rebase_source : 54f1966e0ef9258f20e954cd6250774008eca04c
In particular, this change makes it so that we are not holding the lock
when we clone the WebRenderAPI, because that can result in a deadlock.
MozReview-Commit-ID: 33OGZdFMjEA
--HG--
extra : rebase_source : 4a1aeb81e3316a119d6b0aa798d827314543a70b
This commit moves FlushAsyncPaints to EndTransactionInternal, which allows
us to continue async painting during DLB and FLB. We still flush async paints
before rasterizing into layers as we aren't triple buffered.
--HG--
extra : amend_source : 6ee4f511008c60fe1f52f7a260ef7d5b5e3c0c92
In bug 1443424, the CompositorHitTestInfo for a thumb frame was modified
to only contain the thumb flag if it was layerized. The mochitests were
disabled at the time and so didn't make a fuss.
MozReview-Commit-ID: Argqj8KbnqU
--HG--
extra : rebase_source : 5b4b38fdbeb17c8434be202f20fee5b7e19a66b7
Instead of printing out base-10 numbers like "expected 67" this will
print out a nicer "expected VISIBLE | DISPATCH_TO_CONTENT | SCROLLBAR"
which makes it easier to see which flags are missing from the hit info.
MozReview-Commit-ID: gp9ERBIgYj
--HG--
extra : rebase_source : 6f73ae8598d525227bcbaed2e9de1e24d7915355
Any more specific work that is happening in these methods will have its own
specific category labeling in that specific code. The instances touched in this
patch are more on the outside and don't really know what kind of code is going
to be running inside.
MozReview-Commit-ID: 47NO1DZzkdH
--HG--
extra : rebase_source : 344c380ddaaf42a1fd820a26b762c61ee9e2d524
Any more specific work that is happening in these methods will have its own
specific category labeling in that specific code. The instances touched in this
patch are more on the outside and don't really know what kind of code is going
to be running inside.
MozReview-Commit-ID: 47NO1DZzkdH
--HG--
extra : rebase_source : f807c14bf6a592e0c651e15b63d1e7d63e4b0159
All animated images on a page are currently registered with the refresh
driver and advance with the tick refresh. These animations may not even
be in view, and if they are large and thus cause redecoding, cause a
marked increase in CPU usage for no benefit to the user.
This patch adds an additional flag, mCompositedFrameRequested, to the
AnimationState used by FrameAnimator. It is set to true each time the
current animated image frame is requested via
FrameAnimator::GetCompositedFrame. It is set to false each time the
frame is advanced in FrameAnimator::AdvanceFrame (via
FrameAnimator::RequestRefresh). If it is true when
FrameAnimator::RequestRefresh is called, then it will advance the
animation according to the normal rules. If it is false, then it will
set the current animation time to the current time instead of advancing.
This should not cause the animation to fall behind anymore or skip
frames more than it does today. This is because if
FrameAnimator::GetCompositedFrame is not called, then the internal state
of the animation is advancing ahead of what the user sees. Once it is
called, the new frame is far ahead of the previously displayed frame.
The only difference now is that we will display the previous frame for
slightly longer until the next refresh tick.
Note that if an animated image is layerized (should not happen today) or
otherwise uses an ImageContainer, this optimization fails. While we know
whether or not we have an image container, we do not know if anything is
actively using it.
We no longer need them since in the previous commit we make sure subsequent
ticks happens for animations in delay phase.
MozReview-Commit-ID: F68wCCsCEiE
--HG--
extra : rebase_source : d6ebe9bfa90a767154cea04255dbf4a5403674fe
mAnimStorage->AnimatedValueCount() returns zero in the case where all
animations are in delay phase, even in such case, we should update the previous
timestamp.
MozReview-Commit-ID: 5Dds1YjfVh9
--HG--
extra : rebase_source : 759b7b4d9e5aa23542a31593674683fbef2dbc47
If the animation is in delay phase, we shouldn't produce any values for the
animation but we have to make sure subsequent ticks happen in order to the time
when the animation starts. So what we should do here is that
1) Make AnimationHelper::SampleAnimations() return boolean, return true if
there is any animation.
2) Schedule the next tick if AnimationHelper::SampleAnimations return true
This setup is equivalent to what we do non-WebRender.
So that we don't need to set non-animated value as AnimatedValue for delay
phase to make subsequent ticks happen for the delay phase animations. The
non-animated value will be dropped in the next patch.
MozReview-Commit-ID: IwltLGgvT7K
--HG--
extra : rebase_source : f2c59cb3bdb3affc5846e65ccbaad7dbc069d0ad
The test case has a fixed item A inside a scrollframe B which is inside
a reference frame C which is inside the root scrollframe D. The
ClipManager code currently uses D's scrollid as the scrolling ancestor
for A, because the gecko display list's ASR is set up that way. However,
we really want to set C as the scrolling ancestor, because otherwise the
item A gets hoisted out of C and the transform from C doesn't get
applied to it. This patch ensures that when we enter C, we install an
override so that anything that would have used D's scrollid ends up
using C's, which results in the correct behaviour.
MozReview-Commit-ID: 31tscfT4xWW
--HG--
extra : rebase_source : 03df2fa5519b2592a2c9f598af0f3f1500773718
This is just plumbing, no functional changes yet.
MozReview-Commit-ID: FlmnMVammse
--HG--
extra : rebase_source : edede45a77a829dbd125dc1f18a4c2a4bc8087c1
This ensures the commands to delete compositables are received by WR in the same
transaction as the updates to the display list that removes the references to
those compositables. Otherwise, WR can try to do a scene build on the intermediate
state which results in missing pipeline errors.
MozReview-Commit-ID: ByOHCFWSSjt
--HG--
extra : rebase_source : bcc0f129cbd75e3e9e3543236591b22687d39090
The clip chain API in webrender allows us to build the clip state in WR
so that it matches the gecko display list more closely. This patch throws
away ScrollingLayersHelper.* and introduces ClipManager.* which pushes
the clip state to WR using the new method. A quick summary of the new
method is below.
Each display item in gecko has a DisplayItemClipChain which is a chain
of individual clips. The individual clips are defined in WR, and the
clip ids for those clips are put into a WR clip chain using the new
define_clip_chain API. Furthermore, each clip chain can also have a
parent chain, which is used to link a DisplayItemClipChain to the parent
display item's DisplayItemClipChain. This allows the WR clip state to
closely match the structure of the gecko display list clip state,
resulting in more correct behaviour.
There are a few other major changes that are lumped into this patch and
that were tricky to separate into their own patches:
- The collapsing of WrScrollId and WrStickyId into WrClipId. On the WR
side all the clip ids are treated the same anyway. Trying to preserve
the arbitrary distinction on the gecko side was resulting in
increasingly convoluted code, with different kinds of Variant<..>
types in the method signatures. It was much simpler and resulted in a
bunch of code deletion to just collapse the types.
- Moving the "override" mechanism from WebRenderAPI to ClipManager. The
override mechanism (explained in ClipManager.h) was simplified by
moving it into ClipManager, because it removed the need for tracking
additional clip stack state in WebRenderAPI.
MozReview-Commit-ID: GGbdFyJGprK
--HG--
extra : rebase_source : baa56ff179e917b0ab5a5c186a3a415761f8050a
This is a refactoring that moves the "parent clip id" determination from
bindings.rs into WebRenderAPI.cpp. This should be functionally
identical.
MozReview-Commit-ID: 36rQmsH5E7J
--HG--
extra : rebase_source : f376e71f7681ec3f67e0ab4f2e3035da4edf2a5b
MayResample() is used on the content and compositor to determine whether the whole
visible region should be or should have been validated. This calculation is done
partially by traversing ancestor layers and looking for a flag. This can return
different values then in the content side versus the shadow side, which in this
case leads to artifacts.
This commit tries to solve the problem by ignoring layers that content is unaware
of. This works, but has the downside that resampling artifacts could show up if
the parent process is truly doing animations that require resampling.
MozReview-Commit-ID: 4TW6nzxS6E
--HG--
extra : rebase_source : 0bc82d09686245599b12c42af812b454875291f6
extra : amend_source : 6b423326a2952125468af13f0041e3daff40362f
When a transform thinks it's animated we should abandon screen rasterization
and instead favour local rasterization. This produces a more visually
pleasant rendering, as pixel-snapping "wobbles" the text between
frames.
The float scale of GlyphRasterSpace::Local is currently unused, but this
PR tries its best to set it to a reasonable value, based on discussion
with glennw about the intended semantics. We agreed it should specify
the scale *relative* to the parent stacking context, which means it's
just whatever scaling the stacking context's transform applies. It's
possible we'll need to clamp this value or make it properly 2-dimensional
later on.
Some book-keeping is added to StackingContextHelper to ensure that
GlyphRasterSpace::Screen is never requested by a descendent
of a stacking context using GlyphRasterSpace::Local.
nsDisplayMask is changed to use a StackingContextHelper to ensure
rasterSpace is properly propagated.
In addition, this is the first commit making use of cbindgen's new support
for bridging Rust enums natively into C++! This bumps our minimum cbindgen
to 6.0.0 (just released).
MozReview-Commit-ID: 9AlsB6nUheB
--HG--
extra : rebase_source : 247e5b197e998682cb4bb74f6f9319a9a4dd3264
The original code was added in bug 385263 for fixing bug 279032 that a
single font provides zero for max ascent / descent in its HHEA table
which caused Firefox to crash.
Unconditionally picking the maximum of max ascent / descent and their
em correspondents doesn't seem to be essential for working around that
case, so this patch changes it to just use the em ascent / descent when
both max ascent and descent are zero.
This fixes a webcompat problem related to Roboto font on Linux (and
presumably also Android given it uses FreeType backend as well).
MozReview-Commit-ID: EpKrfiOwnZt
--HG--
extra : rebase_source : 0619abf992fb1e1a1f3068ab172880913ebff1f1
The patch in question is not strictly necessary to fix bug 1458063, and was
causing intermittent failures.
MozReview-Commit-ID: 1llW2BkmcXn
--HG--
extra : rebase_source : 858c3848f00f8a4feafb6815ea578d380533cbd8
On windows it's possible for us to fallback from D2D to Skia rendering at any time due to a device reset.
If this happens with `enable-tiles-if-skia-pomtp` enabled we could begin to use tiling. This can cause a
crash if we never created the worker threads because at initialization time we weren't using tiling.
Another way to fix this would be to dynamically create the worker threads in UpdateRenderMode if we
have switched to skia. That's a larger change and more might be required, so I'd rather just fix the
crash for now.
This commit also fixes a pref that should be `Once` instead of `Live`.
MozReview-Commit-ID: JQidXPjI7ER
--HG--
extra : amend_source : ba9a3746faea3a7355251b7e97e3f7c5dc1ba06b
The purpose of the previous timestamp is to reduce the time difference between
the timestamps on the main-thread and the compositor. Once we skipped a frame
to compose animations on the compositor, the timestamp is far behind from the
timestamp on the main-thread, so we should clear it.
MozReview-Commit-ID: EGiQfwejfsy
--HG--
extra : rebase_source : 7c382116b93b27feb6e70e394ebad543ec8bfda5
This rearranges how synthetic-bold use is determined in the font selection
& rendering code. Previously, we would decide during the font-selection
algorithm whether we need to apply synthetic-bold to the chosen face, and
then pass that decision through the fontgroup (storing it in the FamilyFace
entries of the mFonts array there) down to the actual rendering code that
instantiates fonts from the faces (font entries) we've selected.
That became a problem for variation fonts because in the case of a user
font, we may not have downloaded the resource yet, so we just have a "user
font container" entry, which carries the descriptors from the @font-face
rule and will fetch the actual resource when needed. But in the case of a
@font-face rule without a weight descriptor, we don't actually know at
font-selection time whether the face will support "true" bold (via a
variation axis) or not, so we can't reliably make the right decision about
applying synthetic bold.
So we now defer that decision until we actually instantiate a platform font
object to shape/measure/draw text. At that point, we have the requested
style and we also have the real font resource, so we can easily determine
whether fake-bold is required.
(This patch should not result in any visible behavior change; that will
come in a second patch now that the architecture supports it.)
With async scene building, we might get the message to delete certain
compositor animation ids while we are still building and rendering
scenes that have those compositor animations. This patch associates
those ids with the epoch at which they are safe to delete, and only does
the deletion once we have rendered that epoch.
MozReview-Commit-ID: Jetfcdtwt1q
--HG--
extra : rebase_source : f06b8ee62e460432e8faed670e928f60cb6bc915
This also rearranges the method implementation slightly to make the next
patch easier to read. This patch should have zero functional changes,
it's just refactoring.
MozReview-Commit-ID: 53StJ0TH3IT
--HG--
extra : rebase_source : 2f3aeb54271da75a7e051afc24b8a4c96f8496f2
Before this change, the value which was set by SetShadowBaseTransform()
has been used for the assertion, but it is possible that the value is changed
by APZ. And it's hard to tell whether the value has been changed by APZ or not
and it's hard to *reverse-calculate* the differences in the past APZ at the
moment we want to do the assert.
So after this patch, on debug build we don't actually skip the calculation for
unchanged animations and use the newly calculated value for the assertion.
MozReview-Commit-ID: 8fCcvvbUMHe
--HG--
extra : rebase_source : 0ff5e7100ad33a690bb0edd02af2b00c749afbbe
Ryan Hunt
shindli
Lee Salzman
Martin Stransky
Margareta Eliza Balazs
Matt Woodrow
Hiroyuki Ikezoe
Dorel Luca
Jonathan Kew
Kartikaya Gupta
Bogdan Tara
Jed Davis
Narcis Beleuzu
Adrian Wielgosik
James Willcox
sotaro
Kearwood Gilbert
Brindusan Cristian
Alexis Beingessner
YUKI "Piro" Hiroshi
Brian Birtles
Bob Owen
Brendan Dahl
Dan Glastonbury
Xidorn Quan
Tom Ritter
Noemi Erli
Jan-Ivar Bruaroey
Stephen A Pohl
Csoregi Natalia
Markus Stange
Nicolas Silva
Andrew Osmond
Ciure Andrei
Coroiu Cristina
arthur.iakab
ffxbld
Chris Peterson
Martin Robinson
Milan Sreckovic
Botond Ballo
Cosmin Sabou
Bas Schouten
David Major
Jonathan Watt
Gurzau Raul
Masatoshi Kimura
Andreea Pavel