Not supposed to be merged!

Description

When an SVG does not contain width and height attributes, then it is rendered as black squares in Chrome 148, and prints a WebGL error in the console:

WebGL: INVALID_VALUE: texSubImage2D: bad image data
loadPartialImageSource	@	Texture.js:529

This can be reproduced with the image from issue 13479 and the following trivial sandcastle:

const viewer = new Cesium.Viewer("cesiumContainer");
viewer.entities.add({
  position: Cesium.Cartesian3.fromDegrees(-75.59777, 40.03883),
  billboard: {
    image: "../images/icon1.svg",
  },
});

<!-- Include screenshots if appropriate -->

Sure, here's a screenshot of the rendered SVG:

^🤡

This sill worked in Chrome 147. One could consider this to be a form of regression, but ... who would dare to blame Google here?

<!-- Describe your changes in detail -->

A general recommendation seems to be to not pass img elements to glTexSubImage2D, because it can cause all sorts of trouble and inconsistencies. Instead, one should draw the SVG into a canvas of the desired size, and use that canvas for the glTexSubImage2D instead.

The change here is a DRAFT that "works" with a local test. But it is by no means clear whether this is the right place for the change. The change is in the loadImageElement function, and for the record, I'll quote the full documentation of this function, its purpose, and its parameters here:

The code part itself and its call site link to...

• Make img.naturalWidth/Height handle dimensionless images better whatwg/html#3510
• https://bugzilla.mozilla.org/show_bug.cgi?id=700533
• Dimensionless SVG does not render in Firefox #9188 (comment)
• Dimensionless SVG does not render in Firefox #9188 (comment)
• https://bugzilla.mozilla.org/show_bug.cgi?id=1044102#c38
• https://bugs.chromium.org/p/chromium/issues/detail?id=580202#c10
• Use createImageBitmap when available #7579 (comment)

to explain (or rather justify) what is done there, but 1. didn't backtrack through all these links (and some appear to be broken), and 2. any change will likely cause some form regression, given that there are several layers of workarounds stacked on top of each other.

For now, the purpose of this PR is only to illustrate that trying to load SVG directly appears to be prone to issues, and we should consider using the canvas-based approach instead.

Issue number and link

#13479

Testing plan

n/a

Author checklist

• I have submitted a Contributor License Agreement
• I have added my name to CONTRIBUTORS.md
• I have updated CHANGES.md with a short summary of my change
• I have added or updated unit tests to ensure consistent code coverage
• I have updated the inline documentation, and included code examples where relevant
• I have performed a self-review of my code

AI acknowledgment

• I used AI to generate content in this PR
  • Yes
  • No
  • You decide: I typed "texSubImage2D svg img" into google, and some AI responded that one should usually not pass an SVG directly to this function, but draw it into a canvas instead. I could hardly prevent that.
• If yes, I have reviewed the AI-generated content before submitting

If yes, I used the following Tools(s) and/or Service(s):

I think it's called "Gemini"...

If yes, I used the following Model(s):

Well...