Version: svn trunk (using KDE 4.4.2) OS: Linux The cursor shape 'outline' in preference is my favourite to paint cause it give feedback to the size of the brush I use. But this one is actually : - 'Laggy' when moving on the screen without painting, not smooth as if I choose other 'cursor shapes' ( even the 3D pen one have smoother movement ) - It is 100% color black, this make the work on black background difficult. - The shape disappear when the pen nib is pressed, when the brush stroke is done. Reproducible: Always Steps to Reproduce: 1) Go to the preferences > set the 'cursor shapes' to 'outline' 2) Paint with various brush 3) try after fill the workspace in black or a dark color Actual Results: - 'Laggy' when moving on the screen without painting, not smooth as if I choose other 'cursor shapes' ( even the 3D pen one have smoother movement ) - It is 100% color black, this make the work on black background difficult. - The shape disappear when the pen nib is pressed, when the brush stroke is done. Expected Results: - Smooth the movements when the cursor fly over the canvas - Find a way to keep cursor visible above any colors on the canvas. - Keep the shape outline while applying the stroke The 'outline shape' don't have to be 100% accurate. For example, the cursor shape in Mypaint display a circle even if the brush have an angle / a different aspect ratio than a circle. The most important is the smooth freedom of movement ( or the user have a feeling of being limited ) and a feedback of the general diameters of the brush. ( ex: this help the painter to know where he will paint and if his brush choice is too big compare to the detail he want to paint ) A smooth cursor attenuate the user perception of a laggy brush engine.
SVN commit 1149828 by langkamp: add config option to show brush outline while painting CCBUG:241289 M +8 -0 dialogs/kis_dlg_preferences.cc M +1 -0 dialogs/kis_dlg_preferences.h M +14 -7 forms/wdggeneralsettings.ui M +10 -0 kis_config.cc M +3 -0 kis_config.h M +2 -1 tool/kis_tool_freehand.cc WebSVN link: http://websvn.kde.org/?view=rev&revision=1149828
SVN commit 1150321 by lukast: Add new way of painting outline. Now every paintop returns QPainterPath and tool is responsible for painting and conversion from pixel coord into view coordinates. Thanks to KisTool::paintToolOutline, native OpenGL code is used for OpenGL canvas so drawing might be faster and outline is always visible due to using XOR. XOR is also used for QPainter-based canvas. So far only paintops with standard brush dialog are ported and duplicate paintop is ported. The outline for duplicate is new and experimental (no more just cross). It has bug due to wrong size of the bounding rect, but works for OpenGL canvas. Old API is still used if the paintop is not ported. CCBUG:241289 M +6 -0 image/brushengine/kis_paintop_settings.cpp M +6 -0 image/brushengine/kis_paintop_settings.h M +26 -0 plugins/paintops/defaultpaintops/duplicate/kis_duplicateop_settings.cpp M +1 -0 plugins/paintops/defaultpaintops/duplicate/kis_duplicateop_settings.h M +10 -0 plugins/paintops/libbrush/kis_boundary.cc M +3 -0 plugins/paintops/libbrush/kis_boundary.h M +16 -0 plugins/paintops/libpaintop/kis_brush_based_paintop_settings.cpp M +2 -0 plugins/paintops/libpaintop/kis_brush_based_paintop_settings.h M +18 -1 ui/tool/kis_tool_freehand.cc WebSVN link: http://websvn.kde.org/?view=rev&revision=1150321
SVN commit 1150348 by lukast: o Implement outlines for the rest of the paintops o Remove hotSpot from the API, it is in pixel coords and the path can be translated in the settings object CCBUG:241289 M +1 -2 image/brushengine/kis_paintop_settings.cpp M +1 -2 image/brushengine/kis_paintop_settings.h M +11 -0 plugins/paintops/chalk/kis_chalk_paintop_settings.cpp M +1 -0 plugins/paintops/chalk/kis_chalk_paintop_settings.h M +2 -2 plugins/paintops/defaultpaintops/duplicate/kis_duplicateop_settings.cpp M +1 -1 plugins/paintops/defaultpaintops/duplicate/kis_duplicateop_settings.h M +17 -0 plugins/paintops/deform/kis_deform_paintop_settings.cpp M +1 -0 plugins/paintops/deform/kis_deform_paintop_settings.h M +13 -1 plugins/paintops/gridbrush/kis_grid_paintop_settings.cpp M +2 -0 plugins/paintops/gridbrush/kis_grid_paintop_settings.h M +13 -0 plugins/paintops/hairy/kis_hairy_paintop_settings.cpp M +1 -0 plugins/paintops/hairy/kis_hairy_paintop_settings.h M +4 -4 plugins/paintops/libpaintop/kis_brush_based_paintop_settings.cpp M +1 -1 plugins/paintops/libpaintop/kis_brush_based_paintop_settings.h M +12 -0 plugins/paintops/sketch/kis_sketch_paintop_settings.cpp M +1 -0 plugins/paintops/sketch/kis_sketch_paintop_settings.h M +17 -0 plugins/paintops/softbrush/kis_soft_paintop_settings.cpp M +1 -0 plugins/paintops/softbrush/kis_soft_paintop_settings.h M +17 -0 plugins/paintops/spray/kis_spray_paintop_settings.cpp M +1 -0 plugins/paintops/spray/kis_spray_paintop_settings.h M +2 -3 ui/tool/kis_tool_freehand.cc WebSVN link: http://websvn.kde.org/?view=rev&revision=1150348
I think this one is fixed. Brush outline is always visible, the movement is smooth for me and you can check that outline is visible when you paint. What about others? I think just the smooth movement may vary.
BUGDAY
To me this is solved here.
I can't reproduce any part of this bug either.
Works great for me, even with a 300px brush on a crappy laptop video crad running the FOSS drivers. Outline shows when painting. Nice job guys! TECH SPECS: Krita revision 1166713 Kubuntu 10.04 32bit KDE 4.5 QT 4.7.0 beta 2
D'oh! Now I'm getting this issue, even with a tiny (5px) brush! As the original poster wrote cursor lag only happens with "brush outline" chosen, although painting is really lagging no matter which cursor type is chosen. I'm using the default CMYK template and brush, although it's my second Krita window open. I'm not seeing this issue in the other (rgb) window. TECH SPECS: Krita revision 1166713 Kubuntu 10.04 32bit KDE 4.5 QT 4.7.0 beta 2
This might be related to the cmyk colorspace -- maybe the recomposition of that is too slow?
Don't know, but here's a couple of loose observations: If I have more than one Krita window open (with the same CMYK template) the first window seems the fastest, the second lags more and so on. Krita's CPU usage stays low (around 6%), hard drive isn't doing anything and ram (with 3 cmyk windows open) i at only 150mb. Yet still it lags!