GNOME Bugzilla – Bug 747446
Fix HiDpi rendering
Last modified: 2015-11-03 18:14:03 UTC
Created attachment 301065 [details] screenshot I get this square artifact on all my photos, where the spinner have been
Yes, I have seen it too. Something wrong with the drawing in our preview widget.
Is this something that you see more commonly on a HiDpi display? At least that seems to be the case for me. Anyway, I have a few fixes to gegl-gtk that should make the rendering more robust and prevent these problems. I will attach some patches shortly.
Yes, mostly on the laptop with the HiDPI screen. Maybe I've seen it on the other laptop too, but I'm not sure.
Created attachment 314640 [details] [review] gegl-gtk-view, gegl-gtk-view-helper: Fix HiDpi rendering This turned out to be easier than I thought. We weren't taking the scale factor into account when rendering on HiDpi, so you would often see that the image is hazier than it looks on Eye of GNOME. Also HiDpi screenshots would be rendered at a larger size on a HiDpi display (which, by the way, is also a problem in eog). Things should now look sharper and HiDpi screenshots should look like the HiDpi widgets. Anyway, fixing the rendering on HiDpi seems to have magically fixed the square artifacts too. I guess we were introducing some rounding error when rendering to a 1x1 cairo surface at a lower zoom and then upscaling to a 2x2 window.
Comment on attachment 314640 [details] [review] gegl-gtk-view, gegl-gtk-view-helper: Fix HiDpi rendering Pushed to master.
I tested it out on a LoDpi system today (the patch was written on HiDpi), and it worked as expected. I am still not sure how this could have fixed the square artifacts, but it definitely improves things on HiDpi displays - sharper previews, and HiDpi screenshots are shown at the widget sizes. However, my initial plan with respect to the square artifacts [*] still stands. Currently, we (ie. our internal copy of gegl-gtk) always do a gegl_node_blit for the clip rectangle set on the Cairo context that is passed to the draw vfunc. I think, the safer (and faster?) thing to do would be to blit the entire GeglNode to a Cairo image surface, whenever the graph or the size of the widget changes, and re-use it on successive draws relying on the Cairo clip rectangle to take care of the clipping. That should avoid all the rectangle computation, which is probably where the bug that causes the artifacts is. As a nice side-effect, we would be blitting the node much less. [*] I have seen them when running the gegl-gtk tests/examples on HiDpi.
(In reply to Debarshi Ray from comment #6) To summarize today's discussion in #gegl on GIMPNet ... > However, my initial plan with respect to the square artifacts [*] still > stands. > > Currently, we (ie. our internal copy of gegl-gtk) always do a gegl_node_blit > for the clip rectangle set on the Cairo context that is passed to the draw > vfunc. I think, the safer (and faster?) thing to do would be to blit the > entire GeglNode to a Cairo image surface, whenever the graph or the size of > the widget changes, and re-use it on successive draws relying on the Cairo > clip rectangle to take care of the clipping. > > That should avoid all the rectangle computation, which is probably where the > bug that causes the artifacts is. As a nice side-effect, we would be > blitting the node much less. > > [*] I have seen them when running the gegl-gtk tests/examples on HiDpi. Obviously this comes at a constant memory cost, and it won't work with large images at high zoom levels. However, that is not an issue with gnome-photos because we don't let the user zoom to arbitrarily high zoom levels and we probably don't need to because we are not gimp. So, worst comes to worse and we can't figure out where the co-ordinate calculation is going wrong, we can still do it. Regarding performance ... Lately pippin has been trying to speed up gegl_node_blit even more, so we need to profile how an even faster [*] gegl_node_blit compares with caching the Cairo surface. [*] Note that blitting on gegl-0.3 is generally faster than in 0.2, and using "cairo-ARGB32" as the Babl format has sped it up even more. So, performance-wise, things are already much better than they used to be.
From #gnome-hackers on GIMPNet: 17:49 <andreasn> rishi: finally built the right version. Now on 3.19.1 and the artifact is gone! 17:49 <andreasn> \o/ 17:49 <andreasn> thanks for the fix!
Also pushed to gnome-3-18.