Closed Bug 689411 Opened 14 years ago Closed 14 years ago

When re-decoding images on a tab, we should decode images currently in the viewport first

Categories

(Core :: Graphics: ImageLib, defect)

Product:
Core
Component:
Graphics: ImageLib
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 715308

People

(Reporter: ehsan.akhgari, Unassigned)

References

(Blocks 1 open bug,
URL
)

Details

(Keywords: regression)

STR: 1. Go to the URL. 2. Open a new tab. 3. Wait for 10 or so seconds and then close the tab. Watch the images on the page being redrawn one by one. This looks *very* bad.
This looks no worse than any of the other image-heavy sites I've looked at, like the Atlantic's In Focus blog. We suck at re-decoding discarded images. Provably anything would get more images up faster than our current scheme, which is to decode all images in parallel.
It looks particularly bad because the slides are small. But they're actually large and sized down by the browser.
(In reply to Justin Lebar [:jlebar] from comment #2) > It looks particularly bad because the slides are small. But they're > actually large and sized down by the browser. Yeah, that's a recipe for bad things.
I tested Chrome, Safari and Chrome, and they all do a better job than what we do here.
Ehsan, do you mind if I morph this bug into When re-decoding images on a tab, we should decode images currently in the viewport first. ?
Depends on: 689623
Summary: Image discarding shows up really badly on brendaneich.com → When re-decoding images on a tab, we should decode images currently in the viewport first
What I'd like to see happen is for all the caching stuff to just disappear and for it to decode each and every time an image enters the visible area. I wonder where the real bottlenecks are.
(In reply to Justin Lebar [:jlebar] from comment #5) > Ehsan, do you mind if I morph this bug into > > When re-decoding images on a tab, we should decode images currently in the > viewport first. > > ? Please be my guest. :-)
Component currently reads "Graphics". Should it be "Imagelib"?
(In reply to Robert Claypool from comment #8) > Component currently reads "Graphics". Should it be "Imagelib"? Thanks.
Component: Graphics → ImageLib
QA Contact: thebes → imagelib
Robert, doing what you propose leads to really crappy behavior when scrolling. Keep in mind that on modern desktop hardware decode times for a large jpeg are measured in hundreds of milliseconds to seconds. On mobile things are even worse.
How large is large?
Typical photos from a modern digital camera will do it, last I checked.
What about some sort of intermediate compressed form the resolution of the displayed image so you can keep a whole page of them in memory?
Blocks: 702579
This bug is awfully similar to bug 542158. If anything, that bug is more general, because this one is about re-decoding images. Ehsan, are you happy to dup this to bug 542158?
Actually, this is an exact dupe of bug 715308.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
(In reply to Justin Lebar [:jlebar] from comment #15) > Actually, this is an exact dupe of bug 715308. That is true, sir!
If this is a dupe of bug 715308, shouldn't "Depends on: 689623 Blocks: image-suck" be carried over to bug 715308, then?
Bug 715308 should block image-suck, but the dependency here is false. That's the discovery which led to the patch in bug 715308.
You need to log in before you can comment on or make changes to this bug.