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

Issue 761809 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Last visit > 30 days ago
Closed: Sep 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

Support resizeWidth and resizeHeight in createImageBitmap

Project Member Reported by jakearchibald@chromium.org, Sep 4 2017

Issue description

https://bugs.chromium.org/p/chromium/issues/detail?id=627855 was closed as fixed but it doesn't appear to work.

Test: http://jsbin.com/mejawa/edit?js,console

Expected console output is 100, 100.
 
Cc: junov@chromium.org
Status: Assigned (was: Untriaged)
Cc: xidac...@chromium.org
It might be something related to SVG. We have createImageBitmap with resize layout tests from blob, canvas, image, imagebitmap, imagedata and video in third_party/WebKit/LayoutTests/fast/canvas/webgl/. We need to fix this bug and add the respective tests for SVG and OffscreenCanvas sources.
We should also test that the SVG remains sharp after resizing. Not sure how to test that. Maybe take a 1x1 SVG and scale it to 100x100 and hopefully get more than a single colour out of it.
ImageBitmap uses a SkImage as the storage and as far as I know we don't keep a copy of the SVG object (or a reference to the source SVG object) in ImageBitmap. If I understand correctly, SVG is painted onto a canvas and we get the SkImage from the surface (see: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/svg/graphics/SVGImage.cpp?sq=package:chromium&dr&l=396). This means when we have a 1x1 ImageBitmap we only have one pixel information, and the SVG won't be restored if we resize back to the main size.

junov@, would you please comment on this if I'm wrong?

Also the HTML standard does not say anything about keeping the ImageBitmap object linked to the source (here, SVG): https://html.spec.whatwg.org/#images-2.
In contrast, when defining ResizeQuality it says it is a preference for "interpolation quality", which I believe means we have pixels at the end, not vectors, and we cannot expect the sharp vector quality when we enlarge the ImageBitmap (we expect sharp quality when we enlarge from the source SVG though).
Related: https://github.com/whatwg/html/issues/1552.

If we can't make resizeWidth/Height vector friendly, we should come up with something else that is.
It's possible to do. We can keep a reference to the source SVG (or copy the object, if needed) and redraw from the SVG whenever needed. I'm just not sure if we need to do that.
Use-case: I want to create a tool that allows the user to zoom into an SVG without jank.

I'll draw the SVG to a canvas, and react to mouse/touch events to pan/zoom the SVG on the canvas without having to re-rastersize the SVG per frame.

When the user zooms in, I'll lazily redraw the visible region at 1:1 device pixels.

createImageBitmap allows me to do this on another thread, but I need to be able to control the crop & output pixel size, while achieving a sharp output.
IIUC even if we keep the SVG linked to the ImageBitmap in Blink, we need to redraw the SVG object onto a surface every time we need a sharp representation of the SVG in a desired crop+resize scenario (otherwise, there will be glitches). This will be roughly the same as doing a new createImageBitmap call using the source SVG object in JS. 

What is the problem with doing a new createImageBitmap and drawImage on the JS side instead of doing only drawImage on the JS side and hiding the createImageBitmap part in the Blink?

As I see this feature is working as expected. The only problem is that the API is still behind a flag:

https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/imagebitmap/ImageBitmapOptions.idl?q=ImageBitmapOptions.idl&sq=package:chromium&dr

Please go to chrome://flags and enable "Experimental Canvas Features" and reload the webpage. It should report 100, 100.

I close this bug. I filed another bug ( crbug.com/762558 ) to add the proper layout tests and a bug for turning on the resize feature by default ( crbug.com/762559 ).
Status: WontFix (was: Assigned)
Apologies, I wasn't aware this was behind a flag.
https://lazy-svg.glitch.me/ - hacked this together, which uses createImageBitmap to lazy-render parts of an SVG.
Cool. Thanks for sharing this.
Which Chrome release is this targeting?
I think the feature is ready to ship. The tests for resize from OffscreenCanvas are also added to the code base ( crbug.com/762558 ). I need to verify that all the tests are running on all the platforms before moving forward.
fwiw I wrote about this at https://jakearchibald.com/2017/lazy-async-svg/.
Cool. Thanks. AFAIK it should work fine on stable too, Canary is not needed.
Thanks Jake, it is a great article.
Does the off-main-thread rendering happen in stable too? I thought that was
more recent.
jakearchibald@: It is in M61. We just need the experiment-canvas-feature flag.
Thanks. I've updated the article.

Sign in to add a comment