New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 705669 link

Starred by 21 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Task

Blocked on:
issue 721435



Sign in to add a comment

Implement and launch javascript img decode() api.

Project Member Reported by vmp...@chromium.org, Mar 27 2017

Issue description

This change allows web developers to request to decode an img element. The call to a new HTML <img> element’s decode() function returns a promise, which, when fulfilled, ensures that the image can be appended to the DOM without causing a decoding delay on the next frame. 

Sample code:
var img = new Image();
img.src = "nebula.jpg";
img.decode().then(function() {
  document.getElementById("container").appendChild(img);
});

Intent to implement:
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/LMV9dBG_1-I
 
Labels: -Type-Bug PaintTeamTriaged-20170329 BugSource-Team Type-Launch-OWP

Comment 2 by noel@chromium.org, Apr 3 2017

Cc: noel@chromium.org
How does this HTMLImage change spec-ed to work if the img.src is an animated image type (GIF/WEBP/APNG)?

How does this HTMLImage change spec-ed to work if img.src is an MJEG image?


The general idea for this api is that calling decode implies a load, followed by the decode of the image. Specifically for animated images, the load is still implied, followed by the decode of the first frame of the image. domenic@ is working on wording for this.

I'm not too familiar with how the mjpeg (that's what you meant by MJEG right?) works right now. If it's similar to how animated images work, then it should work the same. I'll take a look at that.


The wording should be pretty clear in the draft spec right now: it explicitly waits for the right image state, and then has a non-normative note about animated images specifically. We have tests for this for animated gifs I believe.
We don't have the animated tests yet, that's on my TODO for the implementation :)

Comment 6 by noel@chromium.org, Apr 4 2017

#4 The wording should be pretty clear in the draft spec right now

