Ensure that blob: URLs will be revoked when pages are cleaned-up/destroyed (JPEG memory usage)
#10644
Conversation
Snuffleupagus
force-pushed
the
revokeObjectURL
branch
from
0465a35 to
89ae9c5
Compare
From: Bot.io (Linux m4)ReceivedCommand cmd_test from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.67.70.0:8877/0904f53f3e7d886/output.txt |
From: Bot.io (Windows)ReceivedCommand cmd_test from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.215.176.217:8877/5c788be6d454ff8/output.txt |
From: Bot.io (Linux m4)FailedFull output at http://54.67.70.0:8877/0904f53f3e7d886/output.txt Total script time: 18.47 mins
Image differences available at: http://54.67.70.0:8877/0904f53f3e7d886/reftest-analyzer.html#web=eq.log |
From: Bot.io (Windows)FailedFull output at http://54.215.176.217:8877/5c788be6d454ff8/output.txt Total script time: 28.99 mins
Image differences available at: http://54.215.176.217:8877/5c788be6d454ff8/reftest-analyzer.html#web=eq.log |
Snuffleupagus
changed the title
blob: URLs will be revoked when pages are cleaned-up/destroyedblob: URLs will be revoked when pages are cleaned-up/destroyed
Snuffleupagus
force-pushed
the
revokeObjectURL
branch
3 times, most recently
from
57c99ad to
f260539
Compare
…stroyed Natively supported JPEG images are sent as-is, using a `blob:` or possibly a `data` URL, to the main-thread for loading/decoding. However there's currently no attempt at releasing these resources, which are held alive by `blob:` URLs, which seems unfortunately given that images can be arbitrarily large. As mentioned in https://developer.mozilla.org/en-US/docs/Web/API/URL/createObjectURL the lifetime of these URLs are tied to the document, hence they are not being removed when a page is cleaned-up/destroyed (e.g. when being removed from the `PDFPageViewBuffer` in the viewer). This is easy to test with the help of `about:memory` (in Firefox), which clearly shows the number of `blob:` URLs becomming arbitrarily large *without* this patch. With this patch however the `blob:` URLs are immediately release upon clean-up as expected, and the memory consumption should thus be considerably reduced for long documents with (simple) JPEG images.
Snuffleupagus
force-pushed
the
revokeObjectURL
branch
from
f260539 to
4fd430e
Compare
Snuffleupagus
changed the title
blob: URLs will be revoked when pages are cleaned-up/destroyedblob: URLs will be revoked when pages are cleaned-up/destroyed
Snuffleupagus
force-pushed
the
revokeObjectURL
branch
from
4fd430e to
19b541f
Compare
From: Bot.io (Windows)ReceivedCommand cmd_test from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.215.176.217:8877/3c3b04fb922560c/output.txt |
From: Bot.io (Linux m4)ReceivedCommand cmd_test from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.67.70.0:8877/8e869ac1e608bed/output.txt |
From: Bot.io (Linux m4)FailedFull output at http://54.67.70.0:8877/8e869ac1e608bed/output.txt Total script time: 18.06 mins
Image differences available at: http://54.67.70.0:8877/8e869ac1e608bed/reftest-analyzer.html#web=eq.log |
From: Bot.io (Windows)FailedFull output at http://54.215.176.217:8877/3c3b04fb922560c/output.txt Total script time: 25.75 mins
Image differences available at: http://54.215.176.217:8877/3c3b04fb922560c/reftest-analyzer.html#web=eq.log |
…pported JPEG images, when pages are cleaned-up/destroyed This will further help reduce the amount of image data that's currently being held alive, by explicitly removing the `src` attribute. Please note that this is mostly relevant for browsers which do not support `URL.createObjectURL`, or where `disableCreateObjectURL` was manually set by the user, since `blob:` URLs will be revoked (see the previous patch). However, using `about:memory` (in Firefox) it does seem that this may also be generally helpful, given that calling `URL.revokeObjectURL` won't invalidate the image data itself (as far as I can tell).
Snuffleupagus
force-pushed
the
revokeObjectURL
branch
from
19b541f to
88d5750
Compare
Snuffleupagus
changed the title
blob: URLs will be revoked when pages are cleaned-up/destroyedblob: URLs will be revoked when pages are cleaned-up/destroyed (JPEG memory usage)
|
This is a really nice find; thanks! |
|
/botio makeref (to fix reference test failures) |
From: Bot.io (Linux m4)ReceivedCommand cmd_makeref from @timvandermeij received. Current queue size: 0 Live output at: http://54.67.70.0:8877/6d7037e0915eed9/output.txt |
From: Bot.io (Windows)ReceivedCommand cmd_makeref from @timvandermeij received. Current queue size: 1 Live output at: http://54.215.176.217:8877/0e8d70af0d295aa/output.txt |
From: Bot.io (Linux m4)SuccessFull output at http://54.67.70.0:8877/6d7037e0915eed9/output.txt Total script time: 16.53 mins
|
From: Bot.io (Windows)SuccessFull output at http://54.215.176.217:8877/0e8d70af0d295aa/output.txt Total script time: 23.22 mins
|
Ensure that
blob:URLs will be revoked when pages are cleaned-up/destroyedNatively supported JPEG images are sent as-is, using a
blob:or possibly adataURL, to the main-thread for loading/decoding.However there's currently no attempt at releasing these resources, which are held alive by
blob:URLs, which seems unfortunately given that images can be arbitrarily large.As mentioned in https://developer.mozilla.org/en-US/docs/Web/API/URL/createObjectURL the lifetime of these URLs are tied to the document, hence they are not being removed when a page is cleaned-up/destroyed (e.g. when being removed from the
PDFPageViewBufferin the viewer).This is easy to test with the help of
about:memory(in Firefox), which clearly shows the number ofblob:URLs becomming arbitrarily large without this patch. With this patch however theblob:URLs are immediately release upon clean-up as expected, and the memory consumption should thus be considerably reduced for long documents with (simple) JPEG images.Remove the
srcattribute fromImageobjects used with natively supported JPEG images, when pages are cleaned-up/destroyedThis will further help reduce the amount of image data that's currently being held alive, by explicitly removing the
srcattribute.Please note that this is mostly relevant for browsers which do not support
URL.createObjectURL, or wheredisableCreateObjectURLwas manually set by the user, sinceblob:URLs will be revoked (see the previous patch).However, using
about:memory(in Firefox) it does seem that this may also be generally helpful, given that callingURL.revokeObjectURLwon't invalidate the image data itself (as far as I can tell).