If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Tune main-thread synchronous decodes for multithreaded image decoding

NEW
Unassigned

Status

()

Core
ImageLib
5 years ago
4 years ago

People

(Reporter: Joe Drew (not getting mail), Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [snappy])

(Reporter)

Description

5 years ago
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.
> 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

5 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

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

Comment 4

5 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)
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

5 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 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

5 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
File a new bug and mark it blocking bug 716140, but I think you've already done that, no?

Comment 9

5 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
You need to log in before you can comment on or make changes to this bug.