854394 - Tune main-thread synchronous decodes for multithreaded image decoding

Status: NEW

(Core :: Graphics: ImageLib, defect)

Description

[Joe Drew (not getting mail)]

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

[Justin Lebar (not reading bugmail)]

> 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

[Willy_ Foo_Foo]

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

[Willy_ Foo_Foo]

Filed a bug 
https://bugzilla.mozilla.org/show_bug.cgi?id=854803

Comment 4

[Willy_ Foo_Foo]

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)

Comment 5

[Avi Halachmi (:avih)]

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

[Timothy Nikkel (:tnikkel)]

comment 2 and comment 4 do not belong in this bug, they are about a regression from multi-threaded image decoding in general, not specific to the issue of this bug.

Comment 7

[Willy_ Foo_Foo]

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

[Timothy Nikkel (:tnikkel)]

File a new bug and mark it blocking bug 716140, but I think you've already done that, no?

Comment 9

[Mayank Bansal]

(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