@rempt KoResourcePaths::assertReady() is really only useful inside KisApplication. I suggest we deactivate by default and only activate it explicitly inside KisApplication.

@alvinhochun I did more tests on two Macs and the time difference seems to come from glDrawArrays.

fixed indentation

more reusability

Now uses boost to calculate rolling mean and variance.

Correction; boost does have rolling_variance after all, I just didn't find it in the docs earlier; blast (http://www.boost.org/doc/libs/1_61_0/boost/accumulators/statistics/rolling_variance.hpp)

Dmitry's patch for WinTab linux timestamps is now included. @alvinhochun I'm not sure what Windows uses as native event timestamp, I should probably disable the code for Windows as long as I don't know in order to not print out wrong numbers. QT's docs are not helpful really (they say the input event timestamp will normally be in milliseconds since some arbitrary point in time, such as the time when the system was started., http://doc.qt.io/qt-5/qinputevent.html)

Still a work in progress; added classes to a different file, now uses shared pointer, adds rolling mean.

Fixes the bug observed by @dkazakov.

@alvinhochun @rempt pushed again, sorry for that :-(

applied patch by @dkazakov and pushed to master.
https://commits.kde.org/krita/17ec3286138e525c9fe16e97b056590c636e87f1

pushed.
https://commits.kde.org/krita/360c6263b3fdfefedc730a3fc291589bcc4d3687

We should document somewhere that Mac users need to delete/update their local kritadefault.profile (usually under Application Support/krita/input) in order for this to work as the new modified kritadefault.profile needs to be fetched.

@alvinhochun @rempt This is definitely the right idea and it would be so great having this as it's the one central performance hog on macOS. Alas, I spent a day last week trying to do exactly that and had to find out that with the current QT implementation there's seemingly no way to do it. It used to be possible with QT 4. But with QT5 and QTQuick, the compositing in the main thread doesn't inform any other thread of when the context is occupied and QT crashes with an assertion that a context cannot be used by two threads. The official sample code (https://github.com/qt/qtbase/blob/5.9/examples/opengl/threadedqopenglwidget) is a hack and only works as long as the OpenGL runs in a separate window without other widgets; if there are any other widgets in the other, QT's compositing code fails to properly call onAboutToCompose and onFrameSwapped and so the whole fragile GL context grabbing logic breaks down. It's sad state of affairs with QT.

@alvinhochun Doesn't seem to be officially reported yet, though it popped up in the forums:

the previous version was my debugging version :-)

@alvinhochun That's what "disabled" should do. Or do you have something in mind that is different from the current top of tree?

Panning works now; (the code is not beautiful but robust).

@alvinhochun I'm not sure there are many ways to use OS X with a touch enabled screen. I have a touch enabled Wacom Cintiq but their touch drivers are unfortunately just a hack mapping to certain keyboard shortcuts and they seem completely separate from Apple native touch events you get from using a MacBook trackpad, so no QNativeGestureEvents here.

@alvinhochun I saw that as well, but I wasn't sure what the reason was. Are you on a hidpi screen? Because I suspect this is a QT bug with wrong scaling in the touch screen coordinates when on hidpi. If you're experiencing this on hidpi as well, I can try a fix.

Hi @dkazakov, after looking at the profiling again and the code, I'm a bit confused. This looks like the m_pool.purge_memory(); call inside KisTextureTileInfoPoolSingleSize::free(), but it's really not called that often. I did that profile on an iMac 5K, where performance is abysmal, so maybe in that specific configuration there's something fishy. Will investigate further.

I'm currently investigating getting rid of the glFinish altogether, by (1) using fences or (2) using double buffered pixel buffers. Might actually abandon this if one of the other approaches works.

Hi @dkazakov, I didn't add the assert in KisCanvasUpdatesCompressor::takeUpdateInfo because I don't think I understand it. Can you take another look?

Several renames as suggested by @dkazakov.

Found a problem that causes a delay when starting to drag a layer that is caused by KisMimeData::loadNodes. Will have to investigate further.

Applied some renames and fixes. Reverted to QVector.

Some ideas for having options for this:

pushed with one small centering tweak.

pushed.

pushed.

@dkazakov Is this safe?

Hi @dkazakov, regarding your questions:

@alvinhochun I believe not. First, the code only overrides multi finger gestures, not single finger touch inputs. And this is done by processing the QNativeGestureEvent that Qt gives us. The classic Krita touch implementation of those touch events that are detectable using QNativeEventGestures under OS X is only deactivated because there would be a conflict otherwise: for pinch and rotate, Qt sends a QNativeEventGestures as well as a QTouchEvent, which means Krita would process the same gesture twice with different code paths, which is obviously not desirable. A similar thing happens with pan events (they come as QWheelEvent as well as QTouchEvent on OS X). So, the only reason some code paths are overriden is to not handle the same gesture twice. We might of course do something like: if a QNativeGestureEvent arrives, then ignore all following or near QTouchEvents; but that would assume that the QNativeGestureEvent always comes first and the QTouchEvents for the same physical finger movement comes second, and that is not documented in Qt. So it's a bit difficult how to really deal with this cross platform wise, if one does not know which events the platform will give us. On OS X it's simple. But on other systems this might have to be an option like "Enable native gesture events".

Pushed: https://commits.kde.org/krita/f8b418319aff896d0fd0058a7d6c5df56f09599e

Fixed and pushed to master.

Changed.

Changed to const iterator getters.

OK, pushed.

I pushed the implementation to krita:bliebl/kocolor now. Is this the right approach?

@alvinhochun I should have mentioned that it's not really enabled for other platforms as I didn't want to break anything. You can try to commend out the two #ifdef Q_OS_OSX and see what happens; it then will override Krita's implementation. But if QT does not send any QNativeGestureEvents on specific platform, this basically breaks touch support for the platform.

Adds missing KisInputManager::Private::addNativeGestureShortcut (sorry for that)

@alvinhochun Yes, pan and zoom are implemented, but on OS X, pan actually maps to zoom as it is reported as a mouse wheel event by Qt, it's very confusing, and zoom works but not, touch wise, as reliable as the native gestures.

concerning (1), I believe it's better to actually enforce an assert as everything else will lead to color space init issues as described in my crash fix text. If the first color space is created before KisApplication has set up the resource paths, we're in big trouble (and this has nothing to do with this PR, to make this clear).

This fixes that crash inside KoLcmsColorProofingConversionTransformation::KoLcmsColorProofingConversionTransformation Dmitry observed.

Interesting. So we can we're safe to use C++11 in Krita where possible (at least range based loops)? BTW which Qt version does Krita support as minimum?

A few more details (and an analysis comparable to the one in D8033):

@alvinhochun @dkazakov, the specific use case for this PR, KisUpdateInfo is indeed bogus (I actually had confused profiler values for the KoUpdateInfo constructor with malloc times) ; and as it turns out, now I've taken more measurements, you're right, Dmitry, the whole time spent in (non-QT) memory allocation even under load usually seems to be not an issue (under 3%).

@alvinhochun This is indeed interesting, so the problem won't occur on Windows. On OS X the timer seems to get swamped if there's a lot of input events, I originally detected this by playing with touch events and seeing that if I used my MacBook touchpad Krita did not respond at all (due to this effect: a lot of touch events, no timers).

removed debugging code

renamed m_d to d

Yes, it's an OS X only bug fix. It actually needs glFinish (full synchronous stop, argh), I tried glFlush and then you get artefacts (at least with mip mapping texture modes).

Fixed margins, moved tags to bottom:

removed the bullets

Added a specific role for tags now in order to be able to give them a separate style:

Using a QVector::swap is more elegant.

Though I personally really find this useful working on a Cintiq with a stylus and not having to grab the scollbar.

fixes a wrong const

So this is the "KOColor without dynamic allocations" refactoring I came up.

Just for completeness' sake: what this ultimately aims at is a very minimal look like with Sketchbook Pro:

But hiding the title bar breaks moving the window in undocked move as far as I tried it once.

@dkazakov, the temp folders should eventually get deleted, but it might take days, months or years, and it's not transparent when OS X does this (and not documented). For example, here's my temp folder where krita would store temp files if one disabled the swap file template file name after force quitting Krita two times: