OS_LIBS for libraries that are not part of the gecko tree, EXTRA_LIBS for
libraries, such as NSPR, that are in the tree, but are not handled by
moz.build just yet. Those EXTRA_LIBS may also come from a system library.
However, in cases where the expanded variables are always empty for the
in-tree case, OS_LIBS is used (as for, e.g. MOZ_ZLIB_LIBS). OS_LDFLAGS is
used exclusively for non-library linker flags.
Always pass EXTRA_LIBS before OS_LIBS on linker command lines.
Forbid EXTRA_DSO_LDOPTS, SHARED_LIBRARY_LIBS and LIBS in Makefiles.
This patch changes the order in which we look for matches when updating existing
animations. Previously we would iterate through new animations in a forwards
direction but match old animations by going through the list of animations
backwards.
This patch makes us iterate through both lists in a backwards direction. That
means that if we have:
animation: anim 100s
and later we make it
animation: anim 100s, anim 100s
Then the new animation will be added to the *start* of the list, i.e. prepended,
and the resulting animation will not restart.
Previously when updating animations we'd generate a new list of animation
objects then try to match up animations from the existing list and copy across
state such as start times and notification flags. However, this means that from
the API we end up returning different objects.
This patch makes us maintain the same object identity when updating an existing
animation. It does this by looking for matching animations in both lists. If it
finds a match it copies the necessary information from the *new* animation to
the *existing* animation (but preserving the start time, last notification
etc.). Then, finally, it puts the *existing* animation in the list of *new*
animations and removes the corresponding *new* animation. The existing
animation is also removed from the list of existing animations so that it only
matches once.
The method used for matching is probably not intuitive but this is addressed in
a subsequent patch in this series.
With image offscreen surfaces enabled for content layers on GTK3, our Basic
compositor needs a way to deal with image layers buffering and compositing in
a performant way. This patch subclasses BasicCompositor into a new
X11BasicCompositor and makes use of a new TextureSource
(X11DataTextureSourceBasic) in order to buffer TextureHost's data into
gfxXlibSurface on compositor side so that we can use XRender when available to
composite layer contents directly to the Window.
When this buffering will occur, switch to ContentClientSingleBuffered.
--HG--
extra : rebase_source : adad6b1c05dcf516a1ea84c6a529df5f141c198f
This patch adds a new pref called "layers.use-image-offscreen-surfaces"
that makes GTK3 platform create gfxImageSurfaces for content layers
instead of gfxXlibSurfaces.
--HG--
extra : rebase_source : b803a453bafc70226f3d4c65684618f154147fdb
The delay in the third test is reduced to ensure that some of the output
signal has traversed every link in the cycle.
The input signal no longer loops for un-muted cycles, to keep it simple.
--HG--
extra : rebase_source : 37f555c356cc2c0573e7c93150ed86587da30ad7
