Bug 300668

Summary:	Canvas input is limited to canvas update rate
Product:	[Applications] krita	Reporter:	Arjen Hiemstra <ahiemstra>
Component:	General	Assignee:	Krita Bugs <krita-bugs-null>
Status:	RESOLVED FIXED
Severity:	normal	CC:	animtim, dimula73, halla
Priority:	NOR
Version:	unspecified
Target Milestone:	---
Platform:	Compiled Sources
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:
Bug Depends on:
Bug Blocks:	300339

Description Arjen Hiemstra 2012-05-26 15:02:08 UTC

(Filing a proper bug for it since I now discovered it is also reproducable with the QPainter canvas.)

The processing of input events is limited to the redraw rate of the canvas. That is, if the canvas takes too long to update, input events are dropped and painting becomes erratic. A good example of this is shown in bug 300339 . 

Reproducible: Always

Steps to Reproduce:
It is simple to reproduce using the OpenGL canvas: Simply draw some quick circles, instead of them becoming proper circles, they will end up with straight bits. It can also be reproduced with QPainter, but only on slower machines or (very rarely) when making really fast circles.

One guaranteed way of reproducing it however is running Krita under valgrind or another tool that slows down Krita. Using valgrind the behaviour is very pronounced, it will only process something like four points when drawing a circle.
Actual Results:  
Input events are dropped and the strokes become more erratic, usually meaning the circle will have straight parts.

Expected Results:  
No input events are dropped and a smooth circle is drawn.

Comment 1 Halla Rempt 2012-06-03 10:02:39 UTC

Some context.... http://www.valdyas.org/fading/index.cgi/hacking/krita/learning_cpp.html?seemore=y

In other words, it's not a new problem. The issue is that you cannot paint on a widget outside the gui thread. We already do the compositing already in a separate thread. I'm not sure about the prescaled projection and pyramid (for the qpainter canvas). I know it was intended to run that in a thread as well, but I'm not sure whether Dmitry finished that part.

For the opengl canvas, I'm not sure what is taking the time there. I guess also the preparation of the textures and the uploading of them to the graphics card. Is that something that can be done in a thread?

Comment 2 Halla Rempt 2012-06-03 10:10:31 UTC

Hm. no, it isn't threaded. There's mention of a QThreadPool in KisImagePyramid, but it's commented out.

Comment 3 Halla Rempt 2013-09-26 19:15:21 UTC

*** Bug 300339 has been marked as a duplicate of this bug. ***

Comment 4 animtim 2013-09-28 15:48:54 UTC

Some more information I've collected on this issue:

-Those broken strokes happen only with pixel brush and color-smudge brush. I can't get any broken stroke with sketch brush or Hairy brush, even in opengl, trilinear activated, over-speed strokes, many layers, zoom 17% (see below..) ...

-The smaller the brush is, the more it happens (which is weird in a way as smaller brush strokes should be faster than bigger brush. I'm not sure why bigger brush trigger less easily the problem.
May be related somehow to the fact bigger brush use bigger/less tiles, or require more processing power making the hardware run faster..

-At Zoom 17% (and actually all numbers from 13% to 19%) it happens a lot more. If I have a 4816x7016 canvas, with only a few layers, I can only get broken stroke at these zoom level. 20%zoom and above are good. 12% and less are quite ok (anyway at this zoom-out level you can't draw little details precisely , so..). But in a file with many layers (like a finished comics page , with tens of layers, groups, and vector layers, it can happen at all zoom level (but still happens more easily at these specific zoom levels).

I hope these clues can help you to find a solution.

Comment 5 Dmitry Kazakov 2013-12-31 06:18:14 UTC

Fixed in master after tablet refactoring