Skip to content
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

Shadows depend on internal canvas state #51237

Closed
yjbanov opened this issue Feb 22, 2020 · 44 comments · Fixed by flutter/engine#27124
Closed

Shadows depend on internal canvas state #51237

yjbanov opened this issue Feb 22, 2020 · 44 comments · Fixed by flutter/engine#27124
Labels
a: desktop Running on desktop a: tablet Tablets and landscape phones c: rendering UI glitches reported at the engine/skia rendering level customer: house dependency: skia Skia team may need to help us engine flutter/engine repository. See also e: labels. found in release: 1.24 Found to occur in 1.24 has reproducible steps The issue has been confirmed reproducible and is ready to work on P1 High-priority issues at the top of the work list platform-android Android applications specifically platform-ios iOS applications specifically platform-linux Building on or for Linux specifically platform-mac Building on or for macOS specifically platform-windows Building on or for Windows specifically r: fixed Issue is closed as already fixed in a newer version

Comments

@yjbanov
Copy link
Contributor

yjbanov commented Feb 22, 2020

Steps to Reproduce

flutter run the following Flutter app:

Sample app
import 'dart:ui';
import 'package:vector_math/vector_math_64.dart';

const Color _kShadowColor = Color.fromARGB(255, 255, 0, 0);
final Path shadowPath = Path()..addRect(const Rect.fromLTRB(0, 0, 20, 20));

Future<void> main() async {
  window.onDrawFrame = () {
    final SceneBuilder builder = SceneBuilder();

    void _paintPicture(Rect bounds, void Function(Canvas) painter) {
      final PictureRecorder recorder = PictureRecorder();
      painter(Canvas(recorder, bounds));
      builder.addPicture(Offset.zero, recorder.endRecording());
    }

    void _paintOutline() {
      _paintPicture(Rect.largest, (Canvas canvas) {
        canvas.drawRect(
          const Rect.fromLTRB(0.0, 0.0, 20.0, 20.0),
          Paint()
            ..color = const Color.fromARGB(255, 0, 0, 255)
            ..style = PaintingStyle.stroke
            ..strokeWidth = 1.0,
        );
      });
    }

    void _paintPhysicalShapeShadow(double elevation, Offset offset) {
      builder.pushOffset(offset.dx, offset.dy);
      builder.pushPhysicalShape(
        path: shadowPath,
        elevation: elevation,
        shadowColor: _kShadowColor,
        color: const Color.fromARGB(0, 0, 0, 0),
      );
      _paintOutline();
      builder.pop(); // physical shape
      builder.pop(); // offset
    }

    void _paintBitmapCanvasShadow(double elevation, Offset offset) {
      builder.pushOffset(offset.dx, offset.dy);
      _paintPicture(Rect.largest, (Canvas canvas) {
        canvas.drawShadow(
          shadowPath,
          _kShadowColor,
          elevation,
          true,
        );
      });
      _paintOutline();
      builder.pop(); // offset
    }

    _paintPicture(Rect.largest, (Canvas canvas) {
      canvas.drawColor(const Color.fromARGB(255, 255, 255, 255), BlendMode.color);
    });

    builder.pushTransform(Matrix4.diagonal3Values(5, 5, 1).storage);
    builder.pushOffset(10, 40);

    for (int i = 0; i < 7; i++) {
      _paintPhysicalShapeShadow(i.toDouble(), Offset(40.0 * i, 0));
    }

    for (int i = 0; i < 7; i++) {
      _paintBitmapCanvasShadow(i.toDouble(), Offset(40.0 * i, 80));
    }

    for (int i = 0; i < 7; i++) {
      _paintPhysicalShapeShadow(i.toDouble(), Offset(40.0 * i, 160));
    }

    builder.pushOffset(0.0, 240.0);
    _paintPicture(Rect.largest, (Canvas canvas) {
      for (int i = 0; i < 7; i++) {
        canvas.drawShadow(
          shadowPath,
          _kShadowColor,
          i.toDouble(),
          true,
        );
        canvas.drawRect(
          const Rect.fromLTRB(0.0, 0.0, 20.0, 20.0),
          Paint()
            ..color = const Color.fromARGB(255, 0, 0, 255)
            ..style = PaintingStyle.stroke
            ..strokeWidth = 1.0,
        );
        canvas.translate(40.0, 0);
      }
    });
    builder.pop(); // offset

    builder.pop();
    builder.pop();
    window.render(builder.build());
  };
  window.scheduleFrame();
}

