[skwasm] Don't mark the backend texture as mipmapped, since it isn't. (…

…#52501)

We don't actually produce mipmaps for any of the textures generated through the `TextureSourceImageGenerator`, even if it is requested of us. So we shouldn't mark the texture as mipmapped in this case. This will allow rendering mechanisms to fall back to a non-mipmapped rendering strategy as needed.

lib/web_ui/skwasm/image.cpp

@@ -100,7 +100,7 @@ class TextureSourceImageGenerator : public GrExternalTextureGenerator {
     glInfo.fTarget = GL_TEXTURE_2D;
 
     auto backendTexture = GrBackendTextures::MakeGL(
-        fInfo.width(), fInfo.height(), mipmapped, glInfo);
+        fInfo.width(), fInfo.height(), skgpu::Mipmapped::kNo, glInfo);
 
     // In order to bind the image source to the texture, makeTexture has changed
     // which texture is "in focus" for the WebGL context.

lib/web_ui/test/ui/image_golden_test.dart

@@ -192,9 +192,9 @@ Future<void> testMain() async {
         await drawOvalWithShader(const ui.Rect.fromLTRB(0, 0, 150, 100), ui.FilterQuality.none);
         await drawOvalWithShader(const ui.Rect.fromLTRB(150, 0, 300, 100), ui.FilterQuality.low);
 
-        // Note that for images that skia handles lazily (ones created via
+        // Note that for images that CanvasKit handles lazily (ones created via
         // `createImageFromImageBitmap` or `instantiateImageCodecFromUrl`)
-        // there is a skia bug that this just renders a black oval instead of
+        // there is a CanvasKit bug that this just renders a black oval instead of
         // actually texturing it with the image.
         // See https://g-issues.skia.org/issues/338095525
         await drawOvalWithShader(const ui.Rect.fromLTRB(0, 100, 150, 200), ui.FilterQuality.medium);