There we are...

http://heap.kogmbh.net/downloads/krita_x64_2.7.8.27.msi
http://heap.kogmbh.net/downloads/krita_x86_2.7.8.27.msi

Wow, finally krita works great, and custom hotkeys are saved again. 25 build had some opengl issues but 26 relaease is smooth as butter.
Nezumi- tu fix popup palette just set it up to middle mouse click. So now bottom of pen side button works as top button.

boudewijn wrote:We will probably have to add more config gui for wacom options...

Right click for popup palette is not configuration problem, but somehow krita swaps top and bottom pen buttons. In wacom settings I have setup like this
- top button => MMB
- bottom button => Right MB
But Krita recognizes:
-top button click as RMB
-bottom button click as MMB

JoseConseco wrote:Nezumi- tu fix popup palette just set it up to middle mouse click. So now bottom of pen side button works as top button.

I switched them in wacom and it didnt worked - will try to switch in Krita..

HA! it worked! I set pan to right click and pop up menu to middle click - Krita by doing opposite of what I set is...doing exactly what I want Tricky but works perfect.
Now it looks like really solid release! Cant wait to finish work and paint something - thx!

BTW JoseConseco - try even newer 27 One bug was shaved also. Krita had problems because of Nvidia - luckily boudewijn managed to purchase Nvidia gfx card from community based donations and fixed this stuff extremely fast :O

Yep, switching RMB with MMB in krita is good workaround. But I noticed that I couldn't select different brush with popup palette. Brush popup is gone as soon as I release my stylus button. With mouse it works ok - popup stays on top even after releasing mouse button. Workaround to this is - disable stylus right click in wacom preferences (I read this in Nezumi post in other thread). I hope boudewijn will fix above issues.

JoseConseco wrote:Yep, switching RMB with MMB in krita is good workaround. But I noticed that I couldn't select different brush with popup palette. Brush popup is gone as soon as I release my stylus button. With mouse it works ok - popup stays on top even after releasing mouse button. Workaround to this is - disable stylus right click in wacom preferences (I read this in Nezumi post in other thread). I hope boudewijn will fix above issues.

True... I just noticed. Well, not a big deal but something to keep in mind upon next release. I just switched again and using that damn middle button

This is probably something to report to bugs.kde.org -- it's fall-out from the wintab/wacom support rewrite. We kind of need a quite detailed overview of what works and what fails with common usecases. Us developers, we probably never go much beyond "hack, build, install, start, draw squiggle, close, hack, build, rinse, repeat..."

it really works very smoothly, great work!

boudewijn wrote:This is probably something to report to bugs.kde.org

Done.

I just loaded up a 41 x 40 image, and it came in with a black canvas. I experimented a bit and found that this happens when creating or loading images 1103 wide x 635 high and smaller, and it stays black until zooming out. The smaller the image, the further you have to zoom out before the canvas comes good again. Seems that a remnant of the OpenGL issue has remained...?

I've had a similar issue with a psd file but solved it by setting the opengl setting to use texture buffer and high quality scaling

I tried those settings and the canvas was still black, and zooming wouldn't fix it either. So I tried trilinear filtering, which was working until I made a 512 x 512 image, which was black with a white square in the lower right. So I tried high quality filtering again, which was now working. And then it wasn't. Seems a bit flaky...

Hm, on my nvidia card, I can reproduce the black canvas issue with a 41x40 pixel image if bilinear filtering is enabled. Switching to high-quality filtering solves the problem for me (probably because it's an entirely different code path). I'm using the 327.23 driver atm.

I'm on 331.65 by the looks of it (Windows is forcing updates now - I no longer have a say in the matter!). Trilinear or high quality do seem to be more reliable than bilinear, but I've had them all go to black at one point or another. It's a bit random.

Are there any disadvantages to using trilinear or high quality over bilinear?

Hi, Chris!

HighQuality may be a but slower on some (broken) drivers, but generally it is much better than Bilinear and Trilinear.

On smaller zoom levels Trilinear will generate more blurry lines, whereas Bilinear will make them more aliased. High Quality has no such problem, but it is available only with openGL 3.0+.

Sounds like HQ is the go then. Thanks dkazakov!