Boud -

Just a quick shout out about my first test run of Krita 3.0 (stock binaries) up on macOS Sierra PB1. It lives.

Here's proof:

https://www.dropbox.com/s/txx6di7fzsfpu ... n.png?dl=0

Cool! Today, Nimmy, Dmitry and me figured out some of the problems with the opengl-based canvas -- input issues are still weirding us out, though!

Firstly - hope you are feeling better. Take care of yourself man! By the way, tell the guy who wants Krita on Windows XP that you'll get to it once you finish the Apple II port...

Good to hear about the OpenGL progress! There are definitely some issues with the paint engine, performance and stability issues all around (at least with the stock 3.0 image downloaded from Krita.org). I wouldn't mind taking a look at the OpenGL paint engine myself. I've done a lot of macOS and iOS OpenGL in the recent past. Lately I've been tinkering around with Metal compute and render shaders. Also noticed some input device issues : some weird (or at least unexpected) behavior mousing around with the Magic Mouse ... Hmmm wonder if this is at all related to tablet woes and Qt.

That was a first shot across the bow, so to speak. I am still in the process of constructing my bleeding edge Krita build on Sierra (beta) frameworks and Xcode 8 (beta) toolchains. By the way, have you guys settled on a base Qt platform for 3.1 OS X yet? I have both 5.7 and 5.6 installed and noticed that ext_qt in your third party repository is still pointing to 5.6. Just want to make sure I stay (relatively) close to your dev branch. Also, some general guidance on your regression test methodology would help. What is stable, what is broken, what shouldn't be touched with a 10 foot pole...

Peace and later

It would probably be best to use 5.7: that's the version Nimmy is aiming for currently with his patch to the Qt OpenGL QPainter Engine. What we figured out is that we do not call the mipmap generation in KisTextureTile::bindToActiveTexture at the right moments. The condition is needed, we shouldn't regen the mipmaps all the time, but there's a problem with that and we're not sure exactly what yet.

One other thing that probably also needs to happen is implement tablet support ourself: both on Windows and Linux/X11 we based our tablet support on Qt's, but had to hack around a lot to make it work properly. On OSX, we're still using Qt's tablet support and that seems to be the cause of some of the input issues.

boudewijn wrote:It would probably be best to use 5.7: that's the version Nimmy is aiming for currently with his patch to the Qt OpenGL QPainter Engine. What we figured out is that we do not call the mipmap generation in KisTextureTile::bindToActiveTexture at the right moments. The condition is needed, we shouldn't regen the mipmaps all the time, but there's a problem with that and we're not sure exactly what yet.

Yes Apple's OpenGL support has been a total mess for years. The silver lining here is better support for 3.x, a good thing. I've been following Nimmy's blog and it looks like he has a very firm handle on things. I am eagerly awaiting the final fruit of this labor to test, and will let you guys sort it out b4 butting in.... By the way he is quite the find , he (and GSoC) Rocks! Very impressed with his reports and writing style - a true joy to read. Has inspired me to blog about my bleeding edge explorations with Krita soon. Just a couple of related thoughts along the lines of making "Krita macOS a first class citizen" and while you have Qt paint engine popped up for repairs... :

Support for Metal. I've been playing around with it for the past few months and it's quite impressive both performance and feature wise. My read of Apple's intentions (sitting glibbly in their ivory tower) is an increasing investment in Metal. Of course this is a response to CUDA,Vulkan, DirectX and who knows how this will all shake out in the end, but the fact is performance gains with compute shaders, c++ shader like language etc...are substantial. I think it's not a flash in the pan and here to stay. Maybe time too review Krita's graphics architecture for extensibility if need be?

Support for native CoreImage shaders and plugins. Same as above, a core macOS and iOS layer Krita artists could benefit from.

I guess these are questions all great open source projects face at a certain time. IMHO the "first class" experience on the Mac should leverage its platform specific strengths. Beyond the near philosophical questions of supporting proprietary technologies lies the (painful) issue of limited resources of course...

One other thing that probably also needs to happen is implement tablet support ourself: both on Windows and Linux/X11 we based our tablet support on Qt's, but had to hack around a lot to make it work properly. On OSX, we're still using Qt's tablet support and that seems to be the cause of some of the input issues.

Yes. This is a killer failing given the user category you are catering too. Digital artists need their tablets! I can only assume its turned off many potential adopters already, especially on the Mac where Wacom rules. Hmmm...developing an itch to acquire a tablet to fix this bad boy once and for all...I lost my old Wacom Intuous unfortunately (don't ask...). I previously mentioned some quirky behavior using the Magic Mouse (with scrolling especially). Maybe after I harden my native build on Sierra beta's. Which leads me to...

Some Good progress on the build side. This is definitely turning into my own personal summer of code project (PSoC ?)... I dare say, the environment is quite avant-garde at the moment:
-- macPro 3,1 (unsupported...thanks Apple!) hacked to install latest beta. Currently on Public Beta 1 (I here PB2 is out already great...)
-- Xcode 8 beta 2 (beta 3 just came out) using standard clang/llvm toolchain
-- virgin OS installations : portless brewless finkless to the best degree possible
-- CMake 3.6
-- Qt 5.7 installed from qt-unified-mac-x64-2.0.3-2-online
-- Latest sources git clone git://anongit.kde.org/krita.git from a few weeks ago.
-- Ninja for speed (over 20 years of using make...kinda getting a little long in the tooth. Besides, it just feels minty fresh and new...
-- considering supporting the latest LLVM 3.8.1 toolchain mainly for OpenMP support (tired as heck waiting for Apple to hear our pleas...)

To date, I haven't encountered any major OS 10.12 framework related (build at least) bugs. Some of the mind bending issues were:
-- .DS_Store files mucking up the ext_boost build (need to file a CMake issue/bug for this soon)
-- making sure we are pointing to the right libxml2. Experience teaches that strict control and inspection over the build environment is a de-facto requirement, otherwise custom builds pick up who knows what libraries from the system. In that sense, my pretty "clean" environment is helping me tease out all the little crimps and quirks that don't usually pop up. So I am meticulously inspecting each dependency build. Takes time, but I am maniacal that way...

Ok, on to final install and packaging, I have some rpath related issues to research and take care of...As always your thoughts on my musings are always welcome.

Later

* Metal: well, I'd be hesitant, and I have no desire to learn the api myself. But Krita's canvas is already abstracted out and replacable, that's why we've got an opengl and a qpainter canvas. Adding a third implementation would need relatively little refactoring, and I wouldn't oppose a patch a priori. Later, much later, it would also be possible to add a Vulkan canvas.

* Tablet support: that's something that needs work. If you want to work on it, we can provide you with a loaner tablet. Basically, the technique is to copy the existing Qt code, add it in the right place and then start improving and debugging. There is something really weird going on where switching between the opengl canvas widget and the qpainter canvas widget and back will turn on tablet support for some people! Unfortunately, my intuos 3 + macbook pro combo just works...

* Good rogress on building Yes, controlling the dependencies is key, which is why I discourage using macports or brew or fink and their ilk.

boudewijn wrote:* Metal: well, I'd be hesitant, and I have no desire to learn the api myself. But Krita's canvas is already abstracted out and replacable, that's why we've got an opengl and a qpainter canvas. Adding a third implementation would need relatively little refactoring, and I wouldn't oppose a patch a priori. Later, much later, it would also be possible to add a Vulkan canvas.

I hear you. You have lots on your plate. I plan on devoting a week (when I can) to boning up on the OpenGl and qpainter canvas design. I have no doubt it's been architected well. What branch is Nimmy's work in?

* Tablet support: that's something that needs work. If you want to work on it, we can provide you with a loaner tablet. Basically, the technique is to copy the existing Qt code, add it in the right place and then start improving and debugging. There is something really weird going on where switching between the opengl canvas widget and the qpainter canvas widget and back will turn on tablet support for some people! Unfortunately, my intuos 3 + macbook pro combo just works...

Cool. Are there any specific tablets that exhibit the problems? Or are they general driver/interface issues? I'm actually looking at purchasing one locally to support my wannabe starving amateur (totally!) digital artist needs again. Am debating over the starter new entry level intuous pen touch or the intuous pro line (assuming I can find a good refurbished or used one ). I want one that breaks so I can reproduce the issue. Thanks for the loaner offer, may take you up on it someday. I've already downloaded some wacom driver code to peel the onion.

* Good rogress on building Yes, controlling the dependencies is key, which is why I discourage using macports or brew or fink and their ilk.

Yes. Just found another link to my system zlib which I need to point to our ext_zlib. Probably compatible but just being consistent. Also had to set my pkg_config_path for OpenJpeg to build correctly. More on these little quirks when I finish my full report. Also having fun automating the build process to report on progress/warnings/errors using growl and monit...as they say where I come from "j'ai beaucoup de pain sur la planche..."

Branch: origin/nimmy-opengl3

For the tablet, it doesn't matter, all Wacom tablets are reported to have issues. I use an Intuos 3, which is mostly fine, though. I never managed to get the cintiq to work at all with OSX. An Intuos Pro is probably the best bet.

I just recently got an antiquated genius tablet to work on OSX with pressure sensitivity, but it doesn't appear to get the pressure right at the beginning on some strokes. I suppose I could make a bug report and investigate it myself, but I have no idea who uses OSX with a cheap genius tablet and if that would be worth it.

On OSX, we don't have our own tablet code (yet), and depend on Qt's implementation. To fix this, either we should fix it directly by patching Qt, or do the same as for Linux and Windows, namely fork it.