I was looking at whether or not this could be an easy fix, but I'm having a heck of a time getting this running locally. if I try and run via flutter run -d macos -t test/render_test.dart after adding a macos folder, all I get is:

flutter: ════════════════════════════════════════════════════════════════════════════════════════════════════
flutter: ══╡ EXCEPTION CAUGHT BY WIDGETS LIBRARY ╞═══════════════════════════════════════════════════════════
flutter: The following assertion was thrown building TileMap(dirty):
flutter: 'package:tiler/src/painter.dart': Failed assertion: line 50 pos 16: '_loadedMap != null': is not
flutter: true.
flutter: 
flutter: The relevant error-causing widget was:
flutter:   TileMap TileMap:file:///Users/jonahwilliams/Documents/tests/tests/test/utils.dart:38:28

@DanTup do you have a specific workflow that needs to be followed to get these goldens to show up locally?

So I'd recommend switching to FilterQuality low rather than none.

@bsalomon I made this change and it didn't seem to alter the goldens on my Mac. Trying on Windows, the results seem much fuzzier (although the docs suggest Low is better quality than None):

Is this expected?

@jonahwilliams all I'm doing is running flutter test and flutter test --update-goldens

Yeah, I was trying to run on an actual device in order to see what a device with a GPU outputs. To make this work, I had to change all of the loader calls to use rootBundle.load, to avoid the flutter_test specifici overriden asset manager. i will file a bug for this later on.

I'm unblocked for now

I've pushed the changes. It does seem like there's no difference now between master and this PR, so (as long as I tested it correctly), I think it should be unblocked now (fixes are DanTup/tiler@380769c and DanTup/tiler-test-maps@6010729).

I'm not around too much longer today (it's getting late here) but if any failures relating to this seem like just issues with Tiler's tests and not Flutter, feel free to remove it from the Flutter customer testing (we can add it back if useful later). Otherwise, Jonah and Jason both have access to the repos and are welcome to commit changes/goldens as required to fix.

