A signal for when an image (img) is decoded enough to paint

[annevk]

See the discussion starting at #1920 (comment) for context.

The idea is to extend the img element with an event, overload decode() somehow, or introduce a another signal not suggested thus far that indicates when it's ready to be displayed to users. While at the same time not making it a high priority relative to painting and hitting 60 FPS and such.

I hope I summarized that correctly.

cc @dbaron @smfr @othermaciej @vmpstr @aghassemi @cramforce @chrishtr

[othermaciej]

I think this needs to be a mode of decode() or a new method along similar lines, because an image may never be decoded enough to paint if the author don’t ask for it. Examples: if it’s not in the DOM, if it’s offscreen, if it’s currently display: none, (hypothetically) if the layout engine detects that no part of it is visible due to opacity, visibility or occlusion. Because of this, an event is not sufficient. This is essentially the same reason decode() had to be a promise-returning method instead of an event.

[cramforce]

An argument to decode seems fine to me. I don't have a good naming suggestion :)

[annevk]

To bikeshed: decode({ priority:"low" }); defaults to "high".

[cramforce]

Ah, I read this more as decode({progressive: true}) (So, try to do a progressive decode if applicable). This might just be a different concern from what you wanted to address @annevk.

[annevk]

Ah, I think there might indeed be two different use cases lurking in that thread:

1. Please let me know when I can paint this complete image, but don't let decoding it take priority over other things (keep it asynchronous, etc.).
2. Please let me know when I can paint anything from this image.

[smfr]

Please let me know when I can paint this complete image, but don't let decoding it take priority over other things (keep it asynchronous, etc.).

This is already covered by decoding=async and decode(), right? Unless you meant to write incomplete, or want some kind of decoding prioritization.

Please let me know when I can paint anything from this image.

I guess this is the incomplete case that we're focusing on here. decode({progressive: true}) would make sense.

[annevk]

@smfr I see, I thought invoking decode() put more priority on decoding than would otherwise be the case (in a scenario where the conditions @othermaciej listed do not apply, e.g., it's visible to the user).

[othermaciej]

Current decode() will initiate decoding of an image even if decoding would not start otherwise, but, at least in WebKit’s implementation, will not make it higher priority than other decoding.

{progressive: true} is close to the right concept, but a little off I think. It doesn’t get across the idea that the promise will be resolved at a different time. Also, regular decode doesn’t prevent progressive decoding necessarily in the case where the image would otherwise paint anyway.

Some examples of syntax that would focus on the issue of the promise firing at a different time:

• decode({firstFrameOnly: true}
• decode({minimallyPaintable: true}
• decode({full: false} (with the default being true)
• decode({notifyWhen: “paintable”}) (with the default being {notifyWhen: “complete”})

I kind of like the last option , though it is a bit wordy. I could think of a boolean version that is equally clear.