Bug 1363216 - Turn off std::future for MinGW.
Bug 1331335 - Add SSE2 Flags to all of libANGLE.
Bug 1364169 - on ANGLE context creation asks for robustness but does not get it.
Bug 1370865 - Suppress more MSVC warnings in gfx/angle.
Bug 1373525 - gfx/angle: Suppress -Wimplicit-fallthrough warnings in third-party code.
Bug 1347866 - Part3: ANGLE patch uplift for bug1325733.
Bug 1347866 - Part4: ANGLE patch uplift for bug1325741.
Bug 1322746 - Add general ID3D11Texture2D to EGLStream support to ANGLE.
Bug 1366425 - Avoid losing context on out of memory error for ANGLE.
--HG--
extra : source : 9aa8f8c7fe616638dd496bdf771d158586732056
The method isn't called and the comments referring to it are no longer applicable.
MozReview-Commit-ID: 2FFWhj7wzht
--HG--
extra : rebase_source : 9bc3e9288ce0f38f03a9d33acc902f11703536da
For now, convert 10/12 bits YUV image to 8 bits. Native support will be tracked in bug 1379948
MozReview-Commit-ID: LOr9X5xxKY7
--HG--
extra : rebase_source : 90b39f46cbc9d5233965e3693c620466557eb8e7
There's no guarantee that the stride of the uv planes is twice as wide as the y plane's stride. This relationship is only true between the planes' width.
MozReview-Commit-ID: JInge1c86Z1
--HG--
extra : rebase_source : 0e9cf5be06812712d50a42db7630f396d0020791
We have too many layers-free things in WebRenderLayerManager. I create a new
class WebRenderCommandsBuilder and move some functions and variables from
WebRenderLayerManager to WebRenderCommandsBuilder.
MozReview-Commit-ID: BJi1E51W7ax
--HG--
extra : rebase_source : ddbfb044d467430403a3c480030ef9dec803c9f7
This is basically just this: https://bugs.chromium.org/p/chromium/issues/detail?id=562951
The original profile that caused us to add this check has bigger problems than negative
colorant tristiumlus values. We should reject it using a better metric. In the mean time
let's not reject these things on macOS.
- A user gesture is required only for the VRDisplay.requestPresent
call that initiates the VR presentation, as per the WebVR 1.1 spec.
- The parameters of the VRLayer can now be updated by calling
VRDisplay.requestPresent on an active VR presentation.
- Dynamic resolution switching is now functional:
https://webvr.info/samples/08-dynamic-resolution.html
iMozReview-Commit-ID: BL7aJfF6nqR
MozReview-Commit-ID: CmhbFJ4ij5q
--HG--
extra : rebase_source : 28a3f608b4f821631e81ccdfe7f7824f9508a7b4
We currently allow the content process to shutdown the IPDL objects on
behalf the parent, and we wait for all of these instances to be freed
before we complete shutdown. This is undesirable because it requires the
parent to trust the child rather than the other way around; the child
can hold shutdown hostage by simply not releasing its instances. The
child should already support the parent closing its graphics IPDL
objects because the GPU process itself can die abruptly and be restored
at a later time.
This patch:
- adds fails-if annotations for all the reftests that were consistently failing
with layers-free turned on.
- removes fails-if or reduces the range on fuzzy-if annotations for all
the reftests that were producing UNEXPECTED-PASS results with
layers-free turned on.
- adds skip-if, random-if, or fuzzy-if annotations to the reftests that
were intermittently failing due to timeout, obvious incorrectness, or
slight pixel differences, respectively.
MozReview-Commit-ID: A0Aknn6rnjj
--HG--
extra : rebase_source : 420d9cf43f23a5d654fa36eec69138937d13c173
Windows detection was broken for the MinGW build. This pulls
in the upstream patch from
https://bugs.chromium.org/p/skia/issues/detail?id=6635
MozReview-Commit-ID: D0ZRIDaPmim
--HG--
extra : rebase_source : d20b6bd4bb1b2a93996775d36fe1c8484d0b0f85
The assembly code is not working in the MinGW build, so we
rebase and pull in the upstream commit that adds support for
not using the optimized jumper assembly code.
https://skia.googlesource.com/skia/+/6492afa7971cf295a3c3cb92a85218917c02bb4a
MozReview-Commit-ID: CARHRTHmQ0i
--HG--
extra : rebase_source : c6d9f19f8742a337e6ab3342d34118f37da71ae7
- Using a separate ID3DDeviceContextState ensures
that the WebVR context does not stomp over the
mirrored state used by the MLGPU "Advanced" Layers rendering.
MozReview-Commit-ID: 99mfdsjFrMI
--HG--
extra : rebase_source : 599df3b1344ca1489cbb13169313dff8e767c399
This patch merges nsAtom into nsIAtom. For the moment, both names can be used
interchangeably due to a typedef. The patch also devirtualizes nsIAtom, by
making it not inherit from nsISupports, removing NS_DECL_NSIATOM, and dropping
the use of NS_IMETHOD_. It also removes nsIAtom's IIDs.
These changes trigger knock-on changes throughout the codebase, changing the
types of lots of things as follows.
- nsCOMPtr<nsIAtom> --> RefPtr<nsIAtom>
- nsCOMArray<nsIAtom> --> nsTArray<RefPtr<nsIAtom>>
- Count() --> Length()
- ObjectAt() --> ElementAt()
- AppendObject() --> AppendElement()
- RemoveObjectAt() --> RemoveElementAt()
- ns*Hashtable<nsISupportsHashKey, ...> -->
ns*Hashtable<nsRefPtrHashKey<nsIAtom>, ...>
- nsInterfaceHashtable<T, nsIAtom> --> nsRefPtrHashtable<T, nsIAtom>
- This requires adding a Get() method to nsRefPtrHashtable that it lacks but
nsInterfaceHashtable has.
- nsCOMPtr<nsIMutableArray> --> nsTArray<RefPtr<nsIAtom>>
- nsArrayBase::Create() --> nsTArray()
- GetLength() --> Length()
- do_QueryElementAt() --> operator[]
The patch also has some changes to Rust code that manipulates nsIAtom.
MozReview-Commit-ID: DykOl8aEnUJ
--HG--
extra : rebase_source : 254404e318e94b4c93ec8d4081ff0f0fda8aa7d1
For DXGIYCbCrTextureHostD3D11, gecko use 3 separated d3d11 A8 textures
to represent the Y, Cb and Cr data. This patch try to use EGL stream to
convert the d3d11 texture to gl handle. Then, WR could use the converted
gl handle to show the video data without buffer copy operation.
MozReview-Commit-ID: C9w9rzufTOj
Create a new type RenderDXGIYCbCrTextureHostOGL for planar-ycbcr format in WR.
That type could convert the 3 d3d11-a8 textures into gl handles. Then, WR could
draw the gl handles directly.
MozReview-Commit-ID: 1CIQO4p8u30
Instead of always discarding the compositor animation id, and then
sometimes un-discarding it (which involves a linear lookup in nsTArray),
this patch now has the WebRenderLayerManager keep a set of active
animation ids, and uses that to avoid discarding the same animation
twice.
In addition, because the display item can be destroyed at any time (e.g.
in the middle of an animation), we were previously "leaking" compositor
animations in that the compositor side never got notified to discard the
IDs. This resulted in infinite composition loops. This patch solves this
problem by having any unused WebRenderAnimationData trigger discard of
the animation id during destruction. This way, even if the nsDisplayItem
is deleted in the middle of the animation we have a fallback mechanism
to discard the id.
MozReview-Commit-ID: 8G3EYHcg9Kl
--HG--
extra : rebase_source : 45e99a0d71a76a15b7fc7a0d498a6149501a722d
XPCOM's string API doesn't have the notion of a "null string". But it does have
the notion of a "void string" (or "voided string"), and that's what these
functions are returning. So the names should reflect that.
--HG--
extra : rebase_source : 4e3f982e0873877174a08a25413595ff66f7d20e
For layers-full mode, we set the backface-visibility to visible because
visibility would be handled by FLB and layers.
MozReview-Commit-ID: CUbeUabfC7K
If the compositor animations are still valid, we don't need to add its id to the discarded list.
This patch also reduces unnecessary SendDeleteCompositorAnimations calls.
MozReview-Commit-ID: AcbVUk3MUo7
--HG--
extra : rebase_source : fa8b1e5b4c9d3e81826eef621926975c967985a0
Currently if SourceSurfaceVolatileData::Map fails due to being purged,
we expect that the surface will be discarded by the caller. This has not
consistently been the case, and as such, we should ensure we do not
forget if a buffer was previously purged when we reacquire it. Since we
do not at this time support repopulating an already allocated buffer
with new data, we cannot reset this state once it has been set.
Currently if SourceSurfaceVolatileData::Map fails due to being purged,
we expect that the surface will be discarded by the caller. This has not
consistently been the case, and as such, we should ensure we do not
forget if a buffer was previously purged when we reacquire it. Since we
do not at this time support repopulating an already allocated buffer
with new data, we cannot reset this state once it has been set.
* The -Wno-unused-but-set-variable flag is supported by gcc but not clang, so move it to a gcc-only CFLAGS.
* The -Wno-error=uninitialized flag is supported by both gcc and clang, so move it to CFLAGS shared by gcc and clang.
* Also suppress -Wunreachable-code and -Wshift-negative-value clang warnings. gcc supports -Wshift-negative-value, but only starting in gcc 6.1 and we are still using gcc 4.9 in automation.
warning: unknown warning option '-Wno-unused-but-set-variable'; did you mean '-Wno-unused-const-variable'? [-Wunknown-warning-option]
gfx/cairo/cairo/src/cairo-quartz-surface.c:1908:6: warning: code will never be executed [-Wunreachable-code]
gfx/cairo/libpixman/src/pixman-bits-image.c:268:32: warning: shifting a negative signed value is undefined [-Wshift-negative-value]
MozReview-Commit-ID: AnQAsfDaZbk
--HG--
extra : rebase_source : 6dd94a39479e05f67f93d4e4be2bd10ece4df7be
extra : source : 34ddaea5129be2ae1e9faa0a1d905b8690909611
DEFFILE is currently just used as a passthrough variable. All but one of
the current uses of it use `SRCDIR + '/file.def'` to get a srcdir-relative
path anyway, and the other one wants an objdir-relative path, so using
Path makes everything clearer.
This makes it more straightforward to translate the paths for the WSL
build.
MozReview-Commit-ID: IRokABaZW2c
--HG--
extra : rebase_source : ae74c984bb2aab70211dc5974a8b052651e025dd
There have been reports of images remaining in the surface cache but no
longer containing the previously decoded data. Instead these appear as
transparent (BGRA) or black (BGRX). This suggests that somehow the image
surface buffer was reset to all zeroes. Additionally this seems to be
correlated with suspend and resume.
One possibility is that the OS purged our volatile buffers on suspend.
This is because we are supposed to be able to regenerate the contents
anyways, so it could choose to not preserve the data on suspend. In
general we should recover from this however and clearly we are not.
This patch adds a diagnostic assert to ensure that a buffer which was
previously purged is not reused later, as we should be discarding said
buffers.
From the crashes associated with bug 1389021, we know that some
compositor thread IPDL owners are not being cleaned up properly. We do
not know which protocols are causing the problem, so we temporarily will
annotate the logs with the ownership status. This should be limited to
under a dozen instances of the protocols.
This change will be backed out after a few builds are produced with it
and we see the first crash reports with the relevant data.
The pref is enabled by default, but it allows the feature to be disabled
easily if necessary.
MozReview-Commit-ID: Iu1JmMKEQv9
--HG--
extra : rebase_source : 57c27ef5840d4932e28cda2eb2f6e921ccd11a71
WMFDecoderModule should only focus on whether the mime type is supported or not.
Let WMFVideoMFTManager do the checking.
MozReview-Commit-ID: K6jPfrntu7s
--HG--
extra : rebase_source : f6ba055824c3a7ebac85666e3201fd6b79e8d815
WMFDecoderModule should only focus on whether the mime type is supported or not.
Let WMFVideoMFTManager do the checking.
MozReview-Commit-ID: K6jPfrntu7s
--HG--
extra : rebase_source : f6ba055824c3a7ebac85666e3201fd6b79e8d815
Unlike regular content, scrollbar thumbs use a different mechanism for
triggering their 'active' style, and no one will clear this flag if
ActiveElementManager sets it.
MozReview-Commit-ID: AfloVYRkvQA
--HG--
extra : rebase_source : e89fe4eefe615d3f65d2471ff59aa9d51d9ae5e2
The general implementation strategy is to detect whether a touch
block is a scrollbar drag, and if so, convert the touch events
to mouse events before sending them to InputQueue. This is done
so that code for handling mouse-drags in InputQueue and APZC
can be re-used.
Content will receive the original touch events, not the synthesized
mouse events. This is done for two reasons:
1) We don't really have a mechanism for APZ to send content
synthesized events.
2) Content already deals with touch events that drag a scroll
thumb correctly.
MozReview-Commit-ID: 7cksE5FMGoS
--HG--
extra : rebase_source : 2e1420a9ae2b9b16c54b89a9cafa0aa9926434b2
Expose the API to get/set inherited scale from stacking context and we can
use these APIs to calculate correct scale for OMTA
MozReview-Commit-ID: DZEkodHTy8v
--HG--
extra : rebase_source : be3c978c8f48c9b1bfcd01cff6bb8200092b5e60
Ensure the UiCompositorControllerChild is shutdown in the UI thread
before the compositor thread is shutdown by the main thread.
MozReview-Commit-ID: 4hXYxSi9tzz
--HG--
extra : rebase_source : fd265b39986f453ea9ab59c60bb80319b74e8f9c
In layers-free mode the gecko display list and coordinate system is very
similar to what WR is expecting. Instead of having each
StackingContextHelper shift the origin of the coordinate system, we can
leave it in one spot and just pass everything relative to that. The
semantics of the Gecko display list already matches this; the exception
is that nsDisplayTransform items are also considered reference frames,
and anything inside them is relative to the nsDisplayTransform. On the
WR side this is also the case, because stacking contexts with a
transform are implicitly turned into reference frames.
Additionally, the size of the bounds passed to the WR stacking context
is never actually used, except on the root stacking context (which is
not created by StackingContextHelper). Since we want a zero origin (as
explained above) and the size is never used, we can just pass a zero
rect to the WR stacking context from StackingContextHelper.
In terms of the actual transform matrix, this patch now passes the full
unmodified transform from nsDisplayTransform into WR. This transform
gets applied onto the contents of the nsDisplayTransform. The contents'
coordinate system is relative to the frame that generated the
nsDisplayTransform. Again this maps directly to WR, where the transform
on the stacking context gets applied to the contents of the stacking
context; the contents' coordinates are relative to the stacking context.
MozReview-Commit-ID: 9hdDxdKXPPi
--HG--
extra : rebase_source : b201cea867c6c6e26c2b0bcd0e38c8722f09fe77
This backs out bug 1399050, bug 1394308 (2 patches), and bug 1391499. I
believe these patches sent us down a path that would make the code
increasingly more complex, when in fact we can do a more "direct"
translation from the gecko display list to the WR display list and make
things a lot simpler and more correct.
MozReview-Commit-ID: ZXXkI9DXiY
--HG--
extra : rebase_source : 47ce1fcb87f0c21d158ee06f38e2b3303f999270
Mostly just threading the TextDrawTarget deeper into the code to use a boolean.
A lot of places are trying to optimize away invisible text!
MozReview-Commit-ID: 89sDAwUv0HA
--HG--
extra : rebase_source : 8d800702232aec6626a33f2d6be893708d0bbfee
This introduces the infrastructure to specify the bounds of drawing commands being executed. These bounds can then be used to limit operations done for blending in order to reduce required fillrate. Currently we only specify the bounds for DrawSurface but it would be easy to extend this for other drawing commands if so desired.
MozReview-Commit-ID: BUFJzphfdKc
--HG--
extra : rebase_source : cbd17803d8aeb1a74b6c7c98fd5c00e06870805b
The optimization avoided a 10ms delay in generating synthesized mouse events
after a touch tap, if the tapped element wasn't styled differently when in
the |:active| state.
This dates back to the B2G days when the delay was in the critical path of
app startup times. It's less important today, and determining whether the
element is styled differently is an expensive operation in the style engine,
so we are removing it.
MozReview-Commit-ID: FYO1GlCR3gS
--HG--
extra : rebase_source : 1b7ce6eec77d0260b153bfcd93e81bccb3558107