Bug 700533 Comment 69 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

[side note: megatests 1 and 2 have a stray code-comment `Will draw the image as 300x227` which is just copypasta that I forgot to delete; ignore it, sorry if it adds confusion when looking at the test]

So comparing Chrome on megatest 2 vs. 3 is interesting. Sorry if the following is confusing; it's a little bit stream-of-consciousness as I try to make sense of things.

There are two different sizes that the browser has to fill in, for each drawImage operation in these megatests:
 (1) What size region of the `<canvas>` should we draw the image into?
 (2) What size should we use as the size for the SVG viewport, when rendering the SVG?

In megatest 3, the answer to question (1) is always 80x160 (hardcoded into the drawImage function-call as args).
In megatest 2, Chrome's answer to question (1) is the full [width,height] of the canvas, if the SVG image has a percent [width,height] -- though if there's a viewBox, Chrome instead seems to size the area-to-fill using the viewBox's aspect-ratio, scaled up to meet the edges of the canvas.  (So for example, in the upper right corner of megatest 1, they don't draw any pink, i.e. nothing from outside of the viewBox).

And then as for question (2): if there's a pixel value in both axes, all browsers use that (and shrink the viewBox to fit it).  Otherwise, Chrome just renders the viewBox itself. Or if there's no viewBox and a percent valued width or height, then Chrome resolves the percent value against the size that they arrived at for question (1).    So for example in the first cell in the second-to-last row of megatest 2: Chrome uses the height of the canvas as the height of the area-to-be-drawn-into, and then it uses a viewport that's sized at 60% of that height, which then ends up meaning the square looks vertically-stretched when we actually draw the rendered SVG to fill the full canvas height.
*[side note: megatests 1 and 2 have a stray code-comment `Will draw the image as 300x227` which is just copypasta that I forgot to delete; ignore it, sorry if it adds confusion when looking at the test]*

So comparing Chrome on megatest 2 vs. 3 is interesting. Sorry if the following is confusing; it's a little bit stream-of-consciousness as I try to make sense of things.

There are two different sizes that the browser has to fill in, for each drawImage operation in these megatests:
 (1) What size region of the `<canvas>` should we draw the image into?
 (2) What size should we use as the size for the SVG viewport, when rendering the SVG?

In megatest 3, the answer to question (1) is always 80x160 (hardcoded into the drawImage function-call as args).
In megatest 2, Chrome's answer to question (1) is the full [width,height] of the canvas, if the SVG image has a percent [width,height] -- though if there's a viewBox, Chrome instead seems to size the area-to-fill using the viewBox's aspect-ratio, scaled up to meet the edges of the canvas.  (So for example, in the upper right corner of megatest 1, they don't draw any pink, i.e. nothing from outside of the viewBox).

And then as for question (2): if there's a pixel value in both axes, all browsers use that (and shrink the viewBox to fit it).  Otherwise, Chrome just renders the viewBox itself. Or if there's no viewBox and a percent valued width or height, then Chrome resolves the percent value against the size that they arrived at for question (1).    So for example in the first cell in the second-to-last row of megatest 2: Chrome uses the height of the canvas as the height of the area-to-be-drawn-into, and then it uses a viewport that's sized at 60% of that height, which then ends up meaning the square looks vertically-stretched when we actually draw the rendered SVG to fill the full canvas height.
*[side note: megatests 1 and 2 have a stray code-comment `Will draw the image as 300x227` which is just copypasta that I forgot to delete; ignore it, sorry if it adds confusion when looking at those test sources]*

So comparing Chrome on megatest 2 vs. 3 is interesting. Sorry if the following is confusing; it's a little bit stream-of-consciousness as I try to make sense of things.

There are two different sizes that the browser has to fill in, for each drawImage operation in these megatests:
 (1) What size region of the `<canvas>` should we draw the image into?
 (2) What size should we use as the size for the SVG viewport, when rendering the SVG?

In megatest 3, the answer to question (1) is always 80x160 (hardcoded into the drawImage function-call as args).
In megatest 2, Chrome's answer to question (1) is the full [width,height] of the canvas, if the SVG image has a percent [width,height] -- though if there's a viewBox, Chrome instead seems to size the area-to-fill using the viewBox's aspect-ratio, scaled up to meet the edges of the canvas.  (So for example, in the upper right corner of megatest 1, they don't draw any pink, i.e. nothing from outside of the viewBox).

And then as for question (2): if there's a pixel value in both axes, all browsers use that (and shrink the viewBox to fit it).  Otherwise, Chrome just renders the viewBox itself. Or if there's no viewBox and a percent valued width or height, then Chrome resolves the percent value against the size that they arrived at for question (1).    So for example in the first cell in the second-to-last row of megatest 2: Chrome uses the height of the canvas as the height of the area-to-be-drawn-into, and then it uses a viewport that's sized at 60% of that height, which then ends up meaning the square looks vertically-stretched when we actually draw the rendered SVG to fill the full canvas height.

Back to Bug 700533 Comment 69