When OpenGL High Quality Filter is ON, tablet drawing becomes extremely slow. Mouse drawing is not affected. Switching to Trilinear Filter brings back the performance. It was OK in revision e2ff0e5a. I'm using a Nvidia GTS250. I cannot test this issue against intel driver because 1st gen intel HD Graphics does not support OpenGL3.x. Reproducible: Always Steps to Reproduce: 1. OpenGL ON 2. High Quality Filter selected 3. Draw a stroke using a tablet Actual Results: Krita draws the stroke extremely slow. Expected Results: Krita draws the stroke as fast as it's using Trilinear filter. Trisquel GNU/Linux 6.0 Qt 4.8.2 KDE 4.12.2 Calligra/2.8 branch rev 12b48e61
Hi, Tyson! Could you try revertion of the commit 6ae0e9f347d66cf3b612f58e? Does it help you? to check you need to do the following line in src directory: git revert 6ae0e9f347d66cf3b612f58e After testing, to get back to calligra/2.8 branch: git reset --hard origin/calligra/2.8
Hi Dmitry, I tried to revert using $ git revert 6ae0e9f347d66cf3b612f58e But it returns: error: could not revert 6ae0e9f... krita: Look up the function pointers for the sync functions and use those hint: after resolving the conflicts, mark the corrected paths hint: with 'git add <paths>' or 'git rm <paths>' hint: and commit the result with 'git commit'
Hi Dmitry, I did some research and used git reset --hard instead of git revert. git reset --hard 79643acb still slow git reset --hard 79643acb still slow git reset --hard 7a3fdb9a things returned to normal
Hm, I could imagine that Arjen's commit commit 6ae0e9f347d66cf3b612f58e877410b535e95711 krita: Look up the function pointers for the sync functions and use those Could do something... Though there is not a big, logical difference. commit 79643acbd03bd7e51048f15a18c16195b4c34516 Report the opengl configuration Only saves a temporary file with the opengl commit when opengl is initialized... I am very puzzled.
Sorry, there was a wrong copy & paste, the correct thing I wanted to post was: git reset --hard 6ae0e9f3 still slow git reset --hard 79643acb still slow git reset --hard 7a3fdb9a things returned to normal
Hi Boud, I went back to check again and found that I must have make a mistake. My second test shows that: git reset --hard 79643acb actually fixes the issue. I must have press the Fn key instead of Ctrl on my keyboard. :b Sorry!
Okay... It looks like the sychronizing never worked on your system, but that you apparently never needed it. Now synchronizing the display works and the HQM mode doesn't get its work done in time, so everything stalls. I guess we'd best add an option to disable synchronizing...
Git commit a6f5ef10a99efc9915af36d65e631c072fb70d17 by Boudewijn Rempt. Committed on 05/03/2014 at 15:41. Pushed by rempt into branch 'calligra/2.8'. Apparently the glFenceSync call never worked (at least on some systems), where making it work slows everything down. On the other hand, on other systems it's necessary... M +7 -0 krita/ui/dialogs/kis_dlg_preferences.cc M +15 -5 krita/ui/forms/wdgdisplaysettings.ui M +10 -0 krita/ui/kis_config.cc M +3 -0 krita/ui/kis_config.h M +6 -4 krita/ui/opengl/kis_opengl_canvas2.cpp http://commits.kde.org/calligra/a6f5ef10a99efc9915af36d65e631c072fb70d17
Git commit 3d3b1e22984b20d4d1461ffb3197097846c285e2 by Boudewijn Rempt. Committed on 05/03/2014 at 15:41. Pushed by rempt into branch 'master'. Apparently the glFenceSync call never worked (at least on some systems), where making it work slows everything down. On the other hand, on other systems it's necessary... M +7 -0 krita/ui/dialogs/kis_dlg_preferences.cc M +15 -5 krita/ui/forms/wdgdisplaysettings.ui M +10 -0 krita/ui/kis_config.cc M +3 -0 krita/ui/kis_config.h M +6 -4 krita/ui/opengl/kis_opengl_canvas2.cpp http://commits.kde.org/calligra/3d3b1e22984b20d4d1461ffb3197097846c285e2
I built the new revision and unchecked the Synchronize Frame option, but unfortunately it doesn't seem to fix the slowliness. But I found another interesting thing: when Krita's canvas took about 1/4 of the area of 1920x1080, it did not slow down.
I also tested this on GTX550Ti and GT430. Both of them were also affected but they seemed to perform somewhat better, even though they can only unleash about 1/4 of their power using the open-source nouveau driver. GT430 and GTX550Ti were choppy, fast for one second and slow for another, while GTS250 was extremely slow all the time. Some OpenGL related packages In my system: Mesa: 9.2.1 libglu1: 8.0.4 libglew:1.6.0 libdrm:2.4.46 nouveau: 1.0.9 linux-kernel: 3.11.5-gnu
Hm... It doesn't make _sense_... Maybe I should wait until tomorrow, when I'm not so fuzzy-minded from releasing :-)
Congratulations on the 2.8.0 release! :D Meanwhile I will test a little further to see if there is anything I forgot to do.
Btw, GeForce GTX 650 T and the commercial drivers here on Linux, but I also see that Krita warns that it cannot enable the sync functions anyway, which explains why I cannot see a slowdown anyway...
Git commit d500815d4f5d48b925240efe8418cce665f439a1 by Boudewijn Rempt. Committed on 05/03/2014 at 18:14. Pushed by rempt into branch 'calligra/2.8'. Restore the QGLFormat check for getting the sync functions Otherwise, the nvidia driver for my GeForce GTX 650 T cannot find the sync functions, and I cannot test the difference between fencing and not fencing. Not that I find a difference... M +6 -6 krita/ui/opengl/kis_opengl_canvas2_p.h http://commits.kde.org/calligra/d500815d4f5d48b925240efe8418cce665f439a1
Git commit f83cc09f1caf2bdcde531ea8a91ac48516027a1b by Boudewijn Rempt. Committed on 05/03/2014 at 18:14. Pushed by rempt into branch 'master'. Restore the QGLFormat check for getting the sync functions Otherwise, the nvidia driver for my GeForce GTX 650 T cannot find the sync functions, and I cannot test the difference between fencing and not fencing. Not that I find a difference... M +6 -6 krita/ui/opengl/kis_opengl_canvas2_p.h http://commits.kde.org/calligra/f83cc09f1caf2bdcde531ea8a91ac48516027a1b
Tested again here, still slow after the patch. I tried to clear the config folder but it didn't work. This is getting more and more mysterious now, don't know what kind of black magic Nvidia played in its hardware lol. Thank you for trying so hard, though! :)
Git commit 8abc44a09d8119156d0b155fe4446171fc1e5aa6 by Boudewijn Rempt. Committed on 05/03/2014 at 18:29. Pushed by rempt into branch 'calligra/2.8'. Don create a config object or two, three every time we draw a frame M +11 -8 krita/ui/opengl/kis_opengl_canvas2.cpp http://commits.kde.org/calligra/8abc44a09d8119156d0b155fe4446171fc1e5aa6
Git commit dfa641ca2296a5f2b50c62e48b08e77680200313 by Boudewijn Rempt. Committed on 05/03/2014 at 18:29. Pushed by rempt into branch 'master'. Don create a config object or two, three every time we draw a frame M +11 -8 krita/ui/opengl/kis_opengl_canvas2.cpp http://commits.kde.org/calligra/dfa641ca2296a5f2b50c62e48b08e77680200313
Tested again, still slow here. ^^b
Okay, last try for tonight.... Can you replace KisOpenGLCanvas2::isBusy() (in kis_opengl_canvas2.cpp) with bool KisOpenGLCanvas2::isBusy() const { if (d->useFenceSync) { return Sync::syncStatus(d->glSyncObject) == Sync::Unsignaled; } else { return false; } } And check again?
Nope, it still wouldn't work. Thank you and sorry for keeping you up late! It's 3:00 AM here, too. So I agree the best idea is to rest for now. Good night! :)
Today I installed a copy of Ubuntu 13.10 on my spare SSD and tested this against rev bb2c85d3, same slow issue. On Ubuntu 13.10, I've updated the graphics stack to the newest using Oibaf's PPA, so I think the slowliness was not caused by outdated version of xorg, mesa, drm or nouveau. The problem Boud mentioned is probably by design on these nvidia cards. Too bad that AMD graphics requires proprietary firmwares to even work. Now we are stuck with nvidia's "black magic". XD I will try and find a way to test this issue against intel 2nd/3rd/4th gen HD Graphics. Report back soon.
HI, Tyson! Could you joing our IRC channel? (#krita on Freenode) Then I could prepare some patches for you.
Similar report: https://bugs.kde.org/show_bug.cgi?id=331759
Hi Boud, I went to the local DIY personal computer dealers today and they kindly let me test this issue on their intel systems. Here is my report: SHORT VERSION: This issue seems to also affect intel HD Graphics with OpenGL 3.0 support. --- LONG VERSION: In a limited of time and selection, I tested the issue on the following models using a fully updated Ubuntu 13.10: - Intel Pentium G620 (SandyBridge / 6th gen / HD Graphics / 6 Excution Units / 650–1100MHz) - Intel Pentium G1620 (IvyBridge / 7th gen / HD Graphics / 6 Excution Units / 650-1050MHz) - Intel I3-3220 (IvyBridge / 7th gen / HD Graphics 2500 / 6 Excution Units / 650-1100MHz) To my surprise when I checked their specifications back home, they seemed to be very close to each other on graphics aspect. But they do perform considerably different on gaming. All of the 3 models were very slow when OpenGL is even ON, no matter which filter Krita was using. I had flipped every possible combination of the OpenGL settings but none of them worked. On my laptop I can at least use OpenGL+Trilinear Filter without slowdown. My laptop graphics is: - intel i7-620LM (Ironlake / 5th gen / HD Graphics / 12 Excution Units / 266–566MHz) Although my model has more EU, the fact is i3-3220 delivers much much better graphics performance in every way. Intel has been improving a lot on their integrated graphics lately. One significant difference I can find was that the 5th gen HD Graphics only support OpenGL 2.1, while later models support at least 3.x. Does this fact reminds you anything? --- ABOUT IRC I will see if I have time tonight. Thank you in advance! --- SIMILAR REPORT The link is actually pointing to this bug?
Git commit 9e4aa70c4f67cd232226eaf940079dfb87a46924 by Dmitry Kazakov. Committed on 06/03/2014 at 15:10. Pushed by dkazakov into branch 'master'. Fix the slow updades when working with a tablet due to the lack of sync'ing It seems like on Linux qglx_getProcAddress("glFenceSyncARB") returns a pointer to a dumb function, which is not null, does not crash, but yet does abolutely nothing when called, setting the openGL error code to GL_INVALID_OPERATION. This patch makes Linux version fo Krita always request non-ARB variant of function and Windows version --- ARB-variant. The latter idea was tested by Boud and implemented in b300060d2, which had to be reverted in preparation for this commit. M +9 -13 krita/ui/opengl/kis_opengl_canvas2_p.h http://commits.kde.org/calligra/9e4aa70c4f67cd232226eaf940079dfb87a46924
Git commit 5215cec42ae24db9bde23ef17904b2aee1b663a9 by Dmitry Kazakov. Committed on 06/03/2014 at 15:10. Pushed by dkazakov into branch 'calligra/2.8'. Fix the slow updades when working with a tablet due to the lack of sync'ing It seems like on Linux qglx_getProcAddress("glFenceSyncARB") returns a pointer to a dumb function, which is not null, does not crash, but yet does abolutely nothing when called, setting the openGL error code to GL_INVALID_OPERATION. This patch makes Linux version fo Krita always request non-ARB variant of function and Windows version --- ARB-variant. The latter idea was tested by Boud and implemented in b300060d2, which had to be reverted in preparation for this commit. M +9 -13 krita/ui/opengl/kis_opengl_canvas2_p.h http://commits.kde.org/calligra/5215cec42ae24db9bde23ef17904b2aee1b663a9
+1 for this issue AMD Phenom II X6 1055T 2.8Ghz 6-core processor 16GB RAM 3TB in RAID 0 NVIDIA GEFORCE 650 GT So... OpenGL should be FAST right?! It's the reason things are slow. It also looks awful. Something is very broken with the OpenGL code. If I turn it off things are very nice and fast.