QML Canvas - MouseArea Performance Issues
-
**Hi Everybody! **
I'm developing a very simple drawing tool for an application:
My target platform is android
The tool is quite simple
A MouseArea over a Canvas.
Every positionChange event on the MouseArea I add the new XY pair to an array.
In a workerScript i make a subdivision of the trajectory to make the line smother.
After that, in the onPaint of the canvas, I draw the latest additions to the trajectory.(Not The entire line, just last segment)
The canvas "renderStrategy" is set to "Canvas.Threaded"So, I expected, the main UI thread to be free of the line smoother algorithm expensive calculations and the canvas drawing operations. BUT the MouseArea onPositionChanged is triggered much less often when the canvas is refresh.
I make 2 tests. Shown in this image:
In both Figures:
-The blue thin line with red dots is the debug input of the android device. (The nearest to real pen trajectory)
-The black circles is where MouseArea onPositionChanged Triggered
-The Green line is the smooth line result.In figure 1: The program is operating normally, drawing just the new segment as a new coordinate is input.
In figure 2: The canvas is not updated until the entire line is complete.
(Is not ultra perfect but acceptable the green line is under the thin Blue one near all time)So, I guess the MouseArea is refreshing less often because the CPU is busier, But moving the smooth algorithm to a workerScript and set the Canvas Render Strategy to Threaded didn't make any noticeable difference.
Is necessary to setup something else to make it work? like including concurrence in the main cpp or in the pro file?
As far as I can tell, real multi-thread performance is not noticeable following just the QML documentation.Am I doing something wrong? Is this a bug? Can it be done in other way?
Thanks in advance!
-
Still Loking for a solution!!!! Please some help will be well revived
-
Still Loking for a solution!!!! Please some help will be well revived
Even in qt 5.5.1 the canvas performance is far far far far beyond from something remotely acceptable.
Should I implement an equivalent solution with openGL and completely disregard the existence of the canvas element???