(I'll try to check back shortly before I vanish for the night though)

I'm surprised on mac you get the issue on mac and then it doesn't get blurry when you make the change. I'd expect if the sample point was near an integer you'd now get a ~50/50 blend of the two adjacent pixels. I can take a look if someone points me to the instructions for running.

AFAIK all of the numbers should've been integers, so I wasn't expecting any scaling at all (I'm also not sure why things changed on Windows and not Mac.. both are just running flutter test which I presume is using the same rendering code?).

You should be able to just clone https://github.com/DanTup/tiler (inc submodules) and run flutter test with whatever version of Flutter.

I just realised I didn't subit the new commit hash to flutter/tests, but as I type this I see @jonahwilliams has beaten me at flutter/tests#173 :)

Thanks for the pointer. I'll take a look to confirm we haven't introduced a bug in Skia.

By default I believe flutter_tester has a 3.0 device pixel ratio, so (if I did my math) right any integer device pixel should become an integer physical pixel. but if there are any parent transforms, offset layers, scrolling, then that can change whether or not that correspondance actually works for an app developer

Ahh, actually that test in particular has a 0.25 scale applied to it. I think that will break the pixel alignment:

https://github.com/DanTup/tiler/blob/master/test/render_test.dart#L18

unless that is acounted for elsewhere?

The sampling works backwards from device space points at half values. That is the device space coords used to shade the top left device pixel are (0.5, 0.5).

While looking at the code, I realised that I only ever committed Windows goldens (because I was using Windows at the time and couldn't easily create the goldens for other platforms). So when I said it didn't happen on Mac, I guess what I really meant was "the tests skip the golden checks on Mac" 🙈

Ahh, actually that test in particular has a 0.25 scale applied to it.

Ah, good spot 😄 It's been a while since I did this.

AFAIK all of the numbers should've been integers, so I wasn't expecting any scaling at all (I'm also not sure why things changed on Windows and not Mac.. both are just running flutter test which I presume is using the same rendering code?).

One difference between Windows and other platforms is that they fully embrace non-integer DPIs. Mac will pretty much always be 2.0 or 1.0. Many phones are integer DPI, but Windows is fond of 2.25 and 1.75 and other non-integer ratios because they've had to embrace a wide range of monitors designed by a wide range of manufacturers and wanted to achieve very consistent sizing across the board.

I'm trying to double check that this change didn't do anything unanticipated. I'm on a Mac. I built the engine for desktop. And then I run:
flutter --local-engine="host_debug_unopt" test
I get:
00:04 +15: All tests passed!

@bsalomon turns out I wasn't committing the goldens on mac. I'll create a branch now with the older goldens produced on a Mac so you can easily run this and verify the difference.

@bsalomon if you checkout the mac-testing branch it now has goldens enabled for macOS and committed from Flutter master (you may need to git submodule init?) and if you run flutter test you should get a number of failures as noted in #114997 (comment).

Note: I changed the FilterQuality back to none for this testing as it seemed like that's what you were testing. If you set it to low then there are no differences between stable and latest master, but the quality is worse (some of the images are blurry, even though they aren't for none, and the docs suggest low is better quality that none?).

Note: I changed the FilterQuality back to none for this testing as it seemed like that's what you were testing. If you set it to low then there are no differences between stable and latest master, but the quality is worse (some of the images are blurry, even though they aren't for none, and the docs suggest low is better quality that none?).

There are very specific circumstances in which none might look better. Some of these images may be running into those. Note that if you animate anything then none will look jittery even though any given frame might look "crisper" when taken out of context in isolation. low will look smooth in motion, but any given frame might be less crisp than a none rendering.

@bsalomon I made this change and it didn't seem to alter the goldens on my Mac. Trying on Windows, the results seem much fuzzier (although the docs suggest Low is better quality than None):

I had confused myself in thinking the original issue was showing up on Mac but now I realize it was Windows. Now these results make perfect sense . Mac is sampling the image at image pixel center so none vs low makes no difference. Windows is hitting at an integer so when sampling was none we changed the snapping and made a gap and on low you get blurriness because you're getting a 50% blend of two rows. I don't think there is really anything to do here. We were already on the knife's edge and on an actual GPU you could have gotten the gap before anything in Flutter Engine changed recently.

@bsalomon I'm a little confused. The issue* does seem to show up on Mac for me - however Tiler's repo was skipping the golden checks for (host) platforms other than Windows (because I wasn't able to easily update the goldens on other platforms) so it only triggered on Windows when running the tests.

• by "issue" here I mean the original reason for this failure, which is that the produced goldens changed in this roll (when using FilterQuality.none, on both Windows and macOS, running on flutter-tester just using flutter test).

The branch I noted above removes the isWindows check and commits Mac goldens for the current Flutter stable. If I checkout that branch and run them on my Mac, I see failures because of golden changes.

On master I've now switched to low, which seems to provide consistent results before/after this roll - although the quality of the rendering is worse for this purpose IMO. If I was still maintaining/releasing that package I'd probably do some comparison of those values to decide which looks best (the original none looked great and wasn't at all fuzzy, but low is very fuzzy).

The fuzziness is due to a 0.25 scale. As you scale down a picture, you'd expect the thin lines in the original to get fainter and harder to see. By the time it is scaled down by 4x you'd expect fuzzy lines. If this picture were rendered at full scale the lines would likely not be fuzzy at all. If it was intended to be rendered at this tiny scale, then the lines should have been larger to compensate.

Can you imagine what a rendering would look like where as you scaled it down across 4x the lines stayed as bold as they were in the original rendering despite all of the other details of the image reducing in size? That would be a quality issue...

The fuzziness is due to a 0.25 scale. As you scale down a picture, you'd expect the thin lines in the original to get fainter and harder to see.

I understand, but it was being scaled exactly the same before this change. It just feels like the quality become a lot worse. Here's a comparison (left is stable, right is master after this change landed - there are no changes at all in the Tiler code):

There's also a slight artifact above the 3rd/clipped character which I think is pixels bled from the sprite above it in the spritesheet.

To be clear, I'm not saying these are issues/bugs, and they may easily be fixed/improved by tweaking my code (although I'm not actively developing that package). I just wanted to make sure the differences are understood (and expected or acceptable) :-)

The bleeding shouldn't be there, that is probably related to the rounding fix that Skia is landing.

These results are to be expected for low. They look bad in these examples because they are so specifically tailored for the few cases where none looks good. Across the spectrum of what you might do with images, none will show problems that make a little fuzziness look like a dream in comparison.

• by "issue" here I mean the original reason for this failure, which is that the produced goldens changed in this roll (when using FilterQuality.none, on both Windows and macOS, running on flutter-tester just using flutter test).

Sorry, by "issue" I was referring only to the row of undesired pixels above the one character with none, not any change to the goldens. I saw that bad pixel row in your original zip on the windows image but not when I ran the tests on my Mac.

Are the characters coming from an image atlas? I'm wondering if you could keep the sharpness of none (with the possible jerkiness pointed out by @flar) by adjusting the image rect used to draw and ensuring there is always a transparent row/column between atlas entries.

@flar

These results are to be expected for low.

Oh, I confused things above. The diff I posted was the change from none to low, and not this roll. The changes in this roll did not make things fuzzy while still using none:

@bsalomon

Are the characters coming from an image atlas? [...] adjusting the image rect used to draw and ensuring there is always a transparent row/column between atlas entries.

Yes, but the tileset is from an external source and the info about the sizes comes from the Tiled editor so not someting that can be changed (although to be clear, I'm not concerned here about specific issues relating to these tests - these are just tests, I only highlighted it in case it was unexpected behaviour that might affect others).

In Skia we have a concept of a sampling "constraint" on drawImageRect. If it is "strict" then it guarantees that the image won't be sampled outside of the src rectangle. I'm not sure if that is exposed in flutter. I don't see an equivalent here:

https://api.flutter.dev/flutter/dart-ui/Canvas/drawImageRect.html

However, I do see references to it in the Flutter Engine code.

In Skia we have a concept of a sampling "constraint" on drawImageRect. If it is "strict" then it guarantees that the image won't be sampled outside of the src rectangle. I'm not sure if that is exposed in flutter. I don't see an equivalent here:

https://api.flutter.dev/flutter/dart-ui/Canvas/drawImageRect.html

However, I do see references to it in the Flutter Engine code.

Hard-coded to Fast here:

https://github.com/flutter/engine/blob/05649893f75f4390b883bdb287d670db5449e024/lib/ui/painting/canvas.cc#L440

Interesting - should I file an issue for exposing this? I'm not currently maintaining this library so it's not of importance to me, but perhaps it should be available in case others are trying to do something similar?

Interesting - should I file an issue for exposing this? I'm not currently maintaining this library so it's not of importance to me, but perhaps it should be available in case others are trying to do something similar?

#67881

Ah, nice - thanks! 😃