Previously our region code was just a simple y,x sorted list of
non-intersecting rectangles. This can cause us to have simple regions
represented in a complex unoptimizable way.
Switching to pixman regions gives us a canonical region implementation.
There are some cases when this can cause performance regressions.
For example, with the old region code we end up with this region:
http://people.mozilla.org/~jmuizelaar/region-pre.html
which is represented like this:
http://people.mozilla.org/~jmuizelaar/region-post.html
with the new code.
We call SimplifyOutward(4) on this. With old regions we can't simplify it so we
end up taking the bounds and get 1 rect. With the new regions we have only 3
rects to start and so we do nothing. The difference between 3 rects and 1 rect
cause D2D to do a PushLayer() instead of a ClipRect() and that seems to be the
causes for the regression.
--HG--
extra : rebase_source : 65e0d29d67b51a3780448eaecfde33dbcb6b99b1
The BufferedAudioStream buffers the data it gets through the Write() calls and
what is consumed by the callback. This means that if the audio producer starts
Write()ing data right after Start()ing the stream, data will accumulate in this
buffer and won't be consumed. Eventually, the buffer will be of a certain size
before it begins to be consumed by the callback, and this means an
umcompressible latency (because the data will be written at more or less the
same rate as it is produced).
This patch start the BufferedAudioStream right away when it is created, dropping
the silent AudioSegment until it finds real data (and padding with silence is
then done at the beginning). The stream will underrun, but the callback will
synthetize silence, avoiding overbuffering in the BufferedAudioStream. This
ensures minimal latency cause by the buffering.
Note that the clock will still advance, so this will not change the behavior of
content that has leading silence.
What LIBXUL_LIBRARY does is:
- Imply FORCE_STATIC_LIB
- Build with -DIMPL_LIBXUL
- Build with -DMOZILLA_INTERNAL_API
Those intermediate libs that end up in gkmedias and have LIBXUL_LIBRARY defined
in their moz.build are all third party code (or handled like third party code).
Besides FORCE_STATIC_LIB, none of the side effects of LIBXUL_LIBRARY should be
needed.
This also moves the LIBXUL_LIBRARY implies FORCE_STATIC_LIB test in the emitter
instead of config.mk, since both variables are defined in moz.build exclusively.
backend.mk can end up with both LIBXUL_LIBRARY and FORCE_STATIC_LIB defined, but
it's just fine.
