New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Placeholders #260

Open
yoavweiss opened this Issue Mar 11, 2015 · 6 comments

Comments

Projects
None yet
3 participants
@yoavweiss
Member

yoavweiss commented Mar 11, 2015

In http://ircbot.responsiveimages.org/bot/log/respimg/2015-03-05#T117041 we discussed adding some way for browsers to load a poor-quality image first, trigger onload, and then lazy-load a higher-res resource.

A similar concept is also being discussed in https://code.google.com/p/chromium/issues/detail?id=464849

I'm not yet sure what's the best form of that should be (opt-in/out, trigger onload for intermediate image, hold window.onload for high-res image, etc), but I think we should further discuss it.

@eeeps

This comment has been minimized.

Show comment
Hide comment
@eeeps

eeeps Mar 11, 2015

(Am I supposed to get a 403 Forbidden at the Chromium issue link?)

Why not just use JavaScript for this, like, say, NPR does now? The big reason I see: you don’t get to leverage the browser’s srcset picking logic for the upgrade, which is potentially much more intelligent/informed and almost certainly far more reliable than whatever you’re rolling on your own. If enough people want to do this, having a consistent, native way to do it seems appropriate.

I’ll hopefully note (while fully acknowledging that this is a sort-of-separate and certainly-more-complicated thing) that this seems like a perfect use-case for some kind of diff-based layering. I’ve been fiddling with Laplacian pyramids recently.

eeeps commented Mar 11, 2015

(Am I supposed to get a 403 Forbidden at the Chromium issue link?)

Why not just use JavaScript for this, like, say, NPR does now? The big reason I see: you don’t get to leverage the browser’s srcset picking logic for the upgrade, which is potentially much more intelligent/informed and almost certainly far more reliable than whatever you’re rolling on your own. If enough people want to do this, having a consistent, native way to do it seems appropriate.

I’ll hopefully note (while fully acknowledging that this is a sort-of-separate and certainly-more-complicated thing) that this seems like a perfect use-case for some kind of diff-based layering. I’ve been fiddling with Laplacian pyramids recently.

@yoavweiss

This comment has been minimized.

Show comment
Hide comment
@yoavweiss

yoavweiss Mar 11, 2015

Member

(Am I supposed to get a 403 Forbidden at the Chromium issue link?)

No you're not. I hope it'd get open to the public soon. (No idea why it was closed to begin with, but no permissions to open it myself)

Member

yoavweiss commented Mar 11, 2015

(Am I supposed to get a 403 Forbidden at the Chromium issue link?)

No you're not. I hope it'd get open to the public soon. (No idea why it was closed to begin with, but no permissions to open it myself)

@yoavweiss

This comment has been minimized.

Show comment
Hide comment
@yoavweiss

yoavweiss Mar 11, 2015

Member

Why not just use JavaScript for this, like, say, NPR does now? The big reason I see: you don’t get to leverage the browser’s srcset picking logic for the upgrade, which is potentially much more intelligent/informed and almost certainly far more reliable than whatever you’re rolling on your own. If enough people want to do this, having a consistent, native way to do it seems appropriate.

A ton of people are using JS for that. What we (ideally) want is for the browser to use its srcset info in order to lower a low-res placeholder (the 0.1x image, if you will) instead.

Again, not sure what the specifics should be, but I think we should discuss it.

I’ll hopefully note (while fully acknowledging that this is a sort-of-separate and certainly-more-complicated thing) that this seems like a perfect use-case for some kind of diff-based layering. I’ve been fiddling with Laplacian pyramids recently.

Yup. (to both it being perfect and more complicated :D )

Member

yoavweiss commented Mar 11, 2015

Why not just use JavaScript for this, like, say, NPR does now? The big reason I see: you don’t get to leverage the browser’s srcset picking logic for the upgrade, which is potentially much more intelligent/informed and almost certainly far more reliable than whatever you’re rolling on your own. If enough people want to do this, having a consistent, native way to do it seems appropriate.

A ton of people are using JS for that. What we (ideally) want is for the browser to use its srcset info in order to lower a low-res placeholder (the 0.1x image, if you will) instead.

Again, not sure what the specifics should be, but I think we should discuss it.

I’ll hopefully note (while fully acknowledging that this is a sort-of-separate and certainly-more-complicated thing) that this seems like a perfect use-case for some kind of diff-based layering. I’ve been fiddling with Laplacian pyramids recently.

Yup. (to both it being perfect and more complicated :D )

@tabatkins

This comment has been minimized.

Show comment
Hide comment
@tabatkins

tabatkins Mar 13, 2015

I agree with this use-case, and think we should address it. Summarized, it's:

Provide a hint to the resource choosing algorithm that it should optimize for download speed rather than quality, choosing sources that are 1x or lower just to get something on the page. This then triggers asynchronous loading of the "normal" high-quality choice; whenever the resource pipeline isn't so contentious, it can go and fetch prettier versions of the image.

This needs to be an opt-in rather than an automatic behavior from the browser because some use-cases do want the high-quality image immediately; if you're going to draw it into a <canvas>, for example, you want the onload event to tell you when the "proper" resource is loaded, not the shitty .1x version.

tabatkins commented Mar 13, 2015

I agree with this use-case, and think we should address it. Summarized, it's:

Provide a hint to the resource choosing algorithm that it should optimize for download speed rather than quality, choosing sources that are 1x or lower just to get something on the page. This then triggers asynchronous loading of the "normal" high-quality choice; whenever the resource pipeline isn't so contentious, it can go and fetch prettier versions of the image.

This needs to be an opt-in rather than an automatic behavior from the browser because some use-cases do want the high-quality image immediately; if you're going to draw it into a <canvas>, for example, you want the onload event to tell you when the "proper" resource is loaded, not the shitty .1x version.

@eeeps

This comment has been minimized.

Show comment
Hide comment
@eeeps

eeeps Mar 13, 2015

Do we need to wait for (or instigate) resource priorities work to start working on this?

This would pair nicely with the measuring-sizes-directly functionality that’s been tossed around as certainly useful but problematically racy, recently.

And let me put the cart before the horse and propose that if we end up using a markup token for this, it be named after lowsrc of yore.

eeeps commented Mar 13, 2015

Do we need to wait for (or instigate) resource priorities work to start working on this?

This would pair nicely with the measuring-sizes-directly functionality that’s been tossed around as certainly useful but problematically racy, recently.

And let me put the cart before the horse and propose that if we end up using a markup token for this, it be named after lowsrc of yore.

@tabatkins

This comment has been minimized.

Show comment
Hide comment
@tabatkins

tabatkins Mar 13, 2015

I don't think this is tied to resource priorities.

I agree that having it tie into the sizes-based-on-layout functionality would be interesting; integrating it syntactically would probably be a good idea.

lowsrc doesnt' seem like a great idea to me; it implies that it should take a url as its value, when all we need is a flag indicating that the browser should choose a lower source from its existing source list.

tabatkins commented Mar 13, 2015

I don't think this is tied to resource priorities.

I agree that having it tie into the sizes-based-on-layout functionality would be interesting; integrating it syntactically would probably be a good idea.

lowsrc doesnt' seem like a great idea to me; it implies that it should take a url as its value, when all we need is a flag indicating that the browser should choose a lower source from its existing source list.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment