Open
Bug 854394
Opened 12 years ago
Updated 2 years ago
Tune main-thread synchronous decodes for multithreaded image decoding
Categories
(Core :: Graphics: ImageLib, defect)
Core
Graphics: ImageLib
Tracking
()
NEW
People
(Reporter: joe, Unassigned)
References
Details
(Whiteboard: [snappy])
Now that we have multithreaded image decoding, we should re-tune our content and layout classes for it. On multicore devices it won't be much of a speed win to decode synchronously on the main loop by calling StartDecoding(), and it will be an interactivity loss since we can simply dispatch the decode to one of the decoder threads.
One place that this definitely makes sense is in nsImageLoadingContent::OnStopRequest, which currently calls StartDecoding but should probably call RequestDecode. In general we might want to switch to RequestDecode everywhere except for tab switch, which we probably still want to do some synchronous main-thread decoding to avoid flashing.
Comment 1•12 years ago
|
||
> In general we might want to switch to RequestDecode everywhere except for tab switch,
> which we probably still want to do some synchronous main-thread decoding to avoid
> flashing.
I think our goal should be to avoid sync main-thread decodes on tab switch, because they're a source of jank.
Certainly we don't want to sync main-thread decode all images in a tab on switch; we only want to decode the ones which are actually visible in the tab.
I agree we also want to avoid flashing, if we can. Maybe we can have a heuristic which tries to decode the images visible in the bg tab when you put your mouse over the tab and leave it there for a brief moment. (We'd also try to leave the images in the tabs left and right of the selected one decoded.)
Anyway, all of this relies on bug 847221, so we can do it separately.
Comment 2•12 years ago
|
||
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20130325 Firefox/22.0
Build ID: 20130325105600
Steps to reproduce:
1. Create fresh profile.
2. Go to http://images.anandtech.com/doci/6857/7970_BLACK_PCB_678x452.png
3. Monitor task manager.
Actual results:
FF continously uses 1 complete core. The image is small in size, ~200KB.
Expected results:
Not so.
Something like if an image is on a very slow network, it is being continously processed or something.
This ~200KB took 22 seconds to load, using 1 full core the whole time.
Profile : http://people.mozilla.com/~bgirard/cleopatra/#report=e30419955389892340f66c0f5ba8c4441769d221
This also occured to me on 9gag, when i was using a 8KB/s internet connection.
Comment 3•12 years ago
|
||
Comment 4•12 years ago
|
||
Visit Fb.com
see cpu usage Goto 75%-100%
no matter how much decoding/rendering is done
Cpu/Gpu usage should be minimal(plus save heating & battery)
Updated•12 years ago
|
OS: Mac OS X → All
Hardware: x86 → All
Summary: Tune for multithreaded image decoding → Tune main-thread synchronous decodes for multithreaded image decoding
Comment 5•12 years ago
|
||
I wanna follow up on http://taras.glek.net/blog/2013/03/25/snappy-number-53-faster-startup/#comment-841747828 (set tabswitch to use async MT image decoding), but judging by comment #2, comment #4, this is not yet ready for prime time?
Comment 6•12 years ago
|
||
Comment 7•12 years ago
|
||
sorry
can you tell me which is the correct one
saw decodes for multithreaded image decoding
& though this one was it
Sorry once again
Comment 8•12 years ago
|
||
File a new bug and mark it blocking bug 716140, but I think you've already done that, no?
Comment 9•12 years ago
|
||
(In reply to Timothy Nikkel (:tn) from comment #8)
> File a new bug and mark it blocking bug 716140, but I think you've already
> done that, no?
umm no, I filed bug 854803
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•