-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Should createImageBitmap support vector formats? #923
Comments
See #921. |
I think #921 is a short term fix to clarify the spec, while this issue is an actual feature request. It should be noted that the sizing algorithm that is used when drawing SVG with 2D canvas's drawImage() cannot be use here because createImageBitmap is not tied to a canvas element that can be used as a reference for sizing. |
This change makes it explicit that creating an ImageBitmap from a Blob only supports *bitmap* file formats. This behaviour is consistent with creating an ImageBitmap from an img element, which explicitly does not support vector graphics. Note: Supporting vector graphics would require defining a sizing algorithm to determine the scale of image, or to have an alternate API that has additional size parameters. See feature request in #923. PR: #921
I agree we should have this, but if an SVG has width & height attributes set then we don't need either. |
#865 proposes the size params |
In the options proposal (https://wiki.whatwg.org/wiki/ImageBitmap_Options) we had resizedWidth/resizedHeight. Perhaps we should just drop the "resized" prefix, which does not make much sense in the case of SVG. The width and height option would apply to both svg and bitmap scaling. When calling createImageBitmap with an svg source, I suppose the behavior would be to throw an exception if width/height are not specified? Also, svg images do have an intrinsic aspect ratio, so we could get away with specifying just width or height, and the other dimension could be inferred. In the case where both width and height are specified, we'd need an additional option to specify how differences in aspect ratio are handled. Something like the fill, contain and cover modes of the object-fit css property. WDYT? |
@jakearchibald: regarding your comment about using the width & height attributes, I assuming you are referring to the image element's, computed size? I would like to avoid depending on that unless absolutely necessary. Two reasons : It is problematic for elements that are not attached to the active DOM because their style and layout is not evaluated, and it would make createImageBitmap dependent on style computation (may induce style recalc). |
It's not style dependant, it's width and height attributes on the SVG element itself. This is used to determine the |
If the SVG has no defined size and no width/height set in createImageBitmap, happy with rejecting. Also agree with width/height rather than "resize". |
So you were referring to the width and height content attributes then? That seems logical, except that the spec says that those attributes "must be omitted if the resource in question does not have both an intrinsic width and an intrinsic height". See: https://html.spec.whatwg.org/multipage/embedded-content.html#attr-dim-width |
I'm guessing there must be something that overrides that. See http://jsbin.com/lijana/edit?html,output - the IMG here has no size specified, but it gets its dimensions from the SVG element's width and height attributes. |
https://svgwg.org/svg2-draft/coords.html#IntrinsicSizing - intrinsic sizing of SVG |
This is interesting. In your jsbin, I tried adding width="100" to the img tag, and it worked, it shrunk the car. So it seems that svg image are treated as having an intrinsic size for the purposes of this section of the spec: https://html.spec.whatwg.org/multipage/embedded-content.html#attr-dim-width This is uncomfortably inconsistent with the behavior of CanvasRenderingContext2D.drawImage |
@doomdavve, you're our only hope. |
Yeah, the intrinsic sizes of an are computed from the width/height/aspectRatio attributes on its root. This gets fed into the sizing algorithms, exactly like the intrinsic sizes of raster images. In the case that those don't exist, CSS has a well-defined algorithm that all image-y things share to determine the concrete width/height of the resource: https://drafts.csswg.org/css-images/#concrete-size-resolution. You just need to define the default object size for this case and invoke the algorithm; the output is a width and height for you to use. From HTML:
Wtf is this talking about. This makes absolutely no sense. I'll file a separate bug to have this line removed, it's nonsense. |
I agree with all what Tab writes. And just to tie it together, https://drafts.csswg.org/css-images/#concrete-size-resolution is what CanvasRenderingContext2D.drawImage() uses to determine the width and height, with no specified size and the canvas size as the default object size. https://html.spec.whatwg.org/multipage/scripting.html#drawing-images I'm a bit confused about this discussion. @jakearchibald seems to be talking about the width and height attributes of the
Yes, adding
@junov Could you clarify the inconsistency? CanvasRenderingContext2D.drawImage() doesn't have any specified size constraints but should otherwise be quite analogous to the |
Here is what I am confused about: |
Why do you say that? The behavior of drawing an |
I don't feel like digging thru a patch right now, so I'll let you summarize what it does. Are you saying that that code treats all SVG images as having no intrinsic dimensions? If so, it's buggy. width/height/aspectRatio on the root |
My understanding is that it considers svg images as having intrinsic aspect ratio but no intrinsic size. @doomdavve ? |
It certainly considers the intrinsic size of SVG images. The thing that particular patch does is to pipe through the canvas size as default object size to use as fallback size in case the SVG image doesn't have an intrinsic size. |
Okay, I got it. Thanks for enlightening me. So SVG images may or may not have an intrinsic size. Sorry about all the confused arguments on my part. So to cycle back to the desired behavior for createImageBitmap. If the source is an HTMLImageElement, an SVGImageElement or a Blob the currently spec'ed behavior is to reject the promise if the source is a vector graphics. Instead, the behavior could be to reject the promise if the source has no intrinsic dimensions. And once we add width/height parameters to the creation options dictionary, the the behavior could be to reject the promise only if the source has no intrinsic dimensions and the width and height parameters are unspecified. Does that make more sense? |
Perfect! I'm happy with this as a first pass too, as I can easily manipulate the SVG string to add the width & height attrs. |
No reason to reject images with no intrinsic dimensions. First, if they're loaded in an |
What would the size be of an SVG blob with no width/height attrs? const svgBlob = new Blob(['<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 10 10">…</svg>'], {
type: 'image/svg+xml'
});
createImageBitmap(svgBlob); |
Ugh, sorry, forgot the thread of the conversation. This is about ImageBitmap, so we don't have a canvas yet. Yeah, reject things without intrinsic width and height. |
Great! I'll whip-up a PR. |
This change fixes issue #923 by allowing ImageBitmap objects to be created from SVG source images, as long as the image has an intrinsic size. If the image does not have an intrinsic size, we still reject the promise with an InvalidStateError, as before. This change also removes CanvasRenderingContext2D from ImageBtimapSource, which was an oversight in PR #790. Since there is no longer a concept of a standalone context, this is no longer needed.
This was fixed through #972. Thanks everyone! |
This change fixes issue whatwg#923 by allowing ImageBitmap objects to be created from SVG source images, as long as the image has an intrinsic size. If the image does not have an intrinsic size, we still reject the promise with an InvalidStateError, as before. This change also removes CanvasRenderingContext2D from ImageBtimapSource, which was an oversight in PR whatwg#790. Since there is no longer a concept of a standalone context, this is no longer needed.
Step 3 of https://html.spec.whatwg.org/multipage/webappapis.html#dom-createimagebitmap for
<img>
specifically rejects on vector data, but it doesn't reject for blobs. There's a vague "If the image data is not in a supported file format" step for blobs, is this supposed to reject on vectors?See https://jakearchibald.github.io/svgomg/ - as a developer, I'd like to control the rasterisation of SVG data using
createImageBitmap
to allow for smooth zooming and panning but lazy re-rendering at the target dimension (and cropped area).The text was updated successfully, but these errors were encountered: