Regardless of the size of an encoded image, SourceBuffer::Compact would
try to consolidate all of the chunks into a single chunk. If an image is
quite large, it can be actively harmful to do this, because we want a
very large contiguous chunk of memory for no real reason, and spend
extra time on the main thread doing the memcpy/consolidation.
Instead we now cap out the chunk size at 20MB. If we start allocating
chunks of this size, we will not perform compacting when we have
received all of the data. (Save for realloc'ing the last chunk since it
probably isn't full.)
On a related note, if we hit an out-of-memory condition in the middle of
appending data to the SourceBuffer, we would swallow the error. This is
because nsIInputStream::ReadSegments will succeed if any data was
written. This leaves the SourceBuffer out of sync. We now propogate this
error up properly to the higher levels.
fixup
Currently we only permit requests from HTTP channels to be retargeted to
the image IO thread. It was implemented this way originally in bug
867755 but it does not appear there was a specific reason for that.
The only kink in this is some browser chrome mochitests listen on debug
build only events to ensure certain chrome images are loaded and/or
drawn. As such, this patch ensures that those observer notifications
continue to be served, requiring a dispatch from the image IO thread to
the main thread.
Another issue to note is that SVGs must be processed on the main thread;
the underlying SVG document can only be accessed from it. We enforce
this by checking the content type. The possibility already exists that
an HTTP response could contain the wrong content type, and in that case,
we fail to decode the image, as there is no content sniffing support for
SVG. Thus there should be no additional risk taken by using the image IO
thread from other non-HTTP channels (if they don't specify the SVG
content type, it is not rendered today, and if they do, it will remain
on the main thread as it is today).
We also ignore data URIs. The specification requires that we process
these images sychronously. See bug 1325080 for details.
This patch enables startupRecorder.js to collect data on
loaded and shown raster and SVG images on startup via events
from native code. It also adds a test that uses this data
to find images that are unnecessarily loaded.
I've not fixed any of the affected images yet, there's a
fairly comprehensive whitelist that I want to gradually
decrease by opening bugs in the respective components.
MozReview-Commit-ID: 9KqQvKLtZhu
--HG--
extra : rebase_source : 5f75fcd1152f569a5b48e21d4e4821a24f768ecd
This patch enables startupRecorder.js to collect data on
loaded and shown raster and SVG images on startup via events
from native code. It also adds a test that uses this data
to find images that are unnecessarily loaded.
I've not fixed any of the affected images yet, there's a
fairly comprehensive whitelist that I want to gradually
decrease by opening bugs in the respective components.
MozReview-Commit-ID: 9KqQvKLtZhu
--HG--
extra : rebase_source : 856f06320c78ed88c4578fce985b2a526566e825
This patch enables startupRecorder.js to collect data on
loaded and shown raster and SVG images on startup via events
from native code. It also adds a test that uses this data
to find images that are unnecessarily loaded.
I've not fixed any of the affected images yet, there's a
fairly comprehensive whitelist that I want to gradually
decrease by opening bugs in the respective components.
MozReview-Commit-ID: 9KqQvKLtZhu
--HG--
extra : rebase_source : 345066e07855bc49975393ec401553981e1138b3
This patch enables startupRecorder.js to collect data on
loaded and shown raster and SVG images on startup via events
from native code. It also adds a test that uses this data
to find images that are unnecessarily loaded.
I've not fixed any of the affected images yet, there's a
fairly comprehensive whitelist that I want to gradually
decrease by opening bugs in the respective components.
MozReview-Commit-ID: 9KqQvKLtZhu
--HG--
extra : rebase_source : fb118db362259a1ff32488868e8238b03638f40f
(In some cases, I've left "ImageLogging.h" being included before the corresponding .h file, because I ran across a warning comment saying that it needs to be included before any IPDL-generated files & anything that includes prlog.h; and it seems possible that Foo.cpp's corresponding Foo.h file could include such headers now or in the future.)
MozReview-Commit-ID: HPvUVj8YuKc
The bulk of this commit was generated with a script, executed at the top
level of a typical source code checkout. The only non-machine-generated
part was modifying MFBT's moz.build to reflect the new naming.
CLOSED TREE makes big refactorings like this a piece of cake.
# The main substitution.
find . -name '*.cpp' -o -name '*.cc' -o -name '*.h' -o -name '*.mm' -o -name '*.idl'| \
xargs perl -p -i -e '
s/nsRefPtr\.h/RefPtr\.h/g; # handle includes
s/nsRefPtr ?</RefPtr</g; # handle declarations and variables
'
# Handle a special friend declaration in gfx/layers/AtomicRefCountedWithFinalize.h.
perl -p -i -e 's/::nsRefPtr;/::RefPtr;/' gfx/layers/AtomicRefCountedWithFinalize.h
# Handle nsRefPtr.h itself, a couple places that define constructors
# from nsRefPtr, and code generators specially. We do this here, rather
# than indiscriminantly s/nsRefPtr/RefPtr/, because that would rename
# things like nsRefPtrHashtable.
perl -p -i -e 's/nsRefPtr/RefPtr/g' \
mfbt/nsRefPtr.h \
xpcom/glue/nsCOMPtr.h \
xpcom/base/OwningNonNull.h \
ipc/ipdl/ipdl/lower.py \
ipc/ipdl/ipdl/builtin.py \
dom/bindings/Codegen.py \
python/lldbutils/lldbutils/utils.py
# In our indiscriminate substitution above, we renamed
# nsRefPtrGetterAddRefs, the class behind getter_AddRefs. Fix that up.
find . -name '*.cpp' -o -name '*.h' -o -name '*.idl' | \
xargs perl -p -i -e 's/nsRefPtrGetterAddRefs/RefPtrGetterAddRefs/g'
if [ -d .git ]; then
git mv mfbt/nsRefPtr.h mfbt/RefPtr.h
else
hg mv mfbt/nsRefPtr.h mfbt/RefPtr.h
fi
--HG--
rename : mfbt/nsRefPtr.h => mfbt/RefPtr.h
