Obsolete
Status Update
No update yet.
Comments
co...@gmail.com
View the fiddle on a retina monitor, the issue stands out even further.
Oddly not seeing this as bad in latest Chrome, was this a regression or is there a solution to smooth things out that is used by Chrome?
Oddly not seeing this as bad in latest Chrome, was this a regression or is there a solution to smooth things out that is used by Chrome?
hc...@google.com
It's been several months since the changes I was aware of to improve linear gradient quality- Florin, have you or others changed anything recently? Over to you for ownership of this one...
fm...@chromium.org
Skia's gradients support dithering, but that must be requested via SkPaint::setDither(): https://fiddle.skia.org/c/901324b3cb857a5a59e8675a86195975
(I think Chrome/Blink always requests dithering, hence the smoother results)
Can you verify that dithering fixes your issue?
(I think Chrome/Blink always requests dithering, hence the smoother results)
Can you verify that dithering fixes your issue?
co...@gmail.com
It seems to improve things a bit on non-retina but on retina monitor the banding persists.
co...@gmail.com
Also if you zoom in (with your bitmap zoomer of choice) on your fiddle results, you'll see the GPU version does a better job at honoring the dithering..not so much on CPU (we're using CPU).
co...@gmail.com
[Comment Deleted]
co...@gmail.com
The retina monitor banding on the fiddle might just be FOL. The dithering for sure helps... should it be the default by chance?
mt...@google.com
We can't really change defaults without breaking all other clients.
fm...@chromium.org
Interesting that dithering doesn't help much on retina. FWIW we've had weird issues with iDisplays before -- there's a Chrome bug where some MBP displays start flickering when we enable cpu dithering :)
I think we use a fixed 2x2 dither cell for the CPU backend, while the GPU is likely doing something fancier - so it isn't surprising that Ganesh looks better under a magnifier.
Not sure about dither-by-default: I guess it's a question of whether the SkPaint flag should default to true. At least for cpu gradients it doesn't cost anything, but don't know about gpu or other code paths. And as Mike said, it may surprise existing clients.
I think we use a fixed 2x2 dither cell for the CPU backend, while the GPU is likely doing something fancier - so it isn't surprising that Ganesh looks better under a magnifier.
Not sure about dither-by-default: I guess it's a question of whether the SkPaint flag should default to true. At least for cpu gradients it doesn't cost anything, but don't know about gpu or other code paths. And as Mike said, it may surprise existing clients.
co...@gmail.com
Cool, I just meant the gradient shader's fDither default to true, looks like it use to long ago, but yeah makes sense.
Thanks for the help.
Thanks for the help.
hc...@google.com
[Empty comment from Monorail migration]
Description
What steps will reproduce the problem?
1. Render a 500x500 linear gradient via SkLinearGradient shader from #656565 to #808080.
2. Resulting image contains many visible "bands".
What is the expected output? What do you see instead?
Hopefully no banding. See attached image, on left is another tool, while some banding exists, the right hand side of the image (as rendered with Skia/M53) has noticeable bands.
What version of the product are you using? On what operating system?
M53
Please provide any additional information below.