I found that most of mobile browser do image decompression only when image is visible on screen, that make pages loading faster and browser initial memory usage smaller. I was hoping that this feature will be implemented in bug 435296, but that fix is landed and this feature still not available... pref("image.mem.discardable", false); pref("image.mem.decodeondraw", false); Here is the some backtraces: https://bugzilla.mozilla.org/attachment.cgi?id=500813 https://bug622470.bugzilla.mozilla.org/attachment.cgi?id=500820 Without this feature Fennec page loading will be generally slow and memory greedy, on news pages, facebooks, livejournals, porn pages...
Possibly we can enable this only for remote content at first.
See bug 573583 and bug 622470 (which you have, I know). The prefs in comment 0 disable discarding and decode-on-draw. Don't you want to set those to true?
> The prefs in comment 0 disable discarding and decode-on-draw. Don't you want > to set those to true? My goal is to not decompress any images which are not visible on screen (in fennec), and first step is disable discarding, because in that case StoringSourceData will return false and we enter into // If we're not storing source data, write it directly to the decoder http://mxr.mozilla.org/mozilla-central/source/modules/libpr0n/src/RasterImage.cpp#1229
But the point is that you _don't_ want to write directly into the decoder, do you? The decoder is going to decompress the data. That's its job!
> you? The decoder is going to decompress the data. That's its job! hmm, you probably right... then I need to make sure that mDecoder is null for downloaded image and mWorker->Run(); not started.
Ok, seems pref("image.mem.decodeondraw", true); + disable nsDocument lock/unlock code making image decompression only on paint... So imagelib code is working perfect for that
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → INVALID
Perhaps we need a pref for the document lock/unlock behavior (which is there to just pin the images in the currently visible tab so they don't get discarded)? That said, why is that locking affecting decode-on-draw? It shouldn't....
> That said, why is that locking affecting decode-on-draw? It shouldn't.... because with locking, all images force decoded when tab activated.. and not on draw... http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsDocument.cpp#8176 also mLockingImages enabled by default for new document, and all images decoded on first loading.
Hmm. I wonder why we force decoding before draw for active documents... > also mLockingImages enabled by default for new document Only if it's active, no? If not, that's a bug...
You need to log in before you can comment on or make changes to this bug.