RESOLVED FIXED 205444
[GTK][WPE] Wrong visualization of Conic gradients in high resolution displays
https://bugs.webkit.org/show_bug.cgi?id=205444
Summary [GTK][WPE] Wrong visualization of Conic gradients in high resolution displays
Diego Pino
Reported 2019-12-19 02:42:49 PST
Created attachment 386091 [details] Conic gradient test 400x400 (taken from https://leaverou.github.io/conic-gradient/). Contains html code and visualizations in hi-res and lo-res displays. There's a bug in https://trac.webkit.org/changeset/253685 when a Conic gradient is displayed in a high resolution display (i.e 3840x2160). In such displays, a conic-gradient like in the example attached shows a clear separation between sections. However, in a low resolution display (i.e 1360x768) the conic-gradient shows just fine.
Attachments
Conic gradient test 400x400 (taken from https://leaverou.github.io/conic-gradient/). Contains html code and visualizations in hi-res and lo-res displays. (100.30 KB, application/gzip)
2019-12-19 02:42 PST, Diego Pino
no flags
Patch (2.16 KB, patch)
2019-12-19 02:53 PST, Diego Pino
no flags
Patch (2.02 KB, patch)
2019-12-19 10:05 PST, Diego Pino
no flags
Patch (2.73 KB, patch)
2019-12-19 10:50 PST, Diego Pino
no flags
Patch (2.73 KB, patch)
2019-12-20 00:18 PST, Diego Pino
no flags
Diego Pino
Comment 1 2019-12-19 02:53:29 PST
Carlos Alberto Lopez Perez
Comment 2 2019-12-19 09:34:55 PST
Comment on attachment 386092 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=386092&action=review > Source/WebCore/platform/graphics/cairo/GradientCairo.cpp:86 > + const double pixelWidth = 0.1; I find confusing this variable name. Its the width of a pixel 0.1?? maybe pixelSeparationWidth is a better name? Also I think its worth adding a comment about why this is needed (because at high resolution a white line appears) > Source/WebCore/platform/graphics/cairo/GradientCairo.cpp:99 > + cxOffset = 0 * pixelWidth; > + cyOffset = -1 * pixelWidth; > } else if (from.offset >= 0.25 && from.offset < 0.50) { > - cxOffset = 0; > - cyOffset = 0; > + cxOffset = 0 * pixelWidth; > + cyOffset = 0 * pixelWidth; > } else if (from.offset >= 0.50 && from.offset < 0.75) { > - cxOffset = -1; > - cyOffset = 0; > + cxOffset = -1 * pixelWidth; > + cyOffset = 0 * pixelWidth; > } else if (from.offset >= 0.75 && from.offset < 1) { > - cxOffset = -1; > - cyOffset = -1; > + cxOffset = -1 * pixelWidth; > + cyOffset = -1 * pixelWidth; > } else { Instead of doing this, perhaps it will be clear to do the multiplication below only once? cx = cx + cxOffset * pixelWidth; cy = cy + cyOffset * pixelWidth;;
Carlos Alberto Lopez Perez
Comment 3 2019-12-19 09:35:45 PST
I also wonder if its possible to write a regression test for this? can the current behaviour be triggered at low resolutions like the one used for layout tests? (i think its 800x600)
Diego Pino
Comment 4 2019-12-19 10:05:03 PST
Diego Pino
Comment 5 2019-12-19 10:12:14 PST
I only managed to reproduce this issue when displaying the gradient in a high resolution monitor. I didn't manage to trigger this issue on a low resolution display, even trying different sizes for the gradient (3000x3000, 800x800). In conclusion, I think it's going to be hard to have a test for this issue considering LayoutTests run on a 800x600 window.
Diego Pino
Comment 6 2019-12-19 10:50:01 PST
Diego Pino
Comment 7 2019-12-20 00:18:35 PST
Carlos Alberto Lopez Perez
Comment 8 2019-12-20 06:19:27 PST
Comment on attachment 386186 [details] Patch r=me
WebKit Commit Bot
Comment 9 2019-12-20 08:10:16 PST
Comment on attachment 386186 [details] Patch Clearing flags on attachment: 386186 Committed r253817: <https://trac.webkit.org/changeset/253817>
WebKit Commit Bot
Comment 10 2019-12-20 08:10:18 PST
All reviewed patches have been landed. Closing bug.
Radar WebKit Bug Importer
Comment 11 2019-12-20 08:11:20 PST
Note You need to log in before you can comment on or make changes to this bug.