Closed
Bug 626419
Opened 14 years ago
Closed 14 years ago
Implement/enable-tweak decompress-on-Paint feature for image lib
Categories
(Core :: Graphics: ImageLib, defect)
Tracking
()
RESOLVED
INVALID
People
(Reporter: romaxa, Unassigned)
References
Details
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...
Reporter | ||
Comment 1•14 years ago
|
||
Possibly we can enable this only for remote content at first.
Comment 2•14 years ago
|
||
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?
Reporter | ||
Comment 3•14 years ago
|
||
> 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
Comment 4•14 years ago
|
||
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!
Reporter | ||
Comment 5•14 years ago
|
||
> 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.
Reporter | ||
Comment 6•14 years ago
|
||
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
Closed: 14 years ago
Resolution: --- → INVALID
Comment 7•14 years ago
|
||
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....
Reporter | ||
Comment 8•14 years ago
|
||
> 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.
Comment 9•14 years ago
|
||
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.
Description
•