Some filters can do the copy of the given data into the working buffer
as part of the filter operation. For those that cannot, we will just
copy the data first, and then advance the row.
Differential Revision: https://phabricator.services.mozilla.com/D46448
--HG--
extra : moz-landing-system : lando
Some filters can do the copy of the given data into the working buffer
as part of the filter operation. For those that cannot, we will just
copy the data first, and then advance the row.
Differential Revision: https://phabricator.services.mozilla.com/D46448
--HG--
extra : moz-landing-system : lando
Some filters can do the copy of the given data into the working buffer
as part of the filter operation. For those that cannot, we will just
copy the data first, and then advance the row.
Differential Revision: https://phabricator.services.mozilla.com/D46448
--HG--
extra : moz-landing-system : lando
Same approach as the other bug, mostly replacing automatically by removing
'using mozilla::Forward;' and then:
s/mozilla::Forward/std::forward/
s/Forward</std::forward</
The only file that required manual fixup was TestTreeTraversal.cpp, which had
a class called TestNodeForward with template parameters :)
MozReview-Commit-ID: A88qFG5AccP
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
It has been observed in profiling that the templated methods that write
pixels to an image buffer do not always inline methods properly, leading
to a high cost of writing a single pixel if it is less than trivial. As
such, there is a new SurfacePipe method, WritePixelBlocks, which
requests pixels in blocks. The provided lambda will write up to the
requested number of pixels into the given buffer. WritePixelBlocks
itself will request enough pixels to fill the row, advance the row if
complete and iterate until it is complete or we need more data.
A default constructed SurfacePipe contains a NullSurfaceSink as its
filter in mHead. This filter does nothing and is merely a placeholder.
Since most SurfacePipe objects are constructed with the default
constructor, and NullSurfaceSink has no (modified) state, we use a
singleton to represent it. Normally the SurfacePipe owns its filter, so
it needs to do a special check for NullSurfaceSink to ensure it doesn't
free it explicitly.
A Decoder object contains a default constructed SurfacePipe until it
needs to create the first frame from an image. This is a very brief
window because it does not take very long or much data to get to this
stage of decoding.
The NullSurfaceSink singleton is freed upon shutdown, however some
ISurfaceProvider objects may be lingering after this. If their Decoder
has yet to create the first frame, that means the SurfacePipe actually
contains a dangling pointer to the already freed singleton. To make
things worse, it actually tried to free the filter because it didn't
match the singleton (it got freed!).
As such, this change removes NullSurfaceSink entirely. We never use the
SurfacePipe before initializing it with a proper filter, and it would be
considered a programming error to do so. Instead let SurfacePipe::mHead
be null, and assert that it is not null when any operations are
performed on the SurfacePipe.
The patch is generated from following command:
rgrep -l unused.h|xargs sed -i -e s,mozilla/unused.h,mozilla/Unused.h,
MozReview-Commit-ID: AtLcWApZfES
--HG--
rename : mfbt/unused.h => mfbt/Unused.h
I found these issues locally by moving all of imagelib's .cpp files to SOURCES instead of UNIFIED_SOURCES. (That change isn't part of this patch, though.)
MozReview-Commit-ID: 97Xpfu8eFE6
Andrew Osmond
Oana Pop Rus
Cosmin Sabou
Sylvestre Ledru
Emilio Cobos Álvarez
Chris Peterson
Kan-Ru Chen
Daniel Holbert
Seth Fowler