Version: 1114466 (using KDE 4.4.2) OS: Linux Installed from: Ubuntu Packages WHAT I EXPECTED TO HAPPEN: When using speed curve to change the size of a brush, I expect the brush size to match the cursor speed from the very beginning of the brush stroke. WHAT ACTUALLY HAPPENS: At the start of the brush stroke, the stroke is always huge. It then shrinks quickly to the expected brush size. It starts at the same size whether the cursor was moving rapidly or very slowly when the brush stroke begins. See: http://img412.imageshack.us/img412/9625/speedcurve.png In this example, the cursor was moving at a fairly consistent speed before, during and after the brush stroke. STEPS TO REPRODUCE: 1. Select a painttop (I used the default pixel brush) 2. Turn on the speed curve in the brush size configuration. 3. Paint a brush stroke with a smooth even movement. 4. Notice that every stroke begins oversize and then shrinks rapidly.
I don't think this is an actual bug. This setting is very sensitive, so even a rather small speed increase does a big change. Try to use a curve that is less steep to reduce the effect.
Created attachment 48132 [details] i try to use a curve, that is less steep i try to use a curve, that is less steep and get the same result. the brushsize of the starting brush depends on the curve's maximum.
Created attachment 48133 [details] however, i believe, that this could be also a feature.
I took a look at the code and the problem is the way the speed is calculated: Because the moved distance is zero at the start of the stroke, distance/time will be zero too (time is always big than zero) that causes the maximum value. Problem is that we don't know the speed in the first moment. Not sure how to solve that.
As Adam suggested it on IRC, the speed of the pointer could be tracked even when not drawing. To make it work, the speed of the cursor should be computed in the freehand tool, and added to KisPaintInformation, and then the speed sensor can read it from there instead of computing it from the time and distance.
This one will be solved probably by using dyna's way of computing speed. For 2.4 as discussed with Cyrille and Boud.
They disagree with LATER :)
Git commit 6fcba2eb1bfd29bb54af8e10a145eb1def17c8d8 by Dmitry Kazakov. Committed on 03/08/2013 at 19:25. Pushed by dkazakov into branch 'master'. Initialize averaging buffer with initial speed value M +8 -2 krita/plugins/paintops/libpaintop/sensors/kis_dynamic_sensors.cc M +1 -5 krita/plugins/paintops/libpaintop/sensors/kis_dynamic_sensors.h http://commits.kde.org/calligra/6fcba2eb1bfd29bb54af8e10a145eb1def17c8d8