Closed luigi-rosso closed 2 years ago
Same on 3.0.2, btw:
[✓] Flutter (Channel unknown, 3.0.2, on macOS 12.3.1 21E258 darwin-arm, locale en-US)
And also repros on latest master:
[✓] Flutter (Channel master, 3.1.0-0.0.pre.1346, on macOS 12.3.1 21E258 darwin-arm, locale en-US)
Hi @luigi-rosso, thanks for filing the issue.
This issue is reproducible on the latest stable
: 3.0.3
and master
: 3.1.0-0.0.pre.1354
.
Chrome: Version 103.0.5060.53 (Official Build) (x8664) (latest version on macOS host machine)_
This issue only happens with Canvaskit
renderer, it displays well with HTML
renderer (see in demo)
Is there any e.t.a on this. We are launching a web game soon where this would set back the launch possibly quite a bit unless we opt for html rendering which is not tested for our game.
This works as expected if I set BROWSER_IMAGE_DECODING_ENABLED=false
to revert to the old image decoder implementation:
flutter -d chrome run --web-renderer=canvaskit --dart-define=BROWSER_IMAGE_DECODING_ENABLED=false --release
This is still reproducible in a current daily build of Chrome (105.0.5140.0).
The ImageDecoder API looks like it is returning the same output as it did in Chrome 102. But something has apparently changed downstream of that when the texture is rendered.
@yjbanov @kjlubick
This works as expected if I set
BROWSER_IMAGE_DECODING_ENABLED=false
to revert to the old image decoder implementation:flutter -d chrome run --web-renderer=canvaskit --dart-define=BROWSER_IMAGE_DECODING_ENABLED=false --release
This is still reproducible in a current daily build of Chrome (105.0.5140.0).
The ImageDecoder API looks like it is returning the same output as it did in Chrome 102. But something has apparently changed downstream of that when the texture is rendered.
@yjbanov @kjlubick
Can confirm this fix works. Without it my flutter canvaskit game has a lot of graphical glitches on Chrome 103 and newer.
Here's a different test case using CanvasKit 0.34.1 https://jsfiddle.skia.org/canvaskit/9c4a6f931f41d953d6c313deb14d9a6a192a56961b9a8ed84125e328708208af
This works fine for me on WebGL 2 on my Linux box and M1 Mac. It exercises some of the texture logic, which I was suspicious of. Does this work for others? If so, it means the issue is in different APIs or upstack of CanvasKit.
Ran a bisect of Chromium versions, which yielded this result:
You are probably looking for a change made after 994565 (known good), but no later than 994569 (first known bad).
CHANGELOG URL:
https://chromium.googlesource.com/chromium/src/+log/d2ed55fb4976616f764830105fb1fdaeb2adbccc..438551efcc62cb07ffa9b025c4338900d2daa631
That range contains this commit: "WebGLImageConversion::ImageExtractor: Remove alpha op" (https://chromium.googlesource.com/chromium/src/+/de0badc548a40620a49371622023ec333a1a5731%5E%21/#F0)
@ccameron-chromium @kenrussell
That CL has been implicated in another bug as well (the other bug is performance, not correctness).
Could you write up instructions on how to set up to reproduce the bug? Or better yet is there a link I can visit which will reproduce it? (The jsfiddle link does not exhibit the bug on my machine).
This can be reproduced by running the Flutter app linked in https://github.com/flutter/flutter/issues/106433#issue-1280665398:
git clone https://github.com/flutter/flutter
git clone https://github.com/luigi-rosso/flutter_web_alpha_bug
cd flutter_web_alpha_bug
flutter/bin/flutter -d chrome run
I can help with debugging inside the Flutter Web engine implementation.
Thank you! I've done some investigation at: https://bugs.chromium.org/p/chromium/issues/detail?id=1340190#c3
Flutter is expecting its WebGL texture uploaded by texImage2D with a VideoFrame to be in premultiplied format, but the WebGL context has the UNPACK_PREMULTIPLY_ALPHA_WEBGL pixel storage parameter set to FALSE. In my reading of the various specifications, Flutter should set UNPACK_PREMULTIPLY_ALPHA_WEBGL to TRUE for this texImage2D call.
The patch linked above fixes a bug where, when uploading from a VideoFrame, Chrome would often ignore the value of UNPACK_PREMULTIPLY_ALPHA_WEBGL.
In either case, it will be safe to set UNPACK_PREMULTIPLY_ALPHA_WEBGL to TRUE during that specific texImage2D upload (and then restore it after the call). If we update the spec to reflect the behavior (and revert the behavior change I made in that patch), then this will still work.
I personally feel that the behavior of both ImageBitmap and WebCodecs, in allowing the user to specify things like premultiplyAlpha, is making a mistake. It is always most efficient to decode into the image's native format (especially for formats where the native format is YUV), and then have the consuming API perform whatever conversion is needed, to a well-defined target format, on the GPU. It is also, in my opinion, a mistake for APIs to expose the "native format" implicitly (because various vagaries of the internals of things may affect this -- we may not always be able to use YUV for images, or we may only support some color spaces, etc). But that's me rambling.
I'm raising this issue to the WebGL and WebCodecs team, so they can decide if we should fix the spec to reflect the behavior before my patch, or if I should remove the behavior change caused by my patch.
I'm leaning very heavily towards requiring that flutter set UNPACK_PREMULTIPLY_ALPHA_WEBGL (I'm very much against the pre-conversion behavior that ImageBitmapOptions and ImageDecoderInit want).
Is this something set when creating the <canvas>, getting the webgl2 context, or on/around the tex2d call? If it's the last option, that will need to be a CanvasKit change.
It's something that needs to be done around the tex2d call, here.
Thanks. I now have a case that reproduces in a visually similar way: when I tell CanvasKit the image is Premul https://jsfiddle.skia.org/canvaskit/11c85ce8ad92b95e20c1246a6a51adce3c6b498cd8400e30a42a7b28b97175b7
This happens for me in Edge browser as well: Version 103.0.1264.37 (Official build) (64-bit). My app uses CanvasKit by default.
CanvasKit roll definitely fixes this issue: https://github.com/flutter/engine/pull/34415
CanvasKit roll is merged. I'm going to go ahead and close this issue.
Any chance for a stable hotfix release?
FYI, RE clarifying the spec.
3.0.4 and 3.0.5 patches have been released since this issue reported. Any update on a stable hotfix?
it's still happen on 3.0.5 and chrome 103
Is this fixed? I see the issue as closed and fixed but on 3.0.5 I am still getting the same problem, do I have to do something on my end to fix this permanently?
Is this fixed? I see the issue as closed and fixed but on 3.0.5 I am still getting the same problem, do I have to do something on my end to fix this permanently?
Same for me, still happening. I also found this: issue
Also still see this issue on 3.0.5
Im not sure how wise it is but you can build with a later version of CanvasKit.
flutter build web --dart-define=FLUTTER_WEB_CANVASKIT_URL=https://unpkg.com/canvaskit-wasm@0.35.0/bin/
Seems to resolve the problem at least until it rolled into stable.
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v
and a minimal reproduction of the issue.
It seems like images with alpha don't draw properly in Chrome (works in Safari) with Flutter. Using a simple image widget:
https://github.com/luigi-rosso/flutter_web_alpha_bug/blob/0cf2002f2174135b0a3f2cf274cf810c3ad50f45/lib/main.dart#L82
I'm not sure if this is a Flutter bug but I'd like to raise awareness and perhaps you can help us track down where this should be filed as it does severely impact Flutter.
Source for the example is here: https://github.com/luigi-rosso/flutter_web_alpha_bug
How it looks in Chrome Version 103.0.5060.53 (Official Build) (arm64):
How it looks in Safari:
In MacOS:
Works in CanvasKit's fiddle, but lots of other factors here including CanvasKit version...