Just a cleanup patch, this function would be cleaner without the
nesting.
MozReview-Commit-ID: DD48E2HSQOL
--HG--
extra : rebase_source : 79cf6b3eee00149fa5993c10bd69649633307fee
extra : histedit_source : 1fde6b0291acddcf73569b2e43757030c38d9e69
This updates the not-really-correct code to flush the WR pipeline before
doing a readback. It now uses the flushing functions introduced in bug
1417784 to ensure things are flushed properly.
MozReview-Commit-ID: 90BZuLKcjUi
--HG--
extra : rebase_source : 2180aa0ac7ff7b46467e0c24094fcc99479120f7
This updates the GetTargetAPZC function to produce a
HitTestingTreeNodeAutoLock out-param instead of a
RefPtr<HitTestingTreeNode>, to ensure that the node can be used safely
in calling functions. It then propagates that change outward as needed,
which covers all the scrollbar dragging code.
MozReview-Commit-ID: 43K4eSECb4E
--HG--
extra : rebase_source : b34a880c6fd60069f7a4fa0527cbb5e903085356
This adds the HitTestingTreeNodeAutoLock RAII class that allows using
a HitTestingTreeNode safely outside a tree lock, and ensures that the
node won't get destroyed or recycled concurrently.
MozReview-Commit-ID: 8Tb3vdIeUgr
--HG--
extra : rebase_source : 6eed3e733edcaa4088da52882a9b3dc8c2355c2e
This patch makes three related changes:
- A non-functional change that factors a IsRecyclable function on
HitTestingTreeNode.
- A non-functional change that sprinkles proof-of-tree-lock arguments to
a few HitTestingTreeNode functions, to ensure at compile-time that they
can only be called while holding the tree lock.
- A functional change that stops clearing mLayersId in
HitTestingTreeNode::Destroy, so that if a node is non-recyclable, and
it gets Destroy()'d while other code still has a RefPtr to it, that
other code can still read the layers id off in a safe manner.
These changes provide a stronger set of checks around node recycling,
and allows for a safe mechanism to use a HitTestingTreeNode on the
controller thread without having to lock the entire APZ tree. The
mechanism is effectively a per-node lock, which will be added in the
next patch.
MozReview-Commit-ID: DBIjFDZJwhE
--HG--
extra : rebase_source : 318c27c4473e54b30a0393fca6c2fc76083036b2
We can easily use Maybe<DataSourceSurface::ScopedMap> instead of
allocated the map on the heap. This does require some minor changes to
ScopedMap to properly support moves, but should be much more efficient.
This defines three flushing functions that flush different parts of the
WR pipeline. Using all three guarantees that everything sent to WR will
have been flushed. This is what we need to do in SyncWithCompositor to
ensure that it meets the API contract.
In addition, this patch updates the existing FlushRendering function to
use the new functions (no functional changes intended here).
MozReview-Commit-ID: GzxwpF4JT04
--HG--
extra : rebase_source : 1a8cf434d1280902906da257ae63751da7ffd114
Instead of notifying the AsyncImagePipelineManager on the compositor
thread via the CompositorBridgeParent, we can send it the new pipeline
info directly from the RenderThread after the update happens. This
effectively splits the AsyncImagePipelineManager update-processing into
two parts: one that takes in the new pipeline info and one that process
it. This allows us to invoke the processing step from other code running
on the compositor thread, which we will need to do in the next patch.
MozReview-Commit-ID: 7xhm8I7bY4C
--HG--
extra : rebase_source : bfa62e326fd830bc2ef771138e5008fb2bc0d6b8
We do a silent upcast from CompositorBridgeParent* to the base class and
pass it around as a CompositorBridgeParentBase* for no reason. Avoiding
this simplifies the code slightly and avoids virtual function overhead.
We do need to move a couple of functions in CompositorBridgeParent from
protected scope to public scope.
MozReview-Commit-ID: 9Zq3GwxEXpr
--HG--
extra : rebase_source : 67346159e7d99ca7fc2fe0052e85aa6618b50d27
In order to have useful Wayland builds we need ability to switch
between GL backends run-time - to use EGL backend for Wayland and GLX backend for X11.
GL_PROVIDER_GLX is used exclusively for GLX GL backend, so let's replace GL_PROVIDER_GLX
build-time check by more general MOZ_X11 check which determines X11 dependent code
and it's valid for both X11 and Wayland builds.
MozReview-Commit-ID: HYobrHveoaP
--HG--
extra : rebase_source : 2d359355ee747f5898d27d8a28d66114f4135f5b
GLContextProviderWayland provides both GLX and EGL GL backends on Wayland enabled builds
according to an active Gtk+ backend (X11/Wayland).
MozReview-Commit-ID: TTBDwWMBAP
--HG--
extra : rebase_source : 26e0455ae3775bdcea83deffbb8ad43aacdb3e42
It has greatly regressed with recent AMD drivers, providing worse performance than the software decoder under most circumstances.
MozReview-Commit-ID: Jtabi1qhoYF
--HG--
extra : rebase_source : 555e3bfdad18753079ccdcdd10261d68bbdaaad1
Wayland on desktop does not support/implement PBuffer. As a workaround
we create a dummy wl_egl_window instead and render to it.
As a side effect we need to store and release this wl_egl_window along
the associated EGLSurface on Wayland.
MozReview-Commit-ID: 1NlzZsOzXz9
--HG--
extra : rebase_source : 13f776ad0a9079f7155ba523b61f93441bf7fd5f
In cases where we were carrying down a transform from a
nsDisplayTransform and then applying it to a child item's WRLSD, we
could get incorrect behaviour when that child item had a different ASR
(and therefore had a different APZ instance). This patch corrects that
behaviour by ensuring that when we run into this case we fall back to
creating two WRLSD items instead of one, where the new WRLSD is the
parent of the other one, and holds the transform. The child WRLSD has
the data from the child item's ASR.
MozReview-Commit-ID: BE6HuZjwc8v
--HG--
extra : rebase_source : 436e81d1b6b1fcda44ef77b21eb893075d294f41
Instead of just storing the gfx::Matrix from the nsDisplayTransform on
the stacking context for scrolldata use, we now store a pointer to the
entire nsDisplayTransform item. We will need this in the next patch.
This patch should not have any functional changes.
MozReview-Commit-ID: 7qsZpL3Ka0X
--HG--
extra : rebase_source : b42957c83ef0591e72fa5b58ceb6650fda96e0b2
The ceiling was introduced in bug 549190 for improve the consistency of
underline positioning. However, removing ceiling now doesn't seem to
regress the testcases in that bug, probably thanks to improvement in
other part.
The ceiling here causes us to have different font metrics than other
browsers on Windows, and can lead to webcompat issue. We also don't do
this for other backends. So it's probably better removing it in favor
of rounding.
There are several test changes:
* min-intrinsic-with-percents-across-elements.html changes result due to
height of wrapping div in reference page depends on line height, so a
fixed line height is set to work around the issue.
* 368020-1.html changes result because a slightly different line-height
triggers bug 1462514. It is changed to use fixed line-height to work
around the issue.
* 456147.xul is disabled because it compares XUL against HTML page, but
XUL has different approach to position text in its elements than HTML.
Specifically, XUL elements don't seem to respect line height while
HTML elements do. The original line height in the file was probably
chosen to make the HTML match XUL, so it seems to be non-trivial to
fix it in a platform-independent way.
* sizing-orthog-{vlr,vrl}-in-htb-{008,020}.xht fails due to text in <p>
after the testing block shifts 1px up for unknown reason.
MozReview-Commit-ID: 2WJG1AigWl1
--HG--
extra : source : 653c6b7480997c4e1dbead5f0441bc06a0605b7a
Patch originally developed on bug 1458921 but needs to land with the WR update.
MozReview-Commit-ID: 82BYyNWBAfn
--HG--
extra : rebase_source : e6bca2f446c019fd41a37c2c28db73bbe1cfc216
The ceiling was introduced in bug 549190 for improve the consistency of
underline positioning. However, removing ceiling now doesn't seem to
regress the testcases in that bug, probably thanks to improvement in
other part.
The ceiling here causes us to have different font metrics than other
browsers on Windows, and can lead to webcompat issue. We also don't do
this for other backends. So it's probably better removing it in favor
of rounding.
There are several test changes:
* min-intrinsic-with-percents-across-elements.html changes result due to
height of wrapping div in reference page depends on line height, so a
fixed line height is set to work around the issue.
* 368020-1.html changes result because a slightly different line-height
triggers bug 1462514. It is changed to use fixed line-height to work
around the issue.
* 456147.xul is disabled because it compares XUL against HTML page, but
XUL has different approach to position text in its elements than HTML.
Specifically, XUL elements don't seem to respect line height while
HTML elements do. The original line height in the file was probably
chosen to make the HTML match XUL, so it seems to be non-trivial to
fix it in a platform-independent way.
* sizing-orthog-{vlr,vrl}-in-htb-{008,020}.xht fails due to text in <p>
after the testing block shifts 1px up for unknown reason.
MozReview-Commit-ID: 2WJG1AigWl1
--HG--
extra : rebase_source : 540e68ffff618a6dc3c14b3702b2c042988061a3
The ceiling was introduced in bug 549190 for improve the consistency of
underline positioning. However, removing ceiling now doesn't seem to
regress the testcases in that bug, probably thanks to improvement in
other part.
The ceiling here causes us to have different font metrics than other
browsers on Windows, and can lead to webcompat issue. We also don't do
this for other backends. So it's probably better removing it in favor
of rounding.
There are several test changes:
* min-intrinsic-with-percents-across-elements.html changes result due to
height of wrapping div in reference page depends on line height, so a
fixed line height is set to work around the issue.
* 368020-1.html changes result because a slightly different line-height
triggers bug 1462514. It is changed to use fixed line-height to work
around the issue.
* 456147.xul is disabled because it compares XUL against HTML page, but
XUL has different approach to position text in its elements than HTML.
Specifically, XUL elements don't seem to respect line height while
HTML elements do. The original line height in the file was probably
chosen to make the HTML match XUL, so it seems to be non-trivial to
fix it in a platform-independent way.
* sizing-orthog-{vlr,vrl}-in-htb-{008,020}.xht fails due to text in <p>
after the testing block shifts 1px up for unknown reason.
MozReview-Commit-ID: 2WJG1AigWl1
--HG--
extra : rebase_source : 6c61fa95a3b01e7b439be46a2498b4f893d8b84b
We should always have the pipeline information for in-process things like
async images, but for cross-process iframes we might not have the information
right away if the content process doesn't get around to sending it for a while.
MozReview-Commit-ID: 18F5nqilXoV
--HG--
extra : rebase_source : 610046cbaaefb38b8e11bda857fd64a00722df27
This lets us improve the illuision that there's not an intermediate surface
being used when drawing SVG. i.e. if content is transformed by 0.5px
the 0.5px transform is included when drawing the SVG content.
MozReview-Commit-ID: ChfbTFblVdR
--HG--
extra : rebase_source : 24144fe05b73ceeaa8499218fdae82035f674e39
Capture a snapping surface transform. This is used
by svg/blob code to compute an fractional offset
to the nearest intermediate surface.
MozReview-Commit-ID: 6EFNvluvzvA
--HG--
extra : rebase_source : f26e7fa823883e93742970c2e8d687319a7eaf5b
I believe this was a left-over from an old strategy where we didn't clear the
items, tried to reuse them but kept made an invalid rect for the old size. Now
that we clear the items this shouldn't be needed. I added the assert to make
sure things are what we expect.
MozReview-Commit-ID: 9btmmSmkl8S
--HG--
extra : rebase_source : 698f4a7e0fb802698f3e86b9fa8e654c5d604ec4
Even if the sticky item has a fixed descendant, we want to use the
sticky container item's "real" ASR when computing the WR clips because
otherwise the WR item doesn't get attached to the correct scrolling
layer.
MozReview-Commit-ID: JVnzEIBeLKp
--HG--
extra : rebase_source : 806e43eb65d46eb5151e21b0a5eb09168b2df82d
This is the other half of the commit renaming the TileUnit to TileCoordUnit. It
also includes some small style cleanups.
--HG--
extra : rebase_source : ebf7a275bed518d1419a2e3c23b67f36601a1089