reference to the draft spec (or it didn't happen :)

Comment 7 by noel@chromium.org, Apr 4 2017

#3 > I'm not too familiar with how the mjpeg (that's what you meant by MJEG right?) works right now.

Yes MJEG, MJPEG normally.  This is defined in the multi-part mime handling sections of the HTML spec.  An MJPEG is a multi-part mime encoded sequence of JPEG images.  Take individual JPEG images and place them in multi-part mime encoded HTTP response.  Decode and display each of the JPEG images in sequence.  Typical use-cases are discussed in  bug 362004 #c17
@6, spec draft is here: https://github.com/whatwg/html/pull/2332/files

There is a note about "Animated images" at the end of the description of what happens once the decode is requested.

Comment 9 Deleted

Comment 10 by noel@chromium.org, Apr 12 2017

re: MJPEG "multi-part mime encoded HTTP response" viz., HTTP Content-Type: multipart/x-mixed-replace

@8 thanks for the link.  Wondered if we could handle animated image types with this API, maybe img.decode(frameNumber) or similar, dunno, but might help with  issue 707356 
Hmm, that's an interesting thought. We kind of punted of some other things like decoding to the appropriate size here, since it's unclear how to get this information correctly prior to inserting the image into the dom. I guess my question would be is whether it's useful to specify any value other than 0 here for it to be displayed (in a typical case that is)
Blockedon: 721435
Labels: migrated-launch-owp Type-Task
This issue has been automatically relabelled type=task because type=launch-owp issues are now officially deprecated. The deprecation is because they were creating confusion about how to get launch approvals, which should be instead done via type=launch issues.

We recommend this issue be used for implementation tracking (for public visibility), but if you already have an issue for that, you may mark this as duplicate.

For more details see here: https://docs.google.com/document/d/1JA6RohjtZQc26bTrGoIE_bSXGXUDQz8vc6G0n_sZJ2o/edit

For any questions, please contact owencm, sshruthi, larforge
Project Member

Comment 15 by bugdroid1@chromium.org, Sep 26 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/5961265cac84855c2777548ed07a4f82b7b8e0dd

commit 5961265cac84855c2777548ed07a4f82b7b8e0dd
Author: Vladimir Levin <vmpstr@chromium.org>
Date: Tue Sep 26 18:42:37 2017

img-decodes: Rework image decodes to align with the reworded spec.

This patch does the following:
- Moves the decode implementation to ImageLoader
- Adds the decode functionality to SVGImageElement
- Reworks the decode functionality to use microtasks to align
  with the proposed spec changes:
  https://github.com/whatwg/html/pull/2965

This patch also cleans up some tests and adds <picture> tests.

R=fs@opera.com, domenic@chromium.org

Bug: 705669
Change-Id: I736f44c59cc173bda9f89000eaea309ddfbbeb85
Reviewed-on: https://chromium-review.googlesource.com/665381
Commit-Queue: vmpstr <vmpstr@chromium.org>
Reviewed-by: Chris Harrelson <chrishtr@chromium.org>
Reviewed-by: Fredrik Söderquist <fs@opera.com>
Cr-Commit-Position: refs/heads/master@{#504436}
[modify] https://crrev.com/5961265cac84855c2777548ed07a4f82b7b8e0dd/third_party/WebKit/LayoutTests/external/wpt/html/semantics/embedded-content/the-img-element/decode/image-decode-iframe.html
[add] https://crrev.com/5961265cac84855c2777548ed07a4f82b7b8e0dd/third_party/WebKit/LayoutTests/external/wpt/html/semantics/embedded-content/the-img-element/decode/image-decode-path-changes-svg.tentative.html
[modify] https://crrev.com/5961265cac84855c2777548ed07a4f82b7b8e0dd/third_party/WebKit/LayoutTests/external/wpt/html/semantics/embedded-content/the-img-element/decode/image-decode-path-changes.html
[add] https://crrev.com/5961265cac84855c2777548ed07a4f82b7b8e0dd/third_party/WebKit/LayoutTests/external/wpt/html/semantics/embedded-content/the-img-element/decode/image-decode-picture.html
[add] https://crrev.com/5961265cac84855c2777548ed07a4f82b7b8e0dd/third_party/WebKit/LayoutTests/external/wpt/html/semantics/embedded-content/the-img-element/decode/image-decode-svg.tentative.html
[modify] https://crrev.com/5961265cac84855c2777548ed07a4f82b7b8e0dd/third_party/WebKit/LayoutTests/external/wpt/html/semantics/embedded-content/the-img-element/decode/image-decode.html
[modify] https://crrev.com/5961265cac84855c2777548ed07a4f82b7b8e0dd/third_party/WebKit/LayoutTests/webexposed/global-interface-listing-expected.txt
[modify] https://crrev.com/5961265cac84855c2777548ed07a4f82b7b8e0dd/third_party/WebKit/Source/core/html/HTMLImageElement.cpp
[modify] https://crrev.com/5961265cac84855c2777548ed07a4f82b7b8e0dd/third_party/WebKit/Source/core/html/HTMLImageElement.h
[modify] https://crrev.com/5961265cac84855c2777548ed07a4f82b7b8e0dd/third_party/WebKit/Source/core/html/HTMLImageLoader.cpp
[modify] https://crrev.com/5961265cac84855c2777548ed07a4f82b7b8e0dd/third_party/WebKit/Source/core/loader/ImageLoader.cpp
[modify] https://crrev.com/5961265cac84855c2777548ed07a4f82b7b8e0dd/third_party/WebKit/Source/core/loader/ImageLoader.h
[modify] https://crrev.com/5961265cac84855c2777548ed07a4f82b7b8e0dd/third_party/WebKit/Source/core/svg/SVGImageElement.cpp
[modify] https://crrev.com/5961265cac84855c2777548ed07a4f82b7b8e0dd/third_party/WebKit/Source/core/svg/SVGImageElement.h
[modify] https://crrev.com/5961265cac84855c2777548ed07a4f82b7b8e0dd/third_party/WebKit/Source/core/svg/SVGImageElement.idl

Comment 17 by mbre...@gmail.com, Nov 6 2017

is the decode cached? I.e. if I call img.decode().then and then add the same <img/> to the dom , will it need to be decoded again?
@17: According to the spec "[the method] attempts to ensure that the decoded image data is available for at least one frame, it can be combined with the requestAnimationFrame() API".
However, I'm not a Chromium engineer so I can't really tell you.
Is this bug finished?
Asking again, is this finished?
Project Member

Comment 21 by bugdroid1@chromium.org, Aug 10

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/32a4a668e4e287c99a3917f1fc16e58a66215ef2

commit 32a4a668e4e287c99a3917f1fc16e58a66215ef2
Author: Eric Willigers <ericwilligers@chromium.org>
Date: Fri Aug 10 04:32:54 2018

Retire  JSImageDecode flag

The  img.decode() api shipped in M64
https://chromium-review.googlesource.com/721771
https://www.chromestatus.com/feature/5637156160667648

BUG=705669

Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_slimming_paint_v2;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I79ea70305d2746794b4ddc0d0af608c32291ce14
Reviewed-on: https://chromium-review.googlesource.com/1165042
Reviewed-by: vmpstr <vmpstr@chromium.org>
Reviewed-by: Chris Harrelson <chrishtr@chromium.org>
Commit-Queue: Eric Willigers <ericwilligers@chromium.org>
Cr-Commit-Position: refs/heads/master@{#582057}
[modify] https://crrev.com/32a4a668e4e287c99a3917f1fc16e58a66215ef2/third_party/blink/renderer/core/html/html_image_element.idl
[modify] https://crrev.com/32a4a668e4e287c99a3917f1fc16e58a66215ef2/third_party/blink/renderer/core/svg/svg_image_element.idl
[modify] https://crrev.com/32a4a668e4e287c99a3917f1fc16e58a66215ef2/third_party/blink/renderer/platform/runtime_enabled_features.json5

Sign in to add a comment