With the opengl option disabled thin lines are smooth and neat at any zoom level, but if I rotate the viewport everything is terribly aliased. With the opengl option enabled thin lines are aliased in any situation instead. I experienced the same problem with the proprietary Nvidia driver and with the free nouveau driver, so I tried to force the anti-aliasing by the Nvidia x server setting panel but it doesn't work. I tested it with a Geforce 9500 GT. For instance under Mypaint I don't experience such problems with/without the rotated viewport at any zoom level and Mypaint takes advantage of display hardware acceleration through the Cairo library for zooming and rotating, so my graphic card should be ok... :) It's a big problem for inking and creating line-art, because the user is forced to switch to the "software" mode to see the result of his work and he can't rotate the viewport without the aliasing curse. ;D Reproducible: Always Actual Results: Expected Results:
Hm, I don't see any aliasing when using opengl, but a thin straight line at 100% zoom rotated two clicks to the right in the qpainter canvas does show aliasing. I'm using an intel graphics card here (I think...)
Created attachment 71139 [details] left qpainter, right opengl
Git commit 24ce177b7225eb83378b65821b10fe32d45a0a25 by Boudewijn Rempt. Committed on 16/05/2012 at 16:09. Pushed by rempt into branch 'master'. Antialias when painting a rotated canvas I'm not sure that this doesn't close the bug yet -- opengl canvas anti- aliasing is graphics card dependent. But I'll ask around for some tips since I'm not an opengl expert (at all). M +2 -0 krita/ui/canvas/kis_qpainter_canvas.cpp http://commits.kde.org/calligra/24ce177b7225eb83378b65821b10fe32d45a0a25
(In reply to comment #1) > Hm, I don't see any aliasing when using opengl, but a thin straight line at > 100% zoom rotated two clicks to the right in the qpainter canvas does show > aliasing. I'm using an intel graphics card here (I think...) I've an Intel graphic chipset integrated in my motherboard, I could try it to see the difference...
I'd be really interested in the results!
Created attachment 71144 [details] Thin Lines Test with/without OpenGL Enabled
Same problem with the Intel card... I've just taken a screenshot to show the difference... Please, look the attachment... ^^
Weird... Could you attach the document as well?
Created attachment 71147 [details] Thin Lines Test for OpenGL Please, look at it with a zoom factor <= 33% and with OpenGL enabled and disabled.
I've just attached a new one, because I didn't save the old one. ^^(In reply to comment #8) > Weird... > > Could you attach the document as well? I've just attached a new one, because I didn't save the old one. ^^
Er... weird: ahiemstra just committed a possible fix and tagged the commit, but nothing is attached here.
Git commit 988dcefeaf90809356db5932d8d6407802259c8a by Arjen Hiemstra. Committed on 16/05/2012 at 19:31. Pushed by ahiemstra into branch 'master'. Set the right filtering modes for rendered textures when using OpenGL. Now use nearest for near filtering and trilinear filtering for fa filtering. This prevents aliassing issues at low zoom levels and still gives the right behaviour at high zoom levels. BUG: 300138
Yes, the commit works! ^^ Although a little problem arises... When I turn on the OpenGL feature everything painted on the canvas disappears, so I've to hide and unhide the levels to force the refreshing. After that Krita works regularly.
That sounds strange -- I wonder whether that wasn't always present. The opengl commit (988dcefeaf90809356db5932d8d6407802259c8a) cannot have anything to do with that, I'd say.
Hmm, from the looks of it, it seems it is actually more a bug in the underlying system that is exposed by my changes. For some reason, the texture data is not updated when OpenGL is enabled, so it does not generate mipmaps properly which are needed for trilinear filtering. I will take a look and see if I can find out what's causing it.
(Where's an edit button when you need one...) Just realised the actual problem: Textures are generated, data is uploaded and only after that is set that it also needs to generate mipmaps - which it does not do directly since none of the data changed... Well I already thought most of the commands in that bit of code don't belong there, but this just confirms it.
Git commit a9a08a81059b2c71b8cce2a7356e5482a72b4cae by Arjen Hiemstra. Committed on 18/05/2012 at 01:25. Pushed by ahiemstra into branch 'master'. Set texture parameters before uploading any texture data. This avoids needlessly resetting the texture parameters and also makes sure we always generate mipmaps, since those are required by the new trilinear filtering. M +0 -5 krita/ui/opengl/kis_opengl_canvas2.cpp M +4 -0 krita/ui/opengl/kis_texture_tile.cpp http://commits.kde.org/calligra/a9a08a81059b2c71b8cce2a7356e5482a72b4cae
I've just tested it... The commit works perfectly. Thanks. :)
Great! Closing the bug then :-)
Okay, we're not here yet... On some hardware, the new opengl code breaks the canvas, and the qpainter smoothing should probably be off while panning, moving, rotating etc., since it's slowing down everything. See also https://bugs.kde.org/show_bug.cgi?id=300339.
Only 300339 is still relevant now.