Bug 313502

Created attachment 76562 [details]
zoom bug- lines while painting first

Created attachment 76563 [details]
zoom bug- lines while painting first then undo

Created attachment 76564 [details]
zoom bug- draw lines then zoom in-out

I think this is the same bug as bug 289915.

@Dmitry : bug 289915 have indeed similarities.

*** Bug 289915 has been marked as a duplicate of this bug. ***

Created attachment 82638 [details]
2013-October : Mypaint VS Azdrawing VS Krita render at 33% viewport

A screenshot in attachement to update actual state I meet here.

Created attachment 82639 [details]
the 'eye' file test , a file to test rendering of inked line-art

Report of my last discovery on the OpenGL rendering  ( reading and tweaking and recompiling krita/ui/openGL/kis_texture_tile.cpp , and reading a bit online Opengl doc ) 

1) In 'Bilinear' mode aka "GL_LINEAR", the drawing method is replaced by 'nearest neighboors' aka "GL_NEAREST" when the zoom is inferior to 50% ( ex: 49% rendering is same for both, but not at 50% ).  That explain the crunchy aspect of Bilinear at 25% and 33%. Because the filter fallback to "GL_NEAREST" for unknown reason. Bug ? When it works,  'Bilinear' is my favorite option , even rotated/flipped...etc 

2) Actual 'Trilinear' aka 'GL_LINEAR_MIPMAP_LINEAR' is too blury at any zoom.  Ex: at 25% http://i.imgur.com/g2fPf4m.jpg , but if you use the rendering "GL_NEAREST_MIPMAP_LINEAR" (l.60) it makes a better rendering for the 'pure' zoom : 50%, 25%, 12%, in page with Gimp and Mypaint canvas rendering ( but all zoom level in between are garbage , even 33%, 67% etc... ) .  Ex: at 25% http://i.imgur.com/XwJ3CHV.jpg . it would be nice if all 50%, 25%, 12% zoom could be rendered with "GL_NEAREST_MIPMAP_LINEAR" , and all other value in-betwwen fallback to the blury 'GL_LINEAR_MIPMAP_LINEAR' method.

Tested on Nvidia proprietary driver.

Additionnal test done now on Intel HD gfx card :
1) In 'Bilinear' mode aka "GL_LINEAR" got similar bug than on Nvidia. When the zoom is inferior to 50% the rendering on screen is similar to "GL_NEAREST" aka  'nearest neighboors'.

2)  'Trilinear' aka 'GL_LINEAR_MIPMAP_LINEAR' do not differ. Exept for the cool result I found if I switch to "GL_NEAREST_MIPMAP_LINEAR" ; the 50% is now garbage and 25%, 12% are best rendering. 

---

=> to resume both experiments for best openGL rendering on both :
* from 0 to 50%   ->  "GL_LINEAR"
* from 50% to 26% -> "GL_LINEAR_MIPMAP_LINEAR"
* 25% ->  "GL_NEAREST_MIPMAP_LINEAR"
* from 23% to 13% -> "GL_LINEAR_MIPMAP_LINEAR"
* 12% ->  "GL_NEAREST_MIPMAP_LINEAR"
* from 11% to minimal -> "GL_LINEAR_MIPMAP_LINEAR"

Created attachment 83015 [details]
experimental patch that uses a quadratic filter to scale

This patch adds filtered scaling code from qimageblitz to the qpainter canvas. There's also some commented-out code to save the image scaled to 33% using all the available filters... I'll upload a .kra that show the result with the eye image for each scaling method.

Created attachment 83016 [details]
comparison of all scaling methods

Sorry for my handwriting...

*** Bug 276278 has been marked as a duplicate of this bug. ***

Git commit a970b3b3efce17aeb613253a117910165ca20258 by Dmitry Kazakov.
Committed on 30/10/2013 at 07:35.
Pushed by dkazakov into branch 'krita-testing-kazakov'.

Added an option for High Quality image downsampling for OpenGL canvas

1) This option activates a custom shader, which filters the image
   with a variation of trapezoidal filter using "one-but-nearest"
   mipmap level. This gives quite decent results, although it might
   be not perfect from the maths point of view.

2) The patch also sets the default texture size to 256. Otherwise
   activation of mipmap generation will make the painting with smaller
   brushes insanely slow. This happens because the mipmap is regenerated
   for the whole texture every time we change a small portion of it.

M  +5    -3    krita/data/shaders/CMakeLists.txt
D  +0    -10   krita/data/shaders/display.frag
A  +72   -0    krita/data/shaders/highq_downscale.frag
C  +5    -3    krita/data/shaders/matrix_transform.vert [from: krita/data/shaders/gl2.vert - 067% similarity]
R  +0    -0    krita/data/shaders/matrix_transform_legacy.vert [from: krita/data/shaders/gl2.vert - 100% similarity]
A  +12   -0    krita/data/shaders/simple_texture.frag
R  +0    -0    krita/data/shaders/simple_texture_legacy.frag [from: krita/data/shaders/checker.frag - 100% similarity]
M  +5    -0    krita/image/kis_signal_compressor.cpp
M  +1    -0    krita/image/kis_signal_compressor.h
M  +8    -0    krita/sdk/tests/testutil.h
M  +5    -0    krita/ui/forms/wdgdisplaysettings.ui
M  +15   -0    krita/ui/kis_config.cc
M  +4    -0    krita/ui/kis_config.h
M  +5    -0    krita/ui/opengl/kis_opengl.cpp
M  +2    -0    krita/ui/opengl/kis_opengl.h
M  +61   -29   krita/ui/opengl/kis_opengl_canvas2.cpp
M  +4    -3    krita/ui/opengl/kis_opengl_image_textures.cpp
M  +5    -0    krita/ui/opengl/kis_opengl_image_textures.h
M  +6    -21   krita/ui/opengl/kis_texture_tile.cpp
M  +1    -3    krita/ui/opengl/kis_texture_tile.h

http://commits.kde.org/calligra/a970b3b3efce17aeb613253a117910165ca20258

@ Dmitry Kazakov : I tested your filter, high quality. Really cool result , congratz !  I already enjoyed a fast sketch with :) http://i.imgur.com/Ys49fsb.jpg. I can't test it on production artwork to really evaluate the performance because Bug 326671 break my *.ora workflow on all updated branch and master. But I'm enthusiast to paint with it more ! this is a big step for general quality of Krita imo.  ( Note: I also saw in case of crash, Krita auto-switch to Qpainter canvas at next start )

Ok, this bug seems to have become a mixture of OpenGL and CPU canvas issues. Now I'll close this bug (since we were talking on openGL here mostly) and will reopen bug 289915, since CPU canvas has really subtly artifacts due to simplified scaling.

As a general note, please use openGL canvas in your production workflow.