Expected results:

The shadows in each column should be identical.

Actual results:

The shadows are different.

shadows

This is observable as of 3cee8e0

@yjbanov
Copy link
Contributor Author

yjbanov commented Feb 22, 2020

The theory is: the shadow depends on the state of the canvas we draw on, in addition to the shadow parameters that are passed (color, path, elevation). It seems the shadow is pushed away from the (0, 0) coordinate along the X axis. Because the second row uses one canvas per shadow the X offset stays the same. However, the fourth row draws multiple shadows in one wide canvas. Notice how the right-most shadow is pushed to the right.

Big thanks to @DaveShuckerow for discovering this!

Note, this bug does not affect the Web (the Web has other issues, but not this one).

/cc @chinmaygarde

@yjbanov yjbanov added dependency: skia Skia team may need to help us engine flutter/engine repository. See also e: labels. c: rendering UI glitches reported at the engine/skia rendering level labels Feb 22, 2020
@yjbanov
Copy link
Contributor Author

yjbanov commented Feb 22, 2020

@chinmaygarde @cbracken I did not assign a milestone to this. Feel free to triage a you see fit. I speculatively added dependency on Skia because my investigation of this bottomed out at a call to the Skia API (third_party/skia/include/utils/SkShadowUtils.h). I'll focus on fixing web shadows (#32215).

@creativecreatorormaybenot
Copy link
Contributor

@yjbanov Is this not the same behavior I alluded to in #48027? It is obvious that the shadow depends on the canvas' state because this will determine where the light source is positioned relative to the shadow.

Btw, I depend on this behavior in creativecreatorormaybenot/clock. In particular, here: L802

Went a bit more in-depth here.

@rydmike
Copy link
Contributor

rydmike commented Feb 22, 2020

@yjbanov I'm happy to see this issue noticed and recorded. I had planned to raise it too, but now I will just add my 0.05$ worth of input to it.

TLDR

I think the behavior reported here is caused by the imaginary light source placement used in the Material Elevation design to cast shadows.
The Material team does beautiful designs, but it looks to me like either the design or the Flutter implementation does not properly consider the impact of the current used implementation on larger surfaces. The current implementation looks very poor on larger surfaces.


The imaginary light source for Material Elevation shadows clearly places the light source above the upper left corner of the surface. In my opinion, at least in the Flutter implementation, this light source location is too low down (z axis wise from the surface). This causes the elevation shadows to become very deep on the bottom and right side of elements, as the surface area grows and elements with elevation shadows are placed close to the bottom or right edge of the surface area.

Below are some examples to demonstrate the issue.

The screenshots below were rendered with Flutter 1.15.4-pre.107 channel master on Windows Desktop, but the same effect can be seen already when using large Android/iOS Tablet devices. The desktop usage just makes it possible too resize and easily show the issue. Also, never mind the content on the screenshots, it is just from an experimental version of a test/dev application’s Settings screen that has Material Card panels and other elevation using elements and it is responsive and show current screen size. Very practical for demonstrating this issue. I noticed this issue in June 2019 and it has remained unchanged since.

All the settings panels below are Material Cards in the screenshots and use the same Material Elevation 3. The demonstrated differences in the shadows depend on their location on the screen, in relation to the imaginary light source.

On small devices, phones and small tablets, the reported surface pixel size is quite small, so the deeper shadows towards the bottom of the screen or the right edge, is barely visible and very subtle.

Size iPhone5
For example, on a small device like an iPhone5 that reports 320x568 pixels, everything looks fine, even though the higher elevation towards the bottom can noticed if you look really closely, the effect is still fine and subtle, probably like intended.
Size-iPhone5-320x568

Size iPhone Xs Max
On new and much larger phones, like iPhoneXs Max that reports 414x896 pixels, it is more obvious already towards the bottom of the screen.
Size-iPhoneXsMax-414x896

Size iPad Pro 12.9
When we move up in surface size to what is probably the largest current device, the 12.9” iPad Pro that reports 1366x1024 pixels, the differences in shadow depths become obvious and already don’t look so nice anymore.
Size-iPadPro12_9in-1366x959

In the next picture the drawer is closed on same iPad size, just to show that the shadow sizes are the same as in the previous images on the edges, demonstrating that that shadow depth is, as it should be, dependent only on the physical location of the element with a shadow on the screen and not of the layout area where it is placed, which would not work if we want location based shadows.
Size-iPadPro12_9in-1366x959-Drawer-Hidden

Ref: iPhone pixel sizes
iPad pixel sizes

Size full HD - Desktop/Web
As we move up in size to the most common desktop/web size, full HD 1920x1080 pixels. The Material Elevation shadows towards the bottom and right edge are already so pronounced that using them can no longer be recommended.
Size-Desktop-1920x1080

Size 4k
If we go up to 4k resolution, then the Material Elevation shadows start look utterly ridiculous. Sure, my automatic responsive application layout is beginning too look silly at this size too, but that is another topic. 😊
I threw in a Theme Details panel on this large layout too, just to show that this issue affects all widgets that use Material Elevation for shadows, not just the Material Card.
Size-Desktop-4k


I hope any of this is useful input and that elevation shadows in Flutter for larger surfaces can be improved.

I think this might be something that needs to be looked over together with the Material design team. Maybe they have already considered how shadows should look and behave on larger surfaces, maybe not, but at least it is clear that Flutter’s implementation of how shadows behave on larger surfaces does not look so nice now and I honestly doubt the Material design team intended it to look this way on larger surfaces.


FINALLY
It is worth noticing that this shadow issue only affects Material Elevations, if you create a custom shadow using using BoxShadow you will not have this issue. However, as a lot of widgets depends on elevation for their shadow the impact is rather wide spread. I think the solution is just to move the imaginary light source proportionally higher up as the surface area grows, in order to keep a more subtle effect on the depth of the shadows for larger surfaces, while keeping it still detectable/visible on smaller surfaces too, if that is the design intent.

The HTML/WEB shadow issue in 32215 also affects how custom BoxShadows look on web and they differ significantly from the Andorid/iOS/MacOS/Win look. There it is probably a difference in the shadow rendering implementation. Since elevation shadows in Flutter probably uses the same primitives to draw shadows as BoxShadow (I tried to check, but the rabbit hole was too deep for me) the look of material elevation shadows on large Web desktop layouts might be affected by both issues.

@yjbanov
Copy link
Contributor Author

yjbanov commented Mar 6, 2020

/cc @liyuqian - related to our discussion yesterday

@liyuqian
Copy link
Contributor

liyuqian commented Mar 6, 2020

@jvanverth is the Skia expert on shadows I believe. He may have some insights on why this happened.

@jvanverth
Copy link

Those results seem expected to me -- with the DrawShadow call, the light position and radius is not affected by the matrix, so as the paths get farther and farther away from it, the more shadowing you get. This look is consistent with what you'd get from Android. That said, it should be possible to get a more orthographic look with DrawShadow by locking the light position to the path in some way.

@creativecreatorormaybenot
Copy link
Contributor

That is what I said as well 😕

@rydmike
Copy link
Contributor

rydmike commented Mar 7, 2020

Thanks for looking into this.
A considerably more orthographic look is certainly needed, probably there are different ways of achieving it, higher light position plus wider light radius or by moving the light position along the path.

Yes the elevation shadows look is the same on all Skia using implementations (Win, Linux, Mac, iOS, Android, Fuchsia ?). It is just that on typical small handheld devices, the drawing surface is so small that it is less of an issue on them, people tend not to notice it as much, although it is clearly visible already on large modern phones. Increased desktop and large tablet usage is clearly making this issue more obvious now.

Just as another example here are two fresh comparison screenshots, using the Skia (from Win Desktop in this case) rendering and Web (apparently with the fix, applied) implementation, both screenshots were made with Flutter master: Flutter 1.15.19-pre.7

Desktop/Skia
Skia-Elevation-Shadows

Web
Web-Elevation-Shadows

The fix flutter/engine#16963 for Web that fixed the too large and fuzzy shadows on WEB, also made the WEB elevation shadows look fairly close to when an element is close enough to the upper left corner in the Skia implementation. The WEB implementation does not show the same kind of light source behavior as the Skia implementation. The WEB elevation shadows now actually look much better on large surfaces than the Skia variant does, so that is nice progress! 👍

One could of course argue and discuss what the actual design intent is? How should it look according to Material design? Still I cannot really think that the Material design team would condone the current look we currently get with elevations when using the Skia implementation. It effects all elements that use elevation shadows and the current implementation makes all elevations on larger surfaces, when the element is far right or low down, look... well to be a bit blunt, utterly ridiculous! So I seriously doubt it is intended to look like this. Modern Material design is after all quite tasteful! 😃 Still, please do discuss it with the Materiel design team too. How should it really look? As we are aiming for desktop use too, the design needs to work and be tested all they up to at least 8k resolution.

@chinmaygarde chinmaygarde removed the dependency: skia Skia team may need to help us label Mar 23, 2020
@rydmike
Copy link
Contributor

rydmike commented Apr 28, 2020

Is there any update on this issue?

The more people start using Flutter on desktop the more this will become a major issue, as it is not only the elevation of Material Card's that it effected, but also all Material widgets that use elevation. While it is possible to avoid using elevation on Card's and just roll your own box shadows for a similar effect, it is not so feasible to do so on most Material widgets (mostly buttons) that use elevation for shadow effects.

You also get this issue on WEB when you compile with the experimental:
flutter run --release --dart-define=FLUTTER_WEB_USE_SKIA=true -d Chrome

The default WEB rendering does not suffer from this issue.

@talamaska
Copy link
Contributor

Pardon me if I'm not understanding this right. I was just curious to see what's the deal about this harder shadows in the far right elements. I looked at the Material spec. I didn't find anything about the light being global. Shouldn't the elevation be per element with it's own light source? Am I missing something? Why @jvanverth says this is expected? In angular material this is not working like that. Every element has it's own shadow, independent of what is its position.

@bashtian
Copy link

In the guidelines two different light sources are mentioned:

In the Material Design environment, virtual lights illuminate the UI. Key lights create sharper, directional shadows, called key shadows. Ambient light appears from all angles to create diffused, soft shadows, called ambient shadows.
https://material.io/design/environment/light-shadows.html#light

Ambient light could be interpreted as global light. But since it's coming from all angles, the shadow should not differ (much?) on different screen sizes.
Key lights can only mean, one light per component, so it should not depend on the screen size.

@rydmike
Copy link
Contributor

rydmike commented Apr 30, 2020

I totally agree with you too @talamaska and @bashtian, on top of this the Flutter Web 'DomCanvas' does not create elevation shadows like this anymore either, it does it in a similar way to the angular Material style.

Clearly the current Flutter Skia implementation makes the shadows look silly on large screen sizes and it cannot really be the Material design teams intent. I think it is just an oversight in Flutter, since the implementation started from what worked well on phones and small screens, the difference is hard to notice on them, even if it is there. Currently the Flutter Material shadows start to look silly already on larger tablets.

@ferhatb ferhatb added the assigned for triage issue is assigned to a domain expert for further triage label May 14, 2020
@mariamhas mariamhas added the platform-web Web applications specifically label May 14, 2020
@yjbanov
Copy link
Contributor Author

yjbanov commented May 16, 2020

@mariamhas I am removing the web tag as this is a desktop and mobile issue. Web shadows are fine. This should somehow land on the C++ engine team's triage. @liyuqian how do we make this happen?

@yjbanov yjbanov added platform-android Android applications specifically platform-ios iOS applications specifically platform-linux Building on or for Linux specifically platform-mac Building on or for macOS specifically and removed platform-web Web applications specifically labels May 16, 2020
@willlarche
Copy link
Member

willlarche commented Sep 23, 2020 via email

@rydmike
Copy link
Contributor

rydmike commented Sep 23, 2020

Thanks @willlarche no problem.

Still I also agree with @talamaska and have to wonder if Flutter's current SKIA implementation of shadows cast by elevations is actually correct? This has been my concern since I first noticed this issue over a year ago.

We can certainly work around the situation on how poor elevation shadows currently look on large screens with Flutter Web Skia builds, large desktop builds and even on large Android/iOS tablet Flutter apps, by simply not using any elevation whenever it is possible to avoid it. Effectively just using flat designs and blur transparencies, basically a more Cupertino and Fluent Design system inspired style and approach.

I was reading through the beautiful Material Design guide again and in these two sections:
https://material.io/design/environment/elevation.html
https://material.io/design/environment/light-shadows.html#light

This particular paragraph does now mention the difference between Android and Web, can't say that I recall seeing it earlier:
https://material.io/design/environment/light-shadows.html#shadows

Shadows in the Material environment are cast by a key light and ambient light. In Android and iOS development, shadows occur when light sources are blocked by Material surfaces at various positions along the z-axis. On the web, shadows are depicted by manipulating the y-axis only.

While the Web and Android implementation difference is mentioned, it does not exactly say that the position of the elevated object on the canvas should affect its cast shadow. Although a consequence of using a proper z-axis implementation will result in this. The problem with the approach is, at least based on the currently visually observed results in Flutter's SKIA renderings, that a z-axis position that results in visually pleasing result for a small surface (phones) does not work so well for larger surfaces, it starts already at large tablets and gets more pronounced as the canvas size grows. The shadows just starts to look, well "not very attractive" and are thus not very usable.

I suspect that a part of what makes changing this behavior in Flutter tricky is that there is no single z-position for the lights that work well visually for all the needed canvas sizes. If so, this certainly complicates finding a working solution. I assume changing and adapting the light positions to dynamically changing canvas sizes, might be difficult and/or maybe costly processing wise.

Would love to hear, learn more and understand the challenges better.

As for the actual current end result, well visually elevations cannot really be used in flutter starting from large tablet sizes for any visually pleasing design result. Hence I don't think that the current implementation (right or wrong design spec wise) is viable as a long term solution for Flutter.

@willlarche
Copy link
Member

willlarche commented Sep 23, 2020 via email

@jvanverth
Copy link

After a brief discussion yesterday, I'll be adding a new interface to Skia that supports orthographic shadows, either by using a direction and elevation, or more directly by offset and blur radius. Flutter can then use this for desktop shadows. Tracking bug is here: https://skbug.com/10781

@willlarche
Copy link
Member

willlarche commented Sep 29, 2020 via email

@yjbanov yjbanov added ask: skia dependency: skia Skia team may need to help us labels Sep 29, 2020
@TahaTesser
Copy link
Member

code sample
import 'dart:ui';
import 'package:vector_math/vector_math_64.dart';

const Color _kShadowColor = Color.fromARGB(255, 255, 0, 0);
final Path shadowPath = Path()..addRect(const Rect.fromLTRB(0, 0, 20, 20));

Future<void> main() async {
  window.onDrawFrame = () {
    final SceneBuilder builder = SceneBuilder();

    void _paintPicture(Rect bounds, void Function(Canvas) painter) {
      final PictureRecorder recorder = PictureRecorder();
      painter(Canvas(recorder, bounds));
      builder.addPicture(Offset.zero, recorder.endRecording());
    }

    void _paintOutline() {
      _paintPicture(Rect.largest, (Canvas canvas) {
        canvas.drawRect(
          const Rect.fromLTRB(0.0, 0.0, 20.0, 20.0),
          Paint()
            ..color = const Color.fromARGB(255, 0, 0, 255)
            ..style = PaintingStyle.stroke
            ..strokeWidth = 1.0,
        );
      });
    }

    void _paintPhysicalShapeShadow(double elevation, Offset offset) {
      builder.pushOffset(offset.dx, offset.dy);
      builder.pushPhysicalShape(
        path: shadowPath,
        elevation: elevation,
        shadowColor: _kShadowColor,
        color: const Color.fromARGB(0, 0, 0, 0),
      );
      _paintOutline();
      builder.pop(); // physical shape
      builder.pop(); // offset
    }

    void _paintBitmapCanvasShadow(double elevation, Offset offset) {
      builder.pushOffset(offset.dx, offset.dy);
      _paintPicture(Rect.largest, (Canvas canvas) {
        canvas.drawShadow(
          shadowPath,
          _kShadowColor,
          elevation,
          true,
        );
      });
      _paintOutline();
      builder.pop(); // offset
    }

    _paintPicture(Rect.largest, (Canvas canvas) {
      canvas.drawColor(
          const Color.fromARGB(255, 255, 255, 255), BlendMode.color);
    });

    builder.pushTransform(Matrix4.diagonal3Values(5, 5, 1).storage);
    builder.pushOffset(10, 40);

    for (int i = 0; i < 7; i++) {
      _paintPhysicalShapeShadow(i.toDouble(), Offset(40.0 * i, 0));
    }

    for (int i = 0; i < 7; i++) {
      _paintBitmapCanvasShadow(i.toDouble(), Offset(40.0 * i, 80));
    }

    for (int i = 0; i < 7; i++) {
      _paintPhysicalShapeShadow(i.toDouble(), Offset(40.0 * i, 160));
    }

    builder.pushOffset(0.0, 240.0);
    _paintPicture(Rect.largest, (Canvas canvas) {
      for (int i = 0; i < 7; i++) {
        canvas.drawShadow(
          shadowPath,
          _kShadowColor,
          i.toDouble(),
          true,
        );
        canvas.drawRect(
          const Rect.fromLTRB(0.0, 0.0, 20.0, 20.0),
          Paint()
            ..color = const Color.fromARGB(255, 0, 0, 255)
            ..style = PaintingStyle.stroke
            ..strokeWidth = 1.0,
        );
        canvas.translate(40.0, 0);
      }
    });
    builder.pop(); // offset

    builder.pop();
    builder.pop();
    window.render(builder.build());
  };
  window.scheduleFrame();
}
flutter doctor -v
[✓] Flutter (Channel master, 1.24.0-4.0.pre.82, on Mac OS X 10.15.7 19H2
    darwin-x64, locale en-GB)
    • Flutter version 1.24.0-4.0.pre.82 at /Users/tahatesser/Code/flutter_master
    • Framework revision e5814756a2 (5 hours ago), 2020-10-27 01:47:03 -0700
    • Engine revision 1857470267
    • Dart version 2.11.0 (build 2.11.0-260.0.dev)

[✓] Android toolchain - develop for Android devices (Android SDK version 30.0.2)
    • Android SDK at /Users/tahatesser/Code/sdk
    • Platform android-30, build-tools 30.0.2
    • ANDROID_HOME = /Users/tahatesser/Code/sdk
    • Java binary at: /Applications/Android
      Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build
      1.8.0_242-release-1644-b3-6222593)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 12.1)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 12.1, Build version 12A7403
    • CocoaPods version 1.10.0.rc.1

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 4.1)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build
      1.8.0_242-release-1644-b3-6222593)

[✓] VS Code (version 1.50.1)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.15.1

[✓] Connected device (4 available)
    • Taha’s iPhone (mobile) • 00008020-001059882212002E • ios            • iOS
      14.1
    • macOS (desktop)        • macos                     • darwin-x64     • Mac
      OS X 10.15.7 19H2 darwin-x64
    • Web Server (web)       • web-server                • web-javascript •
      Flutter Tools
    • Chrome (web)           • chrome                    • web-javascript •
      Google Chrome 86.0.4240.111

• No issues found!

@TahaTesser TahaTesser added found in release: 1.24 Found to occur in 1.24 has reproducible steps The issue has been confirmed reproducible and is ready to work on labels Oct 27, 2020
@yjbanov yjbanov added the platform-web Web applications specifically label Oct 30, 2020
@kf6gpe kf6gpe removed the ask: skia label Dec 4, 2020
@yjbanov yjbanov moved this from Open to In Progress in CanvasKit issues Dec 9, 2020
@yjbanov yjbanov self-assigned this Jan 6, 2021
@yjbanov yjbanov removed e: web_canvaskit CanvasKit (a.k.a. Skia-on-WebGL) rendering backend for Web platform-web Web applications specifically labels Jan 13, 2021
@yjbanov
Copy link
Contributor Author

yjbanov commented Jan 13, 2021

Removing the web labels as the web parts have been fixed as of flutter/engine#23459

@xster xster added the a: tablet Tablets and landscape phones label Jan 19, 2021
@yjbanov yjbanov removed their assignment Feb 24, 2021
@yjbanov
Copy link
Contributor Author

yjbanov commented Feb 24, 2021

I fixed the web parts. Unassigning for now as I won't be able to get to the non-web implementation in the near future. If anyone else is interested, feel free to take this.

/cc @gspencergoog @goderbauer @cbracken feel free to reprioritize based framework/desktop needs. I made it a P3 based on web priorities.

@rydmike
Copy link
Contributor

rydmike commented Apr 20, 2021

@yjbanov What is the status of this issue?
The SKIA case show it as fixed and landed in Flutter. Is that so?
https://bugs.chromium.org/p/skia/issues/detail?id=10781

CanvasKit issues automation moved this from In Progress to Closed Jul 17, 2021
@TahaTesser TahaTesser added the r: fixed Issue is closed as already fixed in a newer version label Jul 21, 2021
@github-actions
Copy link

github-actions bot commented Aug 4, 2021

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Aug 4, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
a: desktop Running on desktop a: tablet Tablets and landscape phones c: rendering UI glitches reported at the engine/skia rendering level customer: house dependency: skia Skia team may need to help us engine flutter/engine repository. See also e: labels. found in release: 1.24 Found to occur in 1.24 has reproducible steps The issue has been confirmed reproducible and is ready to work on P1 High-priority issues at the top of the work list platform-android Android applications specifically platform-ios iOS applications specifically platform-linux Building on or for Linux specifically platform-mac Building on or for macOS specifically platform-windows Building on or for Windows specifically r: fixed Issue is closed as already fixed in a newer version
Projects
Development

Successfully merging a pull request may close this issue.