When WebRender creation is failed, WebRender is disabled in gecko. There is a case that WebRenderBridgeParents exist when WebRender is disabled. To handle this, gecko needs to rebuild all CompositorSessions.
There is also a problem related to gfxVars::UseWebRender on compositor thread. If e10s is enabled, but no-gpu process(default on linux and mac), gfxVars::UseWebRender change is soon notified by compositor thread tasks. If WebRender creation failure happens at 2nd WebRender creation, several WebRenderBridgeParents for 1st WebRender could exist. IPC messages from WebRenderLayerManager are normally async, then there is a chance that the WebRenderBridgeParents receive the messages after the gfxVars::UseWebRender change. Further the gfxVars::UseWebRender change in content process could be delayed than WebRenderBridgeParents, then content process does not have a way to stop sending PWebRenderBridge IPC until the change of gfxVars::UseWebRender is received. WebRenderBridgeParent related tasks handle the message, but some tasks are done based on gfxVars::UseWebRender. At this time, gfxVars::UseWebRender returned false on compositor thread, then it cause unexpected result for WebRenderBridgeParent and WebRender. To addres this inconsistent situation, WebRenderBridgeParent related tasks on compositor thread stop to use gfxVars::UseWebRender.
Put mEffectsBounds in nsDisplyaSVGEffect does not really make sense, since only
nsDisplayFilter need it.
MozReview-Commit-ID: KSvDspZJcMP
--HG--
extra : rebase_source : 9d2f994b40e82e7146358932fbebbc60a4ca01c6
extra : source : cfd8d564c0198239eb029e4984d75a692bd9f9ca
XPIDL generated header files contain a |#if 0| block for every interface,
providing the skeleton of the class as it must be implemented in C++. This is
potentially useful, but also very verbose.
This patch removes this code. In a Linux64 debug build, this reduces the total
size of the $OBJDIR/dist/include/nsI*.h files from 11,023,499 bytes to
8,442,350 bytes, a 23.5% reduction. It didn't speed up compilation, though.
--HG--
extra : rebase_source : 65e1e46cffe7c831d83c3308d7ce58c801618dda
The lesson learned from bug 1356926 and bug 1386588 is that the version
of gcc used to build clang matters, and that we can't bind the version
we use to build clang to the version we use to build Firefox.
In some cases, we can end up linking some things with
--static-libstdc++. The notable (only?) example of that is for the
clang-plugin, and that happens because it gets some of its flags from
llvm-config, which contains --static-libstdc++ because clang itself is
built that way.
When that happens, the combination of --static-libstdc++ and
stdc++compat breaks the build because they have conflicting symbols,
which is very much by design.
There are two ways out of this:
- avoiding either -static-libstdc++ or stdc++compat
- work around the symbol conflicts
The former is not totally reliable ; we'd have to accurately determine
if we're in a potentially conflicting case, and remove one of the two in
that case, and while we can do that for the cases we explicitly know
about, that's not future-proof, and might fail just as much in the
future.
So we go with the latter. The way we do this is by defining all the
std++compat symbols weak, such that at link time, they're overridden by
any symbol with the same name. When building with -static-libstdc++,
libstdc++.a provides those symbols so the linker eliminates the weak
ones. When not building with -static-libstdc++, the linker keeps the
symbols from stdc++compat. That last assertion is validated by the
long-standing CHECK_STDCXX test that we run when linking shared
libraries and programs.
That still leaves the symbols weak in the final shared
libraries/programs, which is a change from the current setup, but
shouldn't cause problems because when using versions of libstdc++.so
that do provide those symbols, it's fine to use the libstdc++.so version
anyways.
This method can be extremely hot, so we need to remove all sources of XPCOM
overhead from it. This includes the usages of weak pointers (thanks to the
previous parts), refcounting, and QueryInterface.
I kept the callers hold the selection controller alive by assigning the
return value to an nsCOMPtr in places where the methods called on it could
have a remote chance of messing with the lifetime of objects.
