The image decoding thread pool can grow to be quite large, up to 32
threads, depending on the number of processors on the system. If the
user is not actively browsing, these threads are occupying resources
which could be reused elsewhere. After the timeout period, it will
release up to half of the threads in the pool.
Move the initialization of SharedSurfacesParent from the compositor
thread creation to mirror the other WebRender-specific components, such
as the render thread creation. Now it will only be created if WebRender
is in use. Also prevent shared surfaces from being used by the image
frame allocator, even if image.mem.shared is set -- there is no purpose
in allowing this at present. It was causing startup crashes for users
who requested image.mem.shared and/or WebRender via gfx.webrender.all
but did not actually get WebRender at all. Surfaces would get allocated
in the shared memory, try to register themselves with the WR render
thread, and then crash since that thread was never created.
The recovery is only enabled for release builds, to avoid papering over
such hit testing bugs. On nightly builds, a diagnostic assert is issued.
MozReview-Commit-ID: Aos0j0jv6Lb
--HG--
extra : rebase_source : 1cb7fa24ed1f3cba7344f52670626bdeb41b51cc
When ContentChild::RecvInitRendering is received, it tries to setup the
IPDL actors related to rendering. If the GPU process crashes before or
during this process, it will fail, and cause the content process to
crash as well. This is unnecessary because the UI process will either
restart the GPU process, or subsume its job into itself, and trigger
ContentChild::RecvReinitRendering. It is a similar case for failures in
ContentChild::RecvReinitRendering.
Since the GPU process crashing should be a recoverable scenario, we now
check if the remote IPDL actor is in the UI or the GPU process. If it is
in the UI process, it will fail/crash as it does today. If it is in the
GPU process, it will wait for the next
ContentChild::RecvReinitRendering.
For failures that are not IPDL related (e.g. failed to get some resource
like spawning a thread), we release assert specifically for those
failures. They are not recoverable.
This commit introduces a lock on each FilterNodeSoftware around the cached surface.
This lock must be acquired whenever the cached surface is accessed. Currently this
is when the Filter is invalidated or painted.
When painting we only hold the cache lock when determining if we need to compute
a new surface, and after we have computed that new surface. This allows another
thread that may be painting that filter node at a different rect to not contend
on the cache. This is just theoretical though as DrawTargetTiled doesn't clamp
the source rect of the Filter command to the tile rect.
MozReview-Commit-ID: KFVZ35e1czB
--HG--
extra : rebase_source : a22918df80a24fad216a834a5737249cab570f08
This is a just a back out of changeset 6882857e1bb5.
MozReview-Commit-ID: 9Z6iEHl3eAy
--HG--
extra : rebase_source : 3d091c72a6e589e702d90ffe6800e131b009604b
The image decoding thread pool can grow to be quite large, up to 32
threads, depending on the number of processors on the system. If the
user is not actively browsing, these threads are occupying resources
which could be reused elsewhere. After the timeout period, it will
release up to half of the threads in the pool.
We will re-use these methods to perform various calculations once we introduce
the pending playback rate.
MozReview-Commit-ID: 2HV44TTNxHg
--HG--
extra : rebase_source : 19e32b13c6fee9cfe9993918557f2433aa687e11
The change to RootAccessible.cpp fixes an obvious bug introduced in bug 741707.
The visibility changes in gfx/thebes are because NS_DECL_ISUPPORTS has a
trailing "public:" that those classes were relying on to have public
constructors.
MozReview-Commit-ID: IeB8KIJCGhU
There's only one caller so let's just eliminate inline FillAzure into
Fill.
MozReview-Commit-ID: JYpAQMkhEcS
--HG--
extra : rebase_source : 962b046405949d435537a77baea50f631a8aee72
Add a command CreateClippedDrawTarget to DrawTarget, which takes the
max required size and a transform between this draw target and the one
to be created. The created draw target may have its size clipped to
the size of this draw target, transformed to the new target's
space. This means that the new surface will be large enough so
that it is rendered to this draw target correctly, but not necessarily
any larger.
Usually this will just create a draw target of the requested size, for
simplicity. However, when replaying a recorded draw target we do clip
the size to the base draw target's size. This is done using a
DrawTargetTiled, so when applying the mask in PopLayer, we must take
the SourceSurface's offset in to account.
MozReview-Commit-ID: 89ONElphzLu
--HG--
extra : rebase_source : 7eebeb66a2686a7b6f4ade36f3004ebb06abc2fe
Fix the DrawTargetTiled::mRect initialization, and expose through the
virtual function GetRect(). Make SnapshotTiled::GetDataSurface()
allocate a surface the size of this rect, rather the XMost and
YMost. Callers of SourceSurface::GetDataSurface() can query
SourceSurface::GetRect() and apply the necessary offset themselves.
MozReview-Commit-ID: C31FGirQ0oK
--HG--
extra : rebase_source : ac31ae3ca0a0b188f9293c4e6898b4e4a65cad0e
Changing the transaction id allocator is now handled better in
ClientLayerManager than before in that it resets the transaction id on
the new allocator to match the old allocator and avoid discontinuities
in the transaction ids. We should apply this behaviour to
WebRenderLayerManager as well, because WebRenderLayerManager was
assuming that any time the allocator changed it would automatically
start the transaction id at 1, which is not the case. In particular,
when navigating to something in the bfcache, we can reuse a pre-existing
refresh driver which might have a transaction id already greater than 1.
MozReview-Commit-ID: 8IUn1Dhnh7c
--HG--
extra : rebase_source : 0e98c96d9636c3a3ee0489ff6b6161bce7677dd7
bug 1379920 changed the way of dirty flag handling. And the dirty flag was not set when CopyableCanvasRenderer::ClearCachedResources() is called. Then ShareableCanvasRenderer::UpdateCompositableClient() did not update canvas.
The important part here is that the test parent page
(test_bug1151663.html) waits for paints to complete before spawning the
helper window. Otherwise, the helper window might think it's done
painting (because it is) and start running the test even though its
layer tree has not been attached to the chrome layer tree. In such a
scenario reading the APZ test data produces an empty tree for the
content layers id and causes the test to fail.
This test was written before we had waitUntilApzStable so sprinkling some
of that into the test makes it more robust in general as well.
MozReview-Commit-ID: J8rqW6dcy23
--HG--
extra : rebase_source : f9e28bd15f355c88649ff1797b1f1205824bf815
A Box is like a Rect but represented as (x1, y1, x2, y2) instead of
(x, y, w, h).
The API is bare-bones at the moment; it can be extended as needed
by future users.
MozReview-Commit-ID: FWv69Y5hP6t
--HG--
extra : rebase_source : 1f717727bc724842a2f6adcba9e6cbbe50059436
The struct initially stores just one flag, mTargetConfirmed, but is
introduced with the intention of expanding it to store additional ones.
MozReview-Commit-ID: 88255UvoYYQ
--HG--
extra : rebase_source : 6826899367d19decbb6da0b3d25f32758c46dcec
We will re-use these methods to perform various calculations once we introduce
the pending playback rate.
MozReview-Commit-ID: 2HV44TTNxHg
--HG--
extra : rebase_source : dcc883fb6db897a799900d709ca9c182dc149764
The only call to IsBackfaceVisible() was removed when we added proper backface
visible support.
MozReview-Commit-ID: ALAF4a0ScQJ
--HG--
extra : rebase_source : 9a138f9ca4244105b4692b340c95e1dbc03f0356
When comparing a Maybe<WrScrollId> to another WrScrollId we need to properly
handle the case where Nothing() signifies the root scroll frame. This is
equivalent to calling scrollId.valueOr(FrameMetrics::NULL_SCROLL_ID), as was
done before WrScrolLId replaced ViewId in the WebRender ScrollingLayersHelper.
We also have DisplayListBuilder::TopmostScrollId always return a value instead
of a Maybe, since an empty clip stack means that the current scroll id is that
of the root scroll frame.
Previously Nothing() was not equivalent to WrScrollId { 0 }, which caused the
ScrollingLayersHelper to fill the mClipAndScroll value and push another
set of clip and scroll nodes onto the WebRender display list builder.
MozReview-Commit-ID: CeatZlRXtuI
It looks like the call chain is called ScheduleComposite on the client
LayerManager API, but then for some reason the functions in the IPDL
bridges are called ForceComposite, and then they eventually call the
ScheduleComposition function on the CompositorVsyncScheduler. This is
silly, so I renamed the IPDL bridge functions to ScheduleComposite as
well to be consistent.
MozReview-Commit-ID: D7bWpASaEtb
--HG--
extra : rebase_source : ecb0494d9461bd4ada48bfb602e7b518f0601c1b
This function is not overridden, so there doesn't seem to be any value
in making it virtual.
MozReview-Commit-ID: 8K34xTGtBc7
--HG--
extra : rebase_source : c7ad229f4b4de1a1ed8b8f8e782a21082c4abb12
This patch takes the safest route for securing modifications to the dependency graph for D2D DrawTargets. It's possible a slightly optimal approach is possible, however lock contention should be rare and I believe this is the safest and most upliftable approach.
MozReview-Commit-ID: HGfSdEp2U5N
This patch takes the safest route for securing modifications to the dependency graph for D2D DrawTargets. It's possible a slightly optimal approach is possible, however lock contention should be rare and I believe this is the safest and most upliftable approach.
MozReview-Commit-ID: HGfSdEp2U5N
This patch changes this file to use the exact C++ mode lines from the
Mozilla coding style guide, available here:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Mode_Line
(The automated modeline.py script won't do this on its own for this one file. I
think that's because this file has the vim & emacs modelines in the reverse
order from the standard Mozilla syntax, and modeline.py is conservative and
won't change syntax that it doesn't immediately expect/understand.)
MozReview-Commit-ID: 7R1DUBEvFFh
--HG--
extra : rebase_source : eb802806375cf7d6f6fb0626220b1a510b375cdb
SetTestSampleTime is called from tests via the advanceTimeAndRefresh API
on DOMWindowUtils, and the expectation is that after it is done, the
time has been advanced and a composite has happened. So we need to
ensure that is the case with WebRender as well. This fixes the issue I
was seeing with test_group_hittest.html and makes it pass.
MozReview-Commit-ID: 86l9mTTwD2v
--HG--
extra : rebase_source : d2921fb0f9b09f4366fb516e4a6254a7f13f3e4e
This splits the FlushRendering function into sync and async versions
just for a bit more clarity. In the async version we don't want to set
the mForceRendering flag at all because we don't need to force a
rendering - if there is one already pending then that's good enough. And
anyway in practice the async version seems to only ever be invoked by
CompositorBridgeParent::SetTestSampleTime which I'll be changing in the
next patch.
MozReview-Commit-ID: 4cdU0U5B1pp
--HG--
extra : rebase_source : d7842844fca758d53121e3326d8da7fb7592ad8b
This extracts a code pattern that appears a couple of times in the code.
It occurs in CompositorBridgeParent as well but there's some extra stuff
involved there with the mOverrideComposeReadiness flag that I don't
understand so I'm leaving that as-is for now.
MozReview-Commit-ID: 2xqgaQZT4e1
--HG--
extra : rebase_source : 294727f146bbe5323a2cbdaa511dac5a4fc81571
GetGfxInfo returns an already_AddRefed, you can't just forget about its return
value.
MozReview-Commit-ID: Ia6pyJN9njf
--HG--
extra : rebase_source : 73f7f1a6a8093d6f6555fa11f784bf912e1ab616
SetNeedsComposite is only ever called from one place on the compositor
thread, but it has a bunch of generic boilerplate to handle being called
from any thread. If we inline it we don't need the extra boilerplate and
it's much simpler to follow the code.
MozReview-Commit-ID: E1AcMh80KsH
--HG--
extra : rebase_source : 717fe101a3b23e30f8443110de5b6bf1a84cddda
This function is exposed as public but only ever called from two places,
both of which are inside the class. It's confusing to have it as a
separate function because it just makes it harder to trace through the
code.
MozReview-Commit-ID: BC7mvOc9wo
--HG--
extra : rebase_source : 56e2c69e158685c106e01e78e31d2df67ea6128c
Having a resume function without a corresponding pause function seems
silly. And the implementation of the function is the same as doing a
force-compose, which is what the call site is intending to do. So we can
just remove this function and do a force-compose instead.
MozReview-Commit-ID: LimMYQhAuEk
--HG--
extra : rebase_source : f10e43c4c4a6f67162b1b473de6c23d8dbdc7a8f
This function has only one call site and there's no need to make it
public.
MozReview-Commit-ID: 5o7B9KMyVqy
--HG--
extra : rebase_source : 38a915c19d48784ce086ebecd66b9f872ae03327
OpenType font collections (*.ttc) contain multiple faces in a single file,
identified via index. When creating a font descriptor for a FreeType or
Fontconfig font, we mistakenly set the index to zero, always.
This bug became visible when layout and WebRender would disagree on the face in
use, rendering text with the metrics from the proper face but the outlines of
another. Unless, of course, the selected face was the first (or only) in the
font file.
MozReview-Commit-ID: 73qcPOD0HIr
--HG--
extra : rebase_source : b5784ff547bae99186d646dbb92b31660beb3970
To avoid future issues, this is done by combining the Render and Update methods
into a single call. As a minor side-effect, timing in the parent method now
includes the time to run update.
MozReview-Commit-ID: GJ0l049eFRj
--HG--
extra : rebase_source : f9b4ee6f34bc45d87b3df40e5a25f3bfb2ec8068
We sometimes render frames for hit-testing consistency requirements but
those frames don't need compositing. This goes with webrender PR 2358.
MozReview-Commit-ID: D6DRF040D5a
--HG--
extra : rebase_source : fd5dadc35a6f6a54b385f535d4ae9c6e34f3a779
pixman-8888-over-565.patch added a call to free(), which is apparently
not included by the other headers when using the new NDK headers.
MozReview-Commit-ID: 9fAuSano36N
--HG--
extra : rebase_source : de9a1f1c4676df9ed724ae7264ca1170b77aac52
Apply Skia upstream commit 592c225b03ca677a1217eabdbc38eede6afcdb14 to
support building with NDK r16.
MozReview-Commit-ID: B6popOoPTni
--HG--
extra : rebase_source : 7d846431f9de12a2ffa270ead93c33cae602c58e
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
extra : intermediate-source : 34c999fa006bffe8705cf50c54708aa21a962e62
extra : histedit_source : b2be2c5e5d226e6c347312456a6ae339c1e634b0
GPUProcessManager::EnsureGPUReady promises that its state will be
consistent after returning. Either the GPU process is ready to be used,
or there is no GPU process at all. In the case it is attempted to
synchronously initialize the GPUChild with the device data and failed,
it broke that promise. This is because the GPU process was still setup,
but we weren't going to use it. This became a problem with the
CompositorManagerChild because it uses the process token as an
identifier, and it should have been reset to 0 in this case.
Now if GPUChild::EnsureGPUReady (the initialization step) fails, we
disable the GPU process entirely. This ensures our internal state is
consistent and the callers expectations are upheld.