[krita] [Bug 450151] New: Crash after changing settings in the brush settings menu
https://bugs.kde.org/show_bug.cgi?id=450151 Bug ID: 450151 Summary: Crash after changing settings in the brush settings menu Product: krita Version: nightly build (please specify the git hash!) Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: crash Priority: NOR Component: General Assignee: krita-bugs-n...@kde.org Reporter: tgdev...@gmail.com Target Milestone: --- Krita version : 5.1.0 pre-alpha 7f553b6 SUMMARY *** NOTE: If you are reporting a crash, please try to attach a backtrace with debug symbols. See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** Crash after changing a few settings in the brush settings menu then drawing in scratchpad. Also, for some reason, the brush tip is not well responsive. STEPS TO REPRODUCE 1. reach the brush settings menu with default pixel engine brush 2. change the ratio of the brush and the size a few times 3. right after doing these, try to paint multiple strokes in the scratchpad OBSERVED RESULT The brush tip preview stops responding to changes suddenly. Same as the scratchpad which stops rendering brush strokes. You get a crash afterwards. EXPECTED RESULT Responsive brush tip preview and scratchpad. No crash. SOFTWARE/OS VERSIONS Windows 10 21H1 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 450151] Krita 5.1.0 prealpha : Crash after changing settings in the brush settings menu
https://bugs.kde.org/show_bug.cgi?id=450151 stephen changed: What|Removed |Added Summary|Crash after changing|Krita 5.1.0 prealpha : |settings in the brush |Crash after changing |settings menu |settings in the brush ||settings menu -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 455570] New: Krita plus 5.1.0 prealpha : complex brush outline causes intolerable performance lag
https://bugs.kde.org/show_bug.cgi?id=455570 Bug ID: 455570 Summary: Krita plus 5.1.0 prealpha : complex brush outline causes intolerable performance lag Product: krita Version: nightly build (please specify the git hash!) Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: normal Priority: NOR Component: * Unknown Assignee: krita-bugs-n...@kde.org Reporter: tgdev...@gmail.com Target Milestone: --- Created attachment 149907 --> https://bugs.kde.org/attachment.cgi?id=149907&action=edit Texture of the gauze brush SUMMARY There's a gauze brush that causes Krita to stutter and lag for some unknown reason. In order to have you make investigation, I'll append the picture of the brush tip here. It's noticeable when you try to paint or to resize the brush with the Shift+drag combination. Because of that, I can't use it to work. STEPS TO REPRODUCE 1. create a custom brush with the provided png file 2. Settings for the custom brush as follows : # Sharpness mod ON : pressure(min : 30%, max : 60%) # Rotation mod ON : fuzzy dab(min : -180°, max : 180°) # Spacing : 0.37(auto : off) 3. Try to paint strokes with the brush at 500 pixels size or more. 4. See if you can increase size to 1000 pixels with smooth updated renders, using the Shift+drag method. OBSERVED RESULT Krita struggles to update the rendered outline preview of the brush when the size is big(500-1000px), noticeable frame rate drop or stutters. Krita paints the stamps at a slower speed than expected when the size is big(500-1000px). EXPECTED RESULT No stutter or framerate drop. SOFTWARE/OS VERSIONS Windows: 10 21H1 Qt versions : Version (compiled): 5.12.12, Version (loaded): 5.12.12 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 455570] Krita plus 5.1.0 prealpha : complex brush outline causes intolerable performance lag
https://bugs.kde.org/show_bug.cgi?id=455570 --- Comment #1 from stephen --- Krita version : prealpha e429092 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 466771] New: KDE 5.26.x/5.27.x has terrible uptime ...
https://bugs.kde.org/show_bug.cgi?id=466771 Bug ID: 466771 Summary: KDE 5.26.x/5.27.x has terrible uptime ... Classification: Plasma Product: kwin Version: 5.27.0 Platform: Fedora RPMs OS: Linux Status: REPORTED Severity: major Priority: NOR Component: compositing Assignee: kwin-bugs-n...@kde.org Reporter: ywre6...@gmail.com Target Milestone: --- KDE starts beautifully, then eventually decays to visible un-usability ... *** After a reboot KDE/Plasma runs beautifully. However after a certain amount of time, usually 3-5 days, windows "appear" to be (re)painted completely black, or are not painted at all (it's hard to tell since it happens so fast). (In X, everything is a window of some type; menus, window contents (I haven't seen decorations do this behaviour yet, but have seen it with all components of the task bar.)) When this happens the following are sometimes TRUE: 1. when resizing is available, sometimes resizing the window provides visibility to its painted contents (this is hit or miss and the contents will flash correctly or not); 2. sometimes iconifing the window, or closing and re-opening the window will allow visibility to its painted contents; and likewise dismissing and reengaging a menu (window) will allow the menu to be visibility painted. 3. This happens across all applications, even programs written in basic X (e.g. /usr/bin/xv) to wildly complex programs like firefox and everything in between. My workspace consists of 4 virtual desktops and switching to another desktop and back has no effect on windows painted as "black." > I really don't know if the window is "properly" rendered then over-painted as > the process is too quick for the eye ...? When it happens, I have to exit the workspace and init S/control-D to reload everything back to "clean the slate," but this is temporary and eventually the cycle repeats. I had hoped 5.27 would have cleaned this up, but it's still there. *** STEPS TO REPRODUCE: 1. Run the workspace for several days including cycles of screen locking, etc. 2. Use the workspace normally (I run several konsoles, firefox, thunderbird, and a few other applications on and off). OBSERVED RESULT Eventually, some windows will be painted as "black." Kinda happens infrequently at first, then becomes more and more common as time progresses. EXPECTED RESULT I'm used to uptimes measured in the years and expect no less from my workspace. I upgraded from Fedora 34 KDE (exactly the same hardware) and have never seen this happen. HACKS TRIED: - most of the kernels released under Fedora 37 - NVIDIA-Linux-x86_64-515.76.run, NVIDIA-Linux-x86_64-520.56.06.run, NVIDIA-Linux-x86_64-525.60.11.run, and NVIDIA-Linux-x86_64-525.89.02.run. - I did NOT think to disable desktop effects (I will if it happens again) to see what happens. SOFTWARE/OS VERSIONS: Operating System: Fedora Linux 37 KDE Plasma Version: 5.27.0 KDE Frameworks Version: 5.103.0 Qt Version: 5.15.8 Kernel Version: 6.1.12-200.fc37.x86_64 (64-bit) Graphics Platform: X11 Processors: 16 × AMD Ryzen 7 1700 Eight-Core Processor Memory: 62.7 GiB of RAM Graphics Processor: NVIDIA GeForce GTX 1060 3GB/PCIe/SSE2 ADDITIONAL INFORMATION Appearance - Breeze Dark Application style - Breeze Plasma Style - Infinity-plasma Windows decorations - Breeze DESKTOP EFFECTS: Magnifier, Mouse Mark, Translucency, Wobbly Windows Virtual Desktop Switching - slide w/desktop background DISABLEd WINDOW BEHAVIOUR: Focus under mouse w/raise on hover after 750ms 4x Virtual desktops on TWO physical monitors xwininfo: Window id: 0x1c00011 "Desktop — Plasma" Absolute upper-left X: 2560 Absolute upper-left Y: 0 Relative upper-left X: 0 Relative upper-left Y: 0 Width: 2560 Height: 1440 Depth: 32 Visual: 0x7a Visual Class: TrueColor Border width: 0 Class: InputOutput Colormap: 0x1c00010 (not installed) Bit Gravity State: NorthWestGravity Window Gravity State: NorthWestGravity Backing Store State: NotUseful Save Under State: no Map State: IsViewable Override Redirect State: no Corners: +2560+0 -0+0 -0-0 +2560-0 -geometry 2560x1440-0+0 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 466771] KDE 5.26.x/5.27.x has terrible uptime ...
https://bugs.kde.org/show_bug.cgi?id=466771 --- Comment #1 from Stephen --- Immediately after I filed this report, it started happening again. I tried toggling the desktop effects (Alt+Shift+F12) and its seems to have cleared it up ... -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 466771] KDE 5.26.x/5.27.x has terrible uptime ...
https://bugs.kde.org/show_bug.cgi?id=466771 --- Comment #2 from Stephen --- toggling the desktop effects... After toggling the desktop effects, it clears up the painting issue, but only briefly. Between minutes to maybe an hour or two. It's a temporary hack to return the desktop's usability, but whatever's causing issue is not corrected entirely (resetting via init S or rebooting resets things to the 2-3 days state before the issue appears). -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 412011] Changing cursor color to black in settings makes the brush outline to disappear
https://bugs.kde.org/show_bug.cgi?id=412011 stephen changed: What|Removed |Added CC||tgdev...@gmail.com --- Comment #4 from stephen --- (In reply to Tiar from comment #3) > I think this might be closed as INTENTIONAL... or changed to wish. Ahab's > explanation on why this happens is correct. I guess a simple fix would be to > use a grey outline instead. Not gray outline. But pure white/black outline depending on the color it hovers on. Can be added as a new color mode for the cursor. -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 412795] Wireguard set up fails with erros -settings lost
https://bugs.kde.org/show_bug.cgi?id=412795 Stephen changed: What|Removed |Added CC||kdeb...@drsudo.com --- Comment #8 from Stephen --- I experienced this too, and was very frustrated by it (especially the default name being invalid and losing my config). I thought that I could add a little bit of explanation to it. The name of the connection is being used as the Linux interface name (The list of names that you get if you type "ip link" at a terminal). AFAIK, other VPN types (such as OpenVPN) in the network manager don't do this. I have an OpenVPN connection up right now, and it gets the interface name "tun0". This has nothing to do with the name that I put in the network manager. The consistent behavior would be to have the wireguard network get named something like "wg0" regardless of what it is called in the network manager. On the other hand having the Linux interface get a nice name is really cool. I think the ideal would be if there was "interface name" field in the wireguard setup UI, and the connection name was decoupled from the interface name. -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 412795] Wireguard set up fails with erros -settings lost
https://bugs.kde.org/show_bug.cgi?id=412795 --- Comment #9 from Stephen --- I looked at the other network-manager editors (eg nm-connection-editor), and they do include a separate "interface" field that is distinct from the name. I have looked into the plasma-nm repo, and I think I have my head wrapped around how to make this change. I haven't done any KDE work before, so I'm getting kdesrc-build set up. Then I am going to take a crack at fixing this issue. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 452471] New: Krita prealpha 5.1.0 : Whole canvas become transparent when you use E key to switch to Eraser
https://bugs.kde.org/show_bug.cgi?id=452471 Bug ID: 452471 Summary: Krita prealpha 5.1.0 : Whole canvas become transparent when you use E key to switch to Eraser Product: krita Version: nightly build (please specify the git hash!) Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: normal Priority: NOR Component: General Assignee: krita-bugs-n...@kde.org Reporter: tgdev...@gmail.com Target Milestone: --- Krita version : 5.1.0 prealpha git(59f3789) Display issue : Whole canvas pixels disappear when you switch to eraser mode using the 10 brush scripts shortcut or eraser mode(glitches of null canvas pixels randomly appear if you activate the erase blending mode) STEPS TO REPRODUCE 1. create an A4 document @300 ppi 2. Zoom in past 100% at least(zoom level >= 100%) 3. use "E" shortcut to switch to an eraser brush or eraser blending mode OBSERVED RESULT 1. All or almost all the displayed pixels disappear, leaving a fully transparent canvas in the viewport 2. Panning afterwards may temporarily bring back the display to normal EXPECTED RESULT The viewport is not supposed to suffer at all from an issue like this and is meant to properly show the canvas whether you zoom in or out or switch brushes. Glitches shouldn't appear at all. SOFTWARE/OS VERSIONS Windows: 10 21H1 ADDITIONAL INFORMATION API in use : Wintab Use tablet drivestamps for brush speed : false(unticked in other words) -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 452471] Krita prealpha 5.1.0 : Whole canvas become transparent when you use E key to switch to Eraser
https://bugs.kde.org/show_bug.cgi?id=452471 --- Comment #2 from stephen --- (In reply to Alvin Wong from comment #1) > I suspect this is the same as bug 451859. What's in your "show system > information for bug reports"? Krita Version: 5.1.0-prealpha (git 59f3789) Installation type: installer / portable package Languages: en_US, en, en_US, en, en_US, en, en_US, en, en_US, en, en_US, en, en_US, en, en_US, en, en_US, en Hidpi: true Qt Version (compiled): 5.12.12 Version (loaded): 5.12.12 OS Information Build ABI: x86_64-little_endian-llp64 Build CPU: x86_64 CPU: x86_64 Kernel Type: winnt Kernel Version: 10.0.19043 Pretty Productname: Windows 10 (10.0) Product Type: windows Product Version: 10 OpenGL Info Vendor: "Google Inc." Renderer: "ANGLE (Intel(R) HD Graphics 4000 Direct3D11 vs_5_0 ps_5_0)" Version: "OpenGL ES 3.0 (ANGLE 2.1.0.57ea533f79a7)" Shading language: "OpenGL ES GLSL ES 3.00 (ANGLE 2.1.0.57ea533f79a7)" Requested format: QSurfaceFormat(version 3.0, options QFlags(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::DoubleBuffer, swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile QSurfaceFormat::CompatibilityProfile) Current format: QSurfaceFormat(version 3.0, options QFlags(), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples 0, swapBehavior QSurfaceFormat::DefaultSwapBehavior, swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile QSurfaceFormat::NoProfile) Version: 3.0 Supports deprecated functions false is OpenGL ES: true supportsBufferMapping: true supportsBufferInvalidation: false Extensions: "GL_CHROMIUM_bind_uniform_location" "GL_ANGLE_depth_texture" "GL_CHROMIUM_copy_compressed_texture" "GL_OES_packed_depth_stencil" "GL_OES_texture_float" "GL_OES_texture_npot" "GL_OES_vertex_array_object" "GL_EXT_read_format_bgra" "GL_OES_compressed_ETC1_RGB8_texture" "GL_EXT_debug_marker" "GL_ANGLE_translated_shader_source" "GL_OES_texture_float_linear" "GL_EXT_texture_storage" "GL_ANGLE_texture_compression_dxt5" "GL_NV_EGL_stream_consumer_external" "GL_ANGLE_framebuffer_multisample" "GL_EXT_frag_depth" "GL_NV_fence" "GL_ANGLE_client_arrays" "GL_EXT_occlusion_query_boolean" "GL_NV_pack_subimage" "GL_OES_texture_half_float" "GL_EXT_disjoint_timer_query" "GL_EXT_texture_compression_dxt1" "GL_NV_pixel_buffer_object" "GL_EXT_texture_filter_anisotropic" "GL_ANGLE_texture_usage" "GL_EXT_shader_texture_lod" "GL_ANGLE_instanced_arrays" "GL_EXT_sRGB" "GL_ANGLE_multiview" "GL_ANGLE_pack_reverse_row_order" "GL_EXT_unpack_subimage" "GL_ANGLE_request_extension" "GL_EXT_draw_buffers" "" "GL_CHROMIUM_color_buffer_float_rgb" "GL_EXT_texture_rg" "GL_EXT_texture_norm16" "GL_CHROMIUM_bind_generates_resource" "GL_EXT_texture_compression_s3tc_srgb" "GL_CHROMIUM_color_buffer_float_rgba" "GL_OES_standard_derivatives" "GL_CHROMIUM_sync_query" "GL_OES_EGL_image_external_essl3" "GL_ANGLE_framebuffer_blit" "GL_ANGLE_robust_client_memory" "GL_OES_EGL_image" "GL_OES_EGL_image_external" "GL_OES_mapbuffer" "GL_EXT_color_buffer_half_float" "GL_KHR_debug" "GL_EXT_texture_format_BGRA" "GL_OES_surfaceless_context" "GL_OES_texture_half_float_linear" "GL_OES_element_index_uint" "GL_CHROMIUM_copy_texture" "GL_ANGLE_texture_compression_dxt3" "GL_ANGLE_lossy_etc_decode" "GL_EXT_robustness" "GL_OES_rgb8_rgba8" "GL_EXT_blend_minmax" "GL_EXT_discard_framebuffer" "GL_OES_get_program_binary" "GL_OES_depth32" "GL_EXT_color_buffer_float" "GL_ANGLE_program_cache_control" "GL_EXT_map_buffer_range" QPA OpenGL Detection Info supportsDesktopGL: true supportsAngleD3D11: true isQtPreferAngle: true use
[krita] [Bug 455570] Krita plus 5.1.0 prealpha : complex brush outline causes intolerable performance lag
https://bugs.kde.org/show_bug.cgi?id=455570 --- Comment #6 from stephen --- (In reply to Dmitry Kazakov from comment #5) > Git commit bef36adac9ed3934c68431da838045041fa4a31d by Dmitry Kazakov. > Committed on 22/06/2022 at 12:48. > Pushed by dkazakov into branch 'krita/5.1'. > > Fix a slowdown when Shift+gestrure-resize huge and complex brushes > > This patch does two things: > > 1) Now the brush outline is generated **not** from the real brush tip, >generated by generateMaskAndApplyMaskOrCreateDab(), but from the >original brushTipImage(). It should generate the same outline, unless >any of our brush modes support changing opacity of the brush tip >(afaict, none of them support that). > > 2) The outline and pyramid caches are now shared between the source and >cloned brush tips. That is, updating a cache inside a cloned brush will >also update the cache inside the source brush (in the registry). This >decision is a bit scary, but solves really a lot of performance troubles. >The link between the two brush objects will be reset only when one of >the objects calls `cache.reset()`. > > M +19 -20 libs/brush/kis_brush.cpp > M +139 -16 libs/global/KisLazySharedCacheStorage.h > > https://invent.kde.org/graphics/krita/commit/ > bef36adac9ed3934c68431da838045041fa4a31d Hello Dmitry. Thank you for caring about the issue. There's another problem again now that the issue is fixed. I'll make another bug report for it. The problem is that some brush tips, especially the complex ones, are showing squares or rectangles instead of the actual brush outline shape. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 456080] New: Krita 5.1.0 beta 2 : outline brush shows square instead of brush tip shape.
https://bugs.kde.org/show_bug.cgi?id=456080 Bug ID: 456080 Summary: Krita 5.1.0 beta 2 : outline brush shows square instead of brush tip shape. Product: krita Version: nightly build (please specify the git hash!) Platform: Other OS: Other Status: REPORTED Severity: normal Priority: NOR Component: Brush Engine/Shape Assignee: krita-bugs-n...@kde.org Reporter: tgdev...@gmail.com Target Milestone: --- Created attachment 150226 --> https://bugs.kde.org/attachment.cgi?id=150226&action=edit outline preview square SUMMARY Krita version is 5.1.0 beta2(git 5f298d4) After the fix of huge performance drop with complex brush tips, the outline preview, started to show either literal squares or rectangle for some custom brush tips. This is an example. And I don't know why this is happening. Given that one of the most complex brush tips I have stills show up correctly, I don't think the brush tip's complexity is the issue. But anyway. Reporting this for eventual investigation. STEPS TO REPRODUCE 1. Select Krita's chalk brush tip to customize one of your pixel engine brushes 2. stay in focus on your canvas and move the cursor around OBSERVED RESULT. The outline of the cursor shows a square rather than the brush shape. EXPECTED RESULT We should observe the shape of the brush tip instead of the square. SOFTWARE/OS VERSIONS Windows: 10 21H1 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 455570] Krita plus 5.1.0 prealpha : complex brush outline causes intolerable performance lag
https://bugs.kde.org/show_bug.cgi?id=455570 stephen changed: What|Removed |Added Status|RESOLVED|REPORTED Resolution|FIXED |--- --- Comment #7 from stephen --- (In reply to Dmitry Kazakov from comment #5) > Git commit bef36adac9ed3934c68431da838045041fa4a31d by Dmitry Kazakov. > Committed on 22/06/2022 at 12:48. > Pushed by dkazakov into branch 'krita/5.1'. > > Fix a slowdown when Shift+gestrure-resize huge and complex brushes > > This patch does two things: > > 1) Now the brush outline is generated **not** from the real brush tip, >generated by generateMaskAndApplyMaskOrCreateDab(), but from the >original brushTipImage(). It should generate the same outline, unless >any of our brush modes support changing opacity of the brush tip >(afaict, none of them support that). > > 2) The outline and pyramid caches are now shared between the source and >cloned brush tips. That is, updating a cache inside a cloned brush will >also update the cache inside the source brush (in the registry). This >decision is a bit scary, but solves really a lot of performance troubles. >The link between the two brush objects will be reset only when one of >the objects calls `cache.reset()`. > > M +19 -20 libs/brush/kis_brush.cpp > M +139 -16 libs/global/KisLazySharedCacheStorage.h > > https://invent.kde.org/graphics/krita/commit/ > bef36adac9ed3934c68431da838045041fa4a31d Greetings. Also I want to say that the issue is not really fixed. Because the problem remains when the brush size is very complex or around 1700 px. But there's this brush from the moo ink bundle, called the "moo bubble". I swear that even right now, only at 150 px, it stutters a freaking lot. Because of this, I'll say that there's been an improvement but it's not really fixed completely yet. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 455570] Krita plus 5.1.0 prealpha : complex brush outline causes intolerable performance lag
https://bugs.kde.org/show_bug.cgi?id=455570 --- Comment #8 from stephen --- If possible, the cursor shouldn't stutter at all. The rendering on the canvas can be slow, but not the cursor. I tried to paint in the scratchpad and believe that the performance in the scratchpad is the expected behavior. Because of the stutter, performance in the scratchpad is much faster than on the canvas. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 455570] Krita plus 5.1.0 prealpha : complex brush outline causes intolerable performance lag
https://bugs.kde.org/show_bug.cgi?id=455570 --- Comment #10 from stephen --- (In reply to Halla Rempt from comment #9) > If you're using very big and very complex brushes, well, your computer is > going to have to do a lot of work, and it needs time to do that work: go big > and complex enough and rendering a brush outline will always become > noticeable. You probably should use one of the other cursor options if you're > using brushes like that. > > Also, it's not up to the bug reporter to re-open reports developers closed. > Please do not do that again. Sorry. I wasn't sure whether I should submit it as "reported" or leave it as it was. Though I don't think the cursor alone should cause any lag at all no matter the complexity of the brush. It's rather the dab/stroke that should be slow if the brush is too complex. The lag I observed with the "gauze brush" tip is exactly the same with the "moo bubble" tip. Even with 100 pixels, it stutters a lot. I'll be making another bug report with the brush causing the stutter. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 456172] New: Krita 5.1.0 beta 2 : complex outline causes lots of stutters on the canvas, but not the scratchpad
https://bugs.kde.org/show_bug.cgi?id=456172 Bug ID: 456172 Summary: Krita 5.1.0 beta 2 : complex outline causes lots of stutters on the canvas, but not the scratchpad Product: krita Version: nightly build (please specify the git hash!) Platform: Other OS: Other Status: REPORTED Severity: normal Priority: NOR Component: Brush Engine/Shape Assignee: krita-bugs-n...@kde.org Reporter: tgdev...@gmail.com Target Milestone: --- Created attachment 150293 --> https://bugs.kde.org/attachment.cgi?id=150293&action=edit stutter brush tip SUMMARY This brush is also complex but for some reason, even at 80-100 px, it causes stutters. Please investigate. STEPS TO REPRODUCE 1. Import the brush from the bundle 2. Paint and see if you get stutters on the canvas 3. Compare with painting in the scratchpad to see the difference OBSERVED RESULT Lots of stutters when preview outline is active EXPECTED RESULT No stutter at all with the cursor shape. Performance should be the same as on the scratchpad. SOFTWARE/OS VERSIONS Windows: 10 21H1 krita git version : 5.1.0 beta 2 3ecf7c7 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 456172] Krita 5.1.0 beta 2 : complex outline causes lots of stutters on the canvas, but not the scratchpad
https://bugs.kde.org/show_bug.cgi?id=456172 --- Comment #2 from stephen --- It is not a duplicate of the resolved bug, but another one. Shouldn't be marked as "duplicate". On Thu, Jun 30, 2022 at 6:46 PM wolthera wrote: > https://bugs.kde.org/show_bug.cgi?id=456172 > > wolthera changed: > >What|Removed |Added > > > CC||griffinval...@gmail.com > Resolution|--- |DUPLICATE > Status|REPORTED|RESOLVED > > --- Comment #1 from wolthera --- > > > *** This bug has been marked as a duplicate of bug 455570 *** > > -- > You are receiving this mail because: > You reported the bug. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 455570] Krita plus 5.1.0 prealpha : complex brush outline causes intolerable performance lag
https://bugs.kde.org/show_bug.cgi?id=455570 --- Comment #12 from stephen --- Created attachment 150306 --> https://bugs.kde.org/attachment.cgi?id=150306&action=edit stutter with the moo bubble (In reply to wolthera from comment #11) > *** Bug 456172 has been marked as a duplicate of this bug. *** I should've appended this file here along with the 1st brush causing the stutters. I imagined that the 1st fix would solve everything, but after some testing, the issue remains again on my side with this new brush. If you don't mind and would like to make Krita's brush engine more performant, here it is. (see moo-animated-brush.bundle for more investigation) -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 455570] Krita plus 5.1.0 prealpha : complex brush outline causes intolerable performance lag
https://bugs.kde.org/show_bug.cgi?id=455570 --- Comment #16 from stephen --- (In reply to Dmitry Kazakov from comment #15) > Hi, Stephen! > > I have fixed the problem that was triggered by the "moo bubble" brush. That > stutter should go now. Though I haven't even checked the part of the bug > that is related to 1700px brushes, because Krita officially doesn't support > brushes bigger that 1000px. Usage of such brushes is "at your own risk" :) Thank you a lot Dmitry ! God blesses you! Also good to know that Krita officially doesn't support brushes bigger than 1000 px. I wasn't aware of that. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 455570] Krita plus 5.1.0 prealpha : complex brush outline causes intolerable performance lag
https://bugs.kde.org/show_bug.cgi?id=455570 --- Comment #17 from stephen --- (In reply to Dmitry Kazakov from comment #15) > Hi, Stephen! > > I have fixed the problem that was triggered by the "moo bubble" brush. That > stutter should go now. Though I haven't even checked the part of the bug > that is related to 1700px brushes, because Krita officially doesn't support > brushes bigger that 1000px. Usage of such brushes is "at your own risk" :) Alright. Greetings everyone. So after a new test, using krita 5.1.0 beta2 git ef3b190, I can't say that there's a big difference. The stutters remains, even just with hovering. When I paint, and continuously paint for 10s, the cursor freezes on the canvas for those 10s and the rendering will update many seconds later after I lift my pen. It this an expected behavior ? For the gauze brush, the performance improvement is noticeable. But with this fuzzy brush, it's not there yet... -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 455570] Krita plus 5.1.0 prealpha : complex brush outline causes intolerable performance lag
https://bugs.kde.org/show_bug.cgi?id=455570 --- Comment #18 from stephen --- (In reply to Dmitry Kazakov from comment #15) > Hi, Stephen! > > I have fixed the problem that was triggered by the "moo bubble" brush. That > stutter should go now. Though I haven't even checked the part of the bug > that is related to 1700px brushes, because Krita officially doesn't support > brushes bigger that 1000px. Usage of such brushes is "at your own risk" :) To make sure my test was well performed, I double checked again. And this is my experience on Windows : 1) Hovering doesn't stutter anymore however selecting this fuzzy brush leads to considerable frame drops even just with hovering. 2) When I use my mouse to paint, the cursor doesn't freeze on the canvas, but the frame drop is even more noticeable as it increases while painting; 3) When I use my pen to paint, the cursor will freeze, the stroke will not render in real time even if it's slow, and I must wait about 3 s after I release my pen before I can see the cursor moving again and the stroke rendered on the canvas. 4) I confirm that using shift+drag is smooth, but the framerate drop of the GUI seems abnormal. So yeah. The gui's frame rate drops severly as if what is happening on the canvas is somewhat linked to GUI. Sound like a rendering issue overall. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 455570] Krita plus 5.1.0 prealpha : complex brush outline causes intolerable performance lag
https://bugs.kde.org/show_bug.cgi?id=455570
stephen changed:
What|Removed |Added
Resolution|WAITINGFORINFO |---
Status|NEEDSINFO |REPORTED
Ever confirmed|1 |0
--- Comment #24 from stephen ---
(In reply to Dmitry Kazakov from comment #19)
> Hi, @stephen!
>
> Could you please clarify, what brush do you mean by "fuzzy brush"? "moo
> bubble" or something else?
Yes Dmitry. It was the "moo bubble" brush.
(In reply to Dmitry Kazakov from comment #21)
> And one more question: does the framedrop happens **only** when **all**
> these conditions are met?
>
> 1) Some brush sensor (e.g. rotation) is set to "Fuzzy Dab", and
> 2) The framedrop happens only when the brush stroke is started and the
> ceases when the stylus is lifted from the tablet surface and starts hovering
No, there are other conditions where the framedrop happens.
One of these conditions is choosing the "moo bubble" brush and just hovering
the cursor without doing anything else.
1) When there's absolutely no sensor active, the framedrop happens(hovering
gives framedrops during the test)
2) The framedrop happens at all time as you hover the cursor.{
2.a : the framedrop is huge while painting with mouse;
2.b : the whole gui freezes when you start a stroke using your pen on Windows;
2.c : The GUI freezing won't stop if you don't lift your pen from the tablet's
surface;
2.d : The freezing goes away about 3s after you lift your pen from the tablet's
surface. }
Since there are more conditions, the answer is no.
Matter of fact, compare the following :
I. hovering the cursor of a basic round brush.
II. hovering the cursor of the "moo bubble" brush.
You'll notice that hovering in condition "I" is faster than hovering in
condition "II".
Which means, that already with just hovering, there's a framedrop on the canvas
if you pick the "moo bubble" brush.
Years ago, I reported to "halla" that the brush outline cursor would be best if
:
A. it was as fast as the system cursor, but he was apparently "too busy".
B. its color was only shifting between black/white, and stays correctly visible
no matter the color on the canvas.
But he/she had no clue about the best way to take care of the issue.
--
You are receiving this mail because:
You are watching all bug changes.
[krita] [Bug 456484] New: Krita 5.1.0 beta 2 : crash right after selecting some brushes
https://bugs.kde.org/show_bug.cgi?id=456484 Bug ID: 456484 Summary: Krita 5.1.0 beta 2 : crash right after selecting some brushes Product: krita Version: nightly build (please specify the git hash!) Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: crash Priority: NOR Component: Brush engines Assignee: krita-bugs-n...@kde.org Reporter: tgdev...@gmail.com Target Milestone: --- SUMMARY Krita git version is c111c9f. STEPS TO REPRODUCE 1. Try to select some custom brushes via your brush tags or brush palette. OBSERVED RESULT Krita crashes rapidly ! EXPECTED RESULT No crash at all. SOFTWARE/OS VERSIONS Windows 10 21H1 Additional information : Information for the crash : Error occurred on Friday, July 8, 2022 at 02:40:26. krita.exe caused an Access Violation at location 7FFC4FB1513C in module libkritalibpaintop.dll Reading from location . AddrPC Params 7FFC4FB1513C 02555D8C2510 libkritalibpaintop.dll!KisBrushBasedPaintOpSettings::paintOpSize+0x1c 7FFC509D9661 00D0039FB098 02555D8C25F0 177E libkritaui.dll!KisSizeResourceConverter::fromSource+0x51 7FFC57D8C3CB 02550416DA80 00D0039FB2D8 025556D4FE48 libkritaflake.dll!KoDerivedResourceConverter::readFromSource+0x1b 7FFC57D887E5 02550416DA80 00D0039FB158 025557C08D30 libkritaflake.dll!KoResourceManager::notifyDerivedResourcesChangeAttempted+0xc5 7FFC57D8819E 025560969E00 025506A3DA00 025506A3DCA0 libkritaflake.dll!KoResourceManager::setResource+0x2e 7FFC509D3735 02556E5F8E40 7FFC5F2AD896 00D0039FB350 libkritaui.dll!KisCanvasResourceProvider::setPaintOpPreset+0x45 7FFC50A99EC7 00D0039FB498 7FFC65C5E1C1 02556E711300 libkritaui.dll!KisPaintopBox::setCurrentPaintop+0x537 7FFC50A9B071 021E libkritaui.dll!KisPaintopBox::resourceSelected+0x4c1 7FFC50AD5B8C 02556CE62A40 02555D8BA230 7FFC506C9968 libkritaui.dll!KisFavoriteResourceManager::slotChangeActivePaintop+0xbc 7FFC4FF80868 0002039FB6A8 02550416D1D8 02550416D9E0 Qt5Core.dll!QMetaObject::activate+0x828 7FFC5089B550 00D0039FBC60 7FFC4FFA2F08 02556C516DB0 libkritaui.dll!KisPopupPalette::sigChangeActivePaintop+0x30 7FFC50AB0BE7 0001 02556C516DB0 0002 libkritaui.dll!KisPopupPalette::mouseReleaseEvent+0x77 7FFC503742D2 00A5006A 0003 00D0039FB8F0 Qt5Widgets.dll!QWidget::event+0x5f2 7FFC5033C716 04DF 4058 4058 Qt5Widgets.dll!QApplicationPrivate::notify_helper+0x106 7FFC5033F3ED Qt5Widgets.dll!QApplication::notify+0x1cad 7FFC50D59018 011001C1 3FF0 libkritaui.dll!KisApplication::notify+0xa8 7FFC4FF53323 3FF0 Qt5Core.dll!QCoreApplication::notifyInternal2+0x93 7FFC5033D001 00D0039FBF50 7FFC55363E55 012701C1 Qt5Widgets.dll!QApplicationPrivate::sendMouseEvent+0x381 7FFC5039239E 02550416D290 7FFC4FF5A0A9 40727000 Qt5Widgets.dll!QWidgetWindow::handleMouseEvent+0x88e 7FFC50390EF8 00D0039FC158 02554F39C410 0003 Qt5Widgets.dll!QWidgetWindow::event+0xc8 7FFC5033C716 012701C1 Qt5Widgets.dll!QApplicationPrivate::notify_helper+0x106 7FFC5033D92E 3FF0 00D0039FC158 Qt5Widgets.dll!QApplication::notify+0x1ee 7FFC50D59018 0255567EF2A0 7FFC4D80C333 libkritaui.dll!KisApplication::notify+0xa8 7FFC4FF53323 02E4043C 7FFC89669877 Qt5Core.dll!QCoreApplication::notifyInternal2+0x93 7FFC4D7CFDF1 0255568BB6B0 0401 Qt5Gui.dll!QGuiApplicationPrivate::processMouseEvent+0xbc1 7FFC4D7B8E5B 0029258E 0003 Qt5Gui.dll!QWindowSystemInterface::sendWindowSystemEvents+0xdb 7FFC4FFA5093 0001 0001 Qt5Core.dll!qt_internal_proc+0x253 7FFC8932E858 3DFF 7FFC4FFA4E40 0029258E USER32.dll!UserCallWinProcCheckWow+0x2f8 7FFC8932E299 7FFC4FFA4E40 0001 USER32.dll!DispatchMessageWorker+0x249 7FFC4FFA659B 02554F39C410 025560FB0F60 00D0039FF8B8 Qt5Core.dll!QEventDispatcherWin32::processEvents+0x7cb 7FFC553C3795 00D0039FF8B8 00D0039FF960 qwindows.dll!QWindowsGuiEventDispatcher::processEvents+0x15 7FFC4FF50175 02550002 02550002 02554FD34620 Qt5Core.dll!QEventLoop::exec+0x1e5 7FFC4FF5399D 00D0
[krita] [Bug 455570] Krita plus 5.1.0 prealpha : complex brush outline causes intolerable performance lag
https://bugs.kde.org/show_bug.cgi?id=455570 stephen changed: What|Removed |Added Resolution|WAITINGFORINFO |--- Status|NEEDSINFO |REPORTED --- Comment #29 from stephen --- (In reply to Dmitry Kazakov from comment #27) > Hi, Stephen! > > > [...] the brush outline cursor would be best if : > > A. it was as fast as the system cursor > > It is technically impossible to make the brush outline to be as fast as the > system cursor. The outline of the brush will always be slower than the > cursor. The reason is easy: the cursor is painted with a special fast-path > routine by hardware. And the brush outline is painted by software alongside > the canvas painting. We can make it "faster" to some extent, but it will > always be several frames slower than the hardware cursor. > > > its color was only shifting between black/white, and stays correctly > > visible no matter the color on the canvas. > > That's a different issue, let's not drift from the main topic :) > > For Stephen and Protoniv: > > I'm afraid I cannot reproduce the regression you report. I tried the two > brushes described by Protoniv and both of them work fine with with mouse, > stylus+winink, stylus+wintab on Windows. > > The video on the forum looks as if Krita has the "Thread limit" set to '1' > in the performance preferences. Could you try resetting Krita settings and > recheck? > > https://docs.krita.org/en/KritaFAQ.html#resetting-krita-configuration Hello Dmitry. So, I've reset my settings as suggested, but using the stylus, it's the same. On my side, the cursor gets stuck while painting with stylus+Wintab and stylus+WinInk. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 458760] New: Annoying glitchy vector handles with select shape tool(noticeable with layer style rendering on)
https://bugs.kde.org/show_bug.cgi?id=458760
Bug ID: 458760
Summary: Annoying glitchy vector handles with select shape
tool(noticeable with layer style rendering on)
Product: krita
Version: git master (please specify the git hash!)
Platform: Microsoft Windows
OS: Microsoft Windows
Status: REPORTED
Severity: normal
Priority: NOR
Component: Layers/Vector
Assignee: krita-bugs-n...@kde.org
Reporter: tgdev...@gmail.com
Target Milestone: ---
SUMMARY
Krita version is 5.1.0 nightly (git 43f0ae3)
The vector handles behave in a weird manner as soon as you release mouse or pen
click(noticeable with stroke rendering on(they stay glued to the mouse movement
after you release your click, and stick for about 1-3 seconds.
STEPS TO REPRODUCE
1. create a new vector layer
2. insert a vector rectangle with white background fill
3. on the vector layer, activate the following layer style options(like json,
but not really json) :
{ "stroke" : {
"Structure" : {
"size" : 12,
"size_unit" : "px",
"Position" : "Outside",
"Blend_Mode" : "Normal",
"opacity" : 100,
"opacity_unit" : "%"
},
"Fill" : {
"Type" : {
"color" : {"hex" : "#000"},
"label" : black
}
}
}
}
4. using the "Select Shapes Tool", modify the shape of the rectangle a few
times by dragging the sides or vertices.
5. also using the "Select shapes tool", try moving the rectangle shape a bit,
then release click while continuing to hover the cursor rapidly.
OBSERVED RESULT
1. dragging the middle handle or vertices casually causes a glitchy gap between
cursor and rectangle once you release mouse or pen click.
2. soon after you release pen click, the rectangle or rectangle handles stick
to the cursor movement for about 2-5 seconds depending on the
circumstances(moving constantly right after click is released)
3. Krita shows "waiting for image operation to complete" if you move constantly
your cursor.
EXPECTED RESULT
1. no glitchy gap from cursor right after you release mouse or pen click after
dragging the corner of the shapes or after moving the shapes with the shapes
tool.
2. Right after you release your click drag, the rectangle should not pursue
your cursor movement and instead stop at the position you released it
SOFTWARE/OS VERSIONS
Windows 10 21H1
--
You are receiving this mail because:
You are watching all bug changes.
[krita] [Bug 442098] New: Krita 5.1.0 prealpha :Ten Brushes, can't switch back to previous preset after pressing key twice
https://bugs.kde.org/show_bug.cgi?id=442098 Bug ID: 442098 Summary: Krita 5.1.0 prealpha :Ten Brushes, can't switch back to previous preset after pressing key twice Product: krita Version: git master (please specify the git hash!) Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: normal Priority: NOR Component: Shortcuts and Canvas Input Settings Assignee: krita-bugs-n...@kde.org Reporter: tgdev...@gmail.com Target Milestone: --- SUMMARY Issue about the ten brushes feature. Something is wrong with switching back to previous brush preset. Krita version is 5.1.0 pre alpha nighly build(git 8376871). If it's not a bug, just proceed to the appropriate action. STEPS TO REPRODUCE 1. Have a specific brush set for any of the ten brushes shortcut 2. With a canvas opened, press on one of the ten brushes shortcut 3. Press the same shortcut a second time OBSERVED RESULT The brush doesn't switch back to the previous preset EXPECTED RESULT Pressing the second time one of the shortcuts should switch back your current preset to the previous pne SOFTWARE/OS VERSIONS Windows 10 1909 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 442098] Krita 5.1.0 prealpha :Ten Brushes, can't switch back to previous preset after pressing key twice
https://bugs.kde.org/show_bug.cgi?id=442098 stephen changed: What|Removed |Added Resolution|WORKSFORME |--- Status|RESOLVED|REPORTED --- Comment #2 from stephen --- (In reply to Halla Rempt from comment #1) > That works for me. Are you sure ? That doesn't work for me. I tried installing this version of Krita again but nope. So how do I make it works here. Saying that it works on your side isn't helping. This is the name of the setup file : krita-nightly-x64-5.1.0-prealpha-8376871fce-setup Also, what to do when it becomes "Resolved" "works for you" while it doesn't work for some other ? Should I even turn the status as "Reported" ? -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 442198] New: Krita 5.1.0 prealpha(git 8376871) : brush texture blending modes not behaving correctly
https://bugs.kde.org/show_bug.cgi?id=442198 Bug ID: 442198 Summary: Krita 5.1.0 prealpha(git 8376871) : brush texture blending modes not behaving correctly Product: krita Version: git master (please specify the git hash!) Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: normal Priority: NOR Component: Brush engines Assignee: krita-bugs-n...@kde.org Reporter: tgdev...@gmail.com Target Milestone: --- SUMMARY An issue about brush textures blending modes. STEPS TO REPRODUCE 1. Open the brush settings panel 2. tick on pattern 3. select different texture blending modes and see how they affect stroke rendering 4. Try painting as well OBSERVED RESULT The stroke doesn't seem changed at all according to the active blending mode. EXPECTED RESULT The active brush pattern/texture blending modes should properly affect the rendering of the stroke. SOFTWARE/OS VERSIONS Windows 10 1909 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 442098] Krita 5.1.0 prealpha :Ten Brushes, can't switch back to previous preset after pressing key twice
https://bugs.kde.org/show_bug.cgi?id=442098 --- Comment #4 from stephen --- (In reply to Halla Rempt from comment #3) > No, only developers should change the status of a bug. > > Resolved/Worksforme means: it works for me, I cannot investigate this report > anymore since there's nothing left for me to try and test or debug. Then I shall forward a screen recording of the issue at the very least. Just so that you understand it's really not working on my side. It doesn't happen with the first Krita 5.0.0 beta, but with the current 5.1.0 prealpha and current 5.0.0 beta builds, switching back to previous preset is not possible anymore. Recording video will be forwarded in the next message. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 442198] Krita 5.1.0 prealpha(git 8376871) : brush texture blending modes not behaving correctly
https://bugs.kde.org/show_bug.cgi?id=442198 --- Comment #2 from stephen --- (In reply to wolthera from comment #1) > Sorry, that seems to work here. I am afraid you'll have to include a picture. Here are the pictures : https://drive.google.com/file/d/1AQRN4XD_8XVM5j7syEjVWknSwR0EZJci/view?usp=sharing https://drive.google.com/file/d/1zECwQTnDdFPhZjxPJ-qvRraHQZGzKkhm/view?usp=sharing https://drive.google.com/file/d/1nmXqql_neKVUok-b2w4SHcXD9FsyEIHo/view?usp=sharing https://drive.google.com/file/d/1hfBoxXYJD9bo2CEa0fVhAJxvjLjRiPQB/view?usp=sharing https://drive.google.com/file/d/12oNtQjefu4eqRNZ1wPja6CP2zhufPUZf/view?usp=sharing https://drive.google.com/file/d/1luJMwWsMJkh-sysoEJKm-piiwKkbqYpa/view?usp=sharing -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 442198] Krita 5.1.0 prealpha(git 8376871) : brush texture blending modes not behaving correctly
https://bugs.kde.org/show_bug.cgi?id=442198 --- Comment #6 from stephen --- (In reply to wolthera from comment #5) > No, we can't seem to reproduce it here on windows either... I am afraid that > there's something else that is not mentioned in the report that's affecting > it. Perhaps a super low spacing, or something else? Even with super low spacing, the blending modes change the stroke rendering quite well. Also, know that the brush used, with the same exact settings, renders and shows well in the v5.0.0 beta 1 version of Krita. No problems with this build. But for some reason, in 5.1.0 prealpha, two things went wrong : Incorrect/inactive texture blending mode, and switching back to previous brush preset seems to never work, because... the brush preset history is deactivated or something like that. I already created a bug report for the latter. Answer was : "worksforme" while it actually doesn't work here. In any case, this is very weird. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 442493] New: Krita 5.0.0 beta 1 (git 5d81078)
https://bugs.kde.org/show_bug.cgi?id=442493 Bug ID: 442493 Summary: Krita 5.0.0 beta 1 (git 5d81078) Product: krita Version: git master (please specify the git hash!) Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: normal Priority: NOR Component: General Assignee: krita-bugs-n...@kde.org Reporter: tgdev...@gmail.com Target Milestone: --- SUMMARY Now it's not just the 5.1.0 prealpha version, but this one too. Switching back to previous brush preset won't work with the Ten brushes script. STEPS TO REPRODUCE 1. Select a brush different from the ones configured according in your ten brushes slots. 2. Simply try to press any configured shortcut of the ten brushes script twice. OBSERVED RESULT The brush doesn't switch back to previous preset after the key is pressed twice. EXPECTED RESULT Should switch back to previous preset. OS : Windows 10 1909 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 442098] Krita 5.1.0 prealpha :Ten Brushes, can't switch back to previous preset after pressing key twice
https://bugs.kde.org/show_bug.cgi?id=442098 stephen changed: What|Removed |Added Resolution|WORKSFORME |--- Status|RESOLVED|REPORTED --- Comment #5 from stephen --- (In reply to Halla Rempt from comment #3) > No, only developers should change the status of a bug. > > Resolved/Worksforme means: it works for me, I cannot investigate this report > anymore since there's nothing left for me to try and test or debug. New update : The issue seems to be caused from the retrieval of brush settings from the sqlite database of a previous Krita version. Especially coming from 5.0.0 beta 1 to later versions. A break happens in the process apparently, causing the brush history to not work as expected with the Ten brushes script. I tried to completely remove any sqlite backup before starting Krita and the ten brushes script worked fine. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 451072] New: Krita 5.1.0 prealpha : issue with the color indicator from the options bar in mask mode
https://bugs.kde.org/show_bug.cgi?id=451072 Bug ID: 451072 Summary: Krita 5.1.0 prealpha : issue with the color indicator from the options bar in mask mode Product: krita Version: nightly build (please specify the git hash!) Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: minor Priority: NOR Component: General Assignee: krita-bugs-n...@kde.org Reporter: tgdev...@gmail.com Target Milestone: --- Created attachment 147253 --> https://bugs.kde.org/attachment.cgi?id=147253&action=edit Maskmode color indicator issue SUMMARY There's an issue with the color indicator on the option bar when you paint in mask mode( check image for reference ). STEPS TO REPRODUCE 1. paint data on a new layer 2. apply transparency mask or any mask you'd like 3. highlight the mask layer in the layer stack 4. With black vs white selected as primary and secondary colors, try to paint/erase the mask OBSERVED RESULT The primary/secondary color indicator on the option bar fails to show white color when you pick white color and shows dark grey instead of white. EXPECTED RESULT selecting white color should update the color indicator on the option bar and show white on it instead of dark grey. SOFTWARE/OS Windows 10 21H1 Krita : 5.1.0 prealpha git 63935b8 -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 456813] New: "Colour corrections "is spelt color correction in the British English version of Fedora KDE
https://bugs.kde.org/show_bug.cgi?id=456813 Bug ID: 456813 Summary: "Colour corrections "is spelt color correction in the British English version of Fedora KDE Product: systemsettings Version: 5.25.3 Platform: Fedora RPMs OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: stephen.james.he...@gmail.com Target Milestone: --- SUMMARY *** NOTE: If you are reporting a crash, please try to attach a backtrace with debug symbols. See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** STEPS TO REPRODUCE 1. install KDE Fedora with British English selected 2. Click Quick Settings 3. "Colour Corrections" is displayed as "Color Corrections" Other uses of Colour within the distro are the correct British Spelling. OBSERVED RESULT "Colour Corrections" is spelt Color Corrections in the British English version of FedoraKDE EXPECTED RESULT "Color Corrections" should be changed to "Colour Corrections" SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 457123] New: Krita 5.1.0 beta2 : crash after reading a recently opened PSD file
https://bugs.kde.org/show_bug.cgi?id=457123 Bug ID: 457123 Summary: Krita 5.1.0 beta2 : crash after reading a recently opened PSD file Product: krita Version: nightly build (please specify the git hash!) Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: crash Priority: NOR Component: General Assignee: krita-bugs-n...@kde.org Reporter: tgdev...@gmail.com Target Milestone: --- ADDITIONAL INFORMATION Krita version : 5.1.0 beta 2 git e91e5d4) SUMMARY For some reason Krita crashes a few seconds after it tries to read a psd file to show its thumbnail. I say psd because, I tried to remove the path of the psd file in kritarc file and the issue ceased. For investigation here's a link to the psd file Krita was trying to read. https://www.mediafire.com/file/8u4ghi4ecst70ze/adfasdf2-1.zip/file STEPS TO REPRODUCE 1. Open the psd file with Krita for the 1st time 2. Close the psd file and close Krita completely. 3. Start Krita again OBSERVED RESULT Krita shows the main GUI then crashes a few seconds after EXPECTED RESULT No crash at all after reading the content of a psd file SOFTWARE/OS VERSIONS Windows 10 21H1 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 457125] New: Krita 5.1.0 beta 2 git e91e5d4 : crash right after undoing a text insertion
https://bugs.kde.org/show_bug.cgi?id=457125 Bug ID: 457125 Summary: Krita 5.1.0 beta 2 git e91e5d4 : crash right after undoing a text insertion Product: krita Version: nightly build (please specify the git hash!) Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: crash Priority: NOR Component: Tool/Text Assignee: krita-bugs-n...@kde.org Reporter: tgdev...@gmail.com Target Milestone: --- SUMMARY Krita crashes right after undoing a text insertion STEPS TO REPRODUCE 1. in a newly opened document, insert a new text 2. undo your text insertion OBSERVED RESULT Krita crashes right after undoing the text insertion EXPECTED RESULT *No crash *The text should disappear from the canvas once undone SOFTWARE/OS VERSIONS Windows 10 21H1 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 455570] Krita plus 5.1.0 prealpha : complex brush outline causes performance lag
https://bugs.kde.org/show_bug.cgi?id=455570 --- Comment #31 from stephen --- (In reply to Dmitry Kazakov from comment #27) > Hi, Stephen! > > > [...] the brush outline cursor would be best if : > > A. it was as fast as the system cursor > > It is technically impossible to make the brush outline to be as fast as the > system cursor. The outline of the brush will always be slower than the > cursor. The reason is easy: the cursor is painted with a special fast-path > routine by hardware. And the brush outline is painted by software alongside > the canvas painting. We can make it "faster" to some extent, but it will > always be several frames slower than the hardware cursor. > > > its color was only shifting between black/white, and stays correctly > > visible no matter the color on the canvas. > > That's a different issue, let's not drift from the main topic :) Hello Dmitry and Krita devs. Hope you're well. It's not the main topic, but I want to encourage you by saying that it's not technically impossible to make the outline cursor as fast as the system cursor. I believe one solution is to target the function that renders the system cursor, and modify it from Krita by inserting the code logic which draws the brush outline shape in it. This code logic would work in a way that, the outline shape is rendered when the cursor hovers in Krita's viewport area, obviously yes, you probably know this one already. Well... if you can use a custom brush cursor icon, then I believe there's a way. The research required for it would probably consist of finding out, how you can use the hardware fast path routine and hack it in a certain way though. Now, I don't know what exactly are the limits of this method given the available tools in your hands. So there might be another technical constraint I'm not aware of. Just saying. Thank you for your hard work. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 455570] Krita plus 5.1.0 prealpha : complex brush outline causes performance lag
https://bugs.kde.org/show_bug.cgi?id=455570 --- Comment #33 from stephen --- Created attachment 151140 --> https://bugs.kde.org/attachment.cgi?id=151140&action=edit Tablet_log (In reply to Dmitry Kazakov from comment #32) > Hi, Stephen! > > Could you please reply to my questions above? I want to understand whether > this bug can be closed or not, since none of us can reproduce this issue. > > PS: > > About the hardware cursors: > > 1) Hardware cursors are usually limited to 32 pixels in size > 2) They are not dynamic (and our outlines dynamically change their shape > depending on the state of the sensors) > > If you want to use hardware cursor, just activate "small circle" cursor in > Krita settings. It will be hardware-optimized and fast. Hello Dmitry. You're definitely right. No matter what is done, it's impossible to perfectly match the system cursor speed. >From your return, I decided to make one last test and use CSP to see if it would display the brush cursor shape given that it also possesses the feature in its latest release. Turns out that even without GPU, the software is able to show it. And I noticed that there's like a two to 8 pixels distance between the brush cursor and the system cursor in Clip Studio when I hover with very high speed. In conclusion, their code is either very well optimized or they use a lower level approach to make the cursor very very fast. Still with both my integrated and dedicated GPUs disabled, with a big enough brush size, CSP starts to drop a lot of frames while painting. So it's all up to software solution then. Debate can be closed now. Thank you again for being informative. Now to answer your above questions : 1. Before the tablet log, no the "basic-5-size" brush works fine, be it with stylus or mouse. 2. With the tablet log on : I couldn't even do anything. Hovering freezes the software with the use of the stylus. Painting with stylus also freezes the software. Software won't stop getting frozen until I stop using stylus or stop putting stylus in detection range. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 430605] Bug : Deselecting a selection has often a long processing time(can have to wait for up to 30s or more before it finishes)
https://bugs.kde.org/show_bug.cgi?id=430605 stephen changed: What|Removed |Added Status|NEEDSINFO |REPORTED Resolution|WAITINGFORINFO |--- --- Comment #3 from stephen --- (In reply to Tiar from comment #1) > What size was your canvas? Can you maybe make a video? > > I cannot reproduce it. It's always instant on my system. I am on Windows 10. Not Linux. As for the additional information, it happens at random just after you apply a transform or move operation on the contained pixels in the selection area. Then try to deselect afterwards using CTRL+D. When it happens, selection continue to stay still for a while and you're temporarily stuck with it. Sometimes there's no way to cancel it even by using CTRL+Z to undo. Which makes me think about something. If some operations are meant to force the user to wait, then at least, provide a dialog window with a progress bar or progress gauge showing the percentage of the progress of a given operation or task. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 430605] Bug : Deselecting a selection has often a long processing time(can have to wait for up to 30s or more before it finishes)
https://bugs.kde.org/show_bug.cgi?id=430605 --- Comment #5 from stephen --- (In reply to Tiar from comment #4) > I guess that might be because it's waiting for the transformation to finish. Then optimizations are awaited. Better ergonomics as well : a loading gauge that shows the progress of the operation from 0 to 100% before allowing the user to interact with the app again. The chances for the bug to happen are high when you quickly move pixels in a selected area to a different position then immediately deselect. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 430605] Bug : Deselecting a selection has often a long processing time(can have to wait for up to 30s or more before it finishes)
https://bugs.kde.org/show_bug.cgi?id=430605 --- Comment #6 from stephen --- (In reply to Tiar from comment #4) > I guess that might be because it's waiting for the transformation to finish. It's official. The long and very long and unbearable delay always and always happens after you move the content of a selection area. 100% frustrating moment. And other than this, moving the contained pixels in the selection area leaves glitches on the canvas if you move continuously without stopping. Krita really really should be optimized. * The brush engine should be optimized to render faster with very big pixel size(100-2000 pixels) * There shouldn't be any artifact/glitch when changing colors through adjustment filters, while hiding/showing a layer, while painting...etc * Any selection tool, for a move operation should only target the contained non null pixels in a selection area and thus reduce the size of the selection area... * No more artifacts/glitches/super long delays while operating transformations on pixels in a layer(always target big data size to optimize things, a 5000x5000 canvas resolution is recommended for things like that). Please, optimize Krita much much deeper to improve workflow speed for professional artists and Krita users in general. We need this to happen. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 430605] Bug : Deselecting a selection has often a long processing time(can have to wait for up to 30s or more before it finishes)
https://bugs.kde.org/show_bug.cgi?id=430605 stephen changed: What|Removed |Added Status|RESOLVED|REPORTED Resolution|NOT A BUG |--- --- Comment #8 from stephen --- (In reply to Halla Rempt from comment #7) > Performance complaints are not suitable for bug reports. Closing this. Have you checked whether it's a bug or not very first ? Reopening this. Please, close this after you have checked. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 430605] Bug : Deselecting a selection has often a long processing time(can have to wait for up to 30s or more before it finishes)
https://bugs.kde.org/show_bug.cgi?id=430605 --- Comment #10 from stephen --- (In reply to Halla Rempt from comment #9) > As maintainer of Krita I have determined that your report does not contain > useful information that can be used to resolve an in issue in Krita's code, > so it's not a bug report. > > Do not reopen bugs if you're not a developer: if you do that again, I will > ask sysadmin to remove your bugzilla account. Fine. I'd like to ask. About the glitches/artifacts that continuously appear on the canvas while moving sleceted raster data, is this not a bug as well ? -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 382876] Copy/Paste Layer Styles
https://bugs.kde.org/show_bug.cgi?id=382876 stephen changed: What|Removed |Added CC||tgdev...@gmail.com --- Comment #5 from stephen --- Yes, copy/paste layer styles is a must at this point. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 405643] Feature request: circle in a square assistant tool
https://bugs.kde.org/show_bug.cgi?id=405643 stephen changed: What|Removed |Added CC||tgdev...@gmail.com --- Comment #5 from stephen --- (In reply to wolthera from comment #1) > Okay, so what you effectively want is a readjustable 4 corner mesh that > always has a circle inside it which touch the sides? (In reply to Hector from comment #4) > Created attachment 122943 [details] > from getleonardo.com Greetings. Here's an article with demo showing another use case of the feature : having it in perspective and move it according to distance in space. You might take a look. https://lazynezumi.com/perspectiveEllipse -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 426523] New: Bug with the outline selection tool for advanced selection technique
https://bugs.kde.org/show_bug.cgi?id=426523 Bug ID: 426523 Summary: Bug with the outline selection tool for advanced selection technique Product: krita Version: unspecified Platform: unspecified OS: All Status: REPORTED Severity: normal Priority: NOR Component: Tools/Selection Assignee: krita-bugs-n...@kde.org Reporter: tgdev...@gmail.com Target Milestone: --- SUMMARY 1) This bug is about the outline selection tool. But first, I want to recall that using the polyline tool, it's still not possible to switch to the outline selection using modifier keys while drawing the perimeter of the selection area. And changing the parameters of this selection tool isn't possible in the settings menu. Alright. So the bug manifests as follows : with a first selection area active, it's impossible to add a new one should you switch to the polyline tool as you draw the new perimeter of the additional selection area. Because doing so results in an unexpected behavior which either cancels all the selection areas, or cancels the new perimeter you draw. The only way so far to add multiple selection areas is to avoid the use of the CTRL modifier key, meaning that you can't switch to the polyline tool after your first selection area is done STEPS TO REPRODUCE 1. Create a selection area with the outline selection tool 2. Try to build a new selection area to add, but make sure you hold CTRL key to try switching to the polyline tool as you draw it. OBSERVED RESULT The new area refuses to be added/subtracted or all your selections areas are dismissed. So CTRL modifier key = cancellation for add/subtract use cases. Not good. EXPECTED RESULT The new area should be added/subtracted depending on the modifier key you held before releasing your pen/mouse, or before committing your selection area. SOFTWARE/OS VERSION Windows 10 1909 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 424319] Modifier shortcut keys stop working
https://bugs.kde.org/show_bug.cgi?id=424319 --- Comment #12 from stephen --- 1) Pen pressure still works when it happens and you can paint with the stylus. 2) Modifier keys do nothing when the issue occurs and no, the brush cursor doesn't change. 3) As for the API I was using WinTab. On Sep 16, 2020 20:50, "Dmitry Kazakov" wrote: https://bugs.kde.org/show_bug.cgi?id=424319 --- Comment #11 from Dmitry Kazakov --- And one more question: 3) Did you use tablet or mouse? If tablet, what API you have activated in Preferences->Tablet, WinTab or WinInk? -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 426790] New: Request : Noise and Density features for both basic and custom brushes
https://bugs.kde.org/show_bug.cgi?id=426790 Bug ID: 426790 Summary: Request : Noise and Density features for both basic and custom brushes Product: krita Version: 4.3.0-beta2 Platform: unspecified OS: All Status: REPORTED Severity: wishlist Priority: NOR Component: Brush engines Assignee: krita-bugs-n...@kde.org Reporter: tgdev...@gmail.com Target Milestone: --- SUMMARY Greetings. This is a feature request for the brush engine. We would like to have Density setting available for both basic and custom brushes. But also another feature I would call Noise. Except that this one puts slight value changes inside your stroke paint and edges to reinforce their natural feel. It's almost unnoticeable from far away, but is very obvious when zoomed in. When combined with the basic soft brushes, the noise is even more noticeable. The soft brush' gradient becomes very noisy and lesser and lesser dense the more we get away from the center of the brush tip shape. Photoshop has it and it helps to reinforce the natural feel of your paint strokes. Looking forward to having a similar thing in Krita. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 426833] New: Feature request : APPLY PAINT TEXTURE PER TIP, new blending modes in brush texture settings, new brush engine : watercolor.
https://bugs.kde.org/show_bug.cgi?id=426833 Bug ID: 426833 Summary: Feature request : APPLY PAINT TEXTURE PER TIP, new blending modes in brush texture settings, new brush engine : watercolor. Product: krita Version: 4.3.0-beta2 Platform: unspecified OS: All Status: REPORTED Severity: wishlist Priority: NOR Component: Brush engines Assignee: krita-bugs-n...@kde.org Reporter: tgdev...@gmail.com Target Milestone: --- SUMMARY 1 ) APPLY PAINT TEXTURE PER TIP Allow the texture used for the paint strokes to be applied per tip, which means it would overlap itself as the paint is built. 2 ) NEW BLENDING MODES IN BRUSH TEXTURE SETTINGS : Blend modes for the texture applied to paint strokes : Height, linear height, Outline(like in Clip Studio), Burn, Overlay, Hard Mix. 3 ) NEW BRUSH ENGINE : WATERCOLOR Brush engine that enable wet edges; it would include an option to adjust edge width inside a stroke and texture density(paint opacity becomes more lighter the more it's dense, and darker the less dense it is). -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 426833] Feature request : APPLY PAINT TEXTURE PER TIP, new blending modes in brush texture settings, new brush engine : watercolor.
https://bugs.kde.org/show_bug.cgi?id=426833 --- Comment #2 from stephen --- Ah, the caps ! My bad, shouting is definitely not the purpose. On Sep 22, 2020 08:24, "Boudewijn Rempt" wrote: > https://bugs.kde.org/show_bug.cgi?id=426833 > > Boudewijn Rempt changed: > >What|Removed |Added > > > Resolution|--- |NOT A BUG > CC||b...@valdyas.org > Status|REPORTED|RESOLVED > > --- Comment #1 from Boudewijn Rempt --- > Sorry, but making feature requests doesn't work like this. Please read > https://docs.krita.org/en/untranslatable_pages/new_features.html first. > Oh, and > don't use ALL CAPS: that's shouting. > > -- > You are receiving this mail because: > You reported the bug. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 424319] Modifier shortcut keys stop working
https://bugs.kde.org/show_bug.cgi?id=424319 --- Comment #18 from stephen --- (In reply to Dmitry Kazakov from comment #17) > Hi, Stephen and Dummsaccs! > > Could you please test the packages I added in this comment? :) > > https://bugs.kde.org/show_bug.cgi?id=424319#c13 Oh, ok. I'll do tests. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 427080] New: Bug : Inconsistent functionality of the line tool
https://bugs.kde.org/show_bug.cgi?id=427080 Bug ID: 427080 Summary: Bug : Inconsistent functionality of the line tool Product: krita Version: 4.4.0-beta1 Platform: unspecified OS: Microsoft Windows Status: REPORTED Severity: normal Priority: NOR Component: Tools Assignee: krita-bugs-n...@kde.org Reporter: tgdev...@gmail.com Target Milestone: --- Created attachment 131991 --> https://bugs.kde.org/attachment.cgi?id=131991&action=edit Inconsistent line tracing with line tool SUMMARY I'm using a Krita plus build version 4.4.1 alpha(git b20cb06) There's a bug with the line tool. STEPS TO REPRODUCE 1. Select the line tool either by holding V button or by clicking on the tool icon. 2. Start painting, trace, then release. 3. Repeat step 2 multiples times to see what happens. OBSERVED RESULT Tracing lines is inconsistent. There are typical failures : either only part of the distance is traced, or nothing happens, even at full pen pressure. EXPECTED RESULT Consistent and correct lines traced according to pen pressure and distance between the starting point and the final point. OS Version : Windows 10 1909 ADDITIONAL INFORMATION Krita Version: 4.4.1-alpha (git b20cb06) Languages: en_US, en, en_US, en, en_US, en, en_US, en, en_US, en, en_US, en, en_US, en, en_US, en, en_US, en Hidpi: false Qt Version (compiled): 5.12.9 Version (loaded): 5.12.9 OS Information Build ABI: x86_64-little_endian-llp64 Build CPU: x86_64 CPU: x86_64 Kernel Type: winnt Kernel Version: 10.0.18363 Pretty Productname: Windows 10 (10.0) Product Type: windows Product Version: 10 OpenGL Info Vendor: "Google Inc." Renderer: "ANGLE (NVIDIA GeForce GT 640M Direct3D11 vs_5_0 ps_5_0)" Version: "OpenGL ES 3.0 (ANGLE 2.1.0.57ea533f79a7)" Shading language: "OpenGL ES GLSL ES 3.00 (ANGLE 2.1.0.57ea533f79a7)" Requested format: QSurfaceFormat(version 3.0, options QFlags(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::DoubleBuffer, swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile QSurfaceFormat::CompatibilityProfile) Current format:QSurfaceFormat(version 3.0, options QFlags(), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples 0, swapBehavior QSurfaceFormat::DefaultSwapBehavior, swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile QSurfaceFormat::NoProfile) Version: 3.0 Supports deprecated functions false is OpenGL ES: true QPA OpenGL Detection Info supportsDesktopGL: true supportsAngleD3D11: true isQtPreferAngle: true Hardware Information GPU Acceleration: angle Memory: 12126 Mb Number of Cores: 4 Swap Location: C:/Users/Yed/AppData/Local/Temp Current Settings Current Swap Location: C:/Users/Yed/AppData/Local/Temp Current Swap Location writable: true Undo Enabled: true Undo Stack Limit: 400 Use OpenGL: true Use OpenGL Texture Buffer: true Use AMD Vectorization Workaround: false Canvas State: OPENGL_SUCCESS Autosave Interval: 300 Use Backup Files: true Number of Backups Kept: 1 Backup File Suffix: ~ Backup Location: Same Folder as the File Backup Location writable: false Use Win8 Pointer Input: false Use RightMiddleTabletButton Workaround: false Levels of Detail Enabled: false Use Zip64: false Display Information Number of screens: 1 Screen: 0 Name: \\.\DISPLAY1 Depth: 32 Scale: 1 Resolution in pixels: 1600x900 Manufacturer: Model: Refresh Rate: 60 Current Settings Current Swap Location: C:/Users/Yed/AppData/Local/Temp Current Swap Location writable: true Undo Enabled: true Undo Stack Limit: 400 Use OpenGL: true Use OpenGL Texture Buffer: true Use AMD Vectorization Workaround: false Canvas State: OPENGL_SUCCESS Autosave Interval: 300 Use Backup Files: true Number of Backups Kept: 1 Backup File Suffix: ~ Backup Location: Same Folder as the File Backup Location writable: false Use Win8 Pointer Input: false Use RightMiddleTabletButton Workaround: false Levels of Detail Enabled: false Use Zip64: false -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 427080] Bug : Inconsistent functionality of the line tool
https://bugs.kde.org/show_bug.cgi?id=427080 --- Comment #1 from stephen --- (In reply to stephen from comment #0) > Created attachment 131991 [details] > Inconsistent line tracing with line tool > > SUMMARY > I'm using a Krita plus build version 4.4.1 alpha(git b20cb06) > There's a bug with the line tool. > > STEPS TO REPRODUCE > 1. Select the line tool either by holding V button or by clicking on the > tool icon. > 2. Start painting, trace, then release. > 3. Repeat step 2 multiples times to see what happens. > > OBSERVED RESULT > Tracing lines is inconsistent. There are typical failures : either only part > of the distance is traced, or nothing happens, even at full pen pressure. > > EXPECTED RESULT > Consistent and correct lines traced according to pen pressure and distance > between the starting point and the final point. > > OS Version : Windows 10 1909 > > ADDITIONAL INFORMATION > Krita > > Version: 4.4.1-alpha (git b20cb06) > Languages: en_US, en, en_US, en, en_US, en, en_US, en, en_US, en, en_US, > en, en_US, en, en_US, en, en_US, en > Hidpi: false > > Qt > > Version (compiled): 5.12.9 > Version (loaded): 5.12.9 > > OS Information > > Build ABI: x86_64-little_endian-llp64 > Build CPU: x86_64 > CPU: x86_64 > Kernel Type: winnt > Kernel Version: 10.0.18363 > Pretty Productname: Windows 10 (10.0) > Product Type: windows > Product Version: 10 > > OpenGL Info > > Vendor: "Google Inc." > Renderer: "ANGLE (NVIDIA GeForce GT 640M Direct3D11 vs_5_0 ps_5_0)" > Version: "OpenGL ES 3.0 (ANGLE 2.1.0.57ea533f79a7)" > Shading language: "OpenGL ES GLSL ES 3.00 (ANGLE 2.1.0.57ea533f79a7)" > Requested format: QSurfaceFormat(version 3.0, options > QFlags(DeprecatedFunctions), depthBufferSize > 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, > stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::DoubleBuffer, > swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile > QSurfaceFormat::CompatibilityProfile) > Current format:QSurfaceFormat(version 3.0, options > QFlags(), depthBufferSize 24, redBufferSize 8, > greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, > samples 0, swapBehavior QSurfaceFormat::DefaultSwapBehavior, swapInterval 0, > colorSpace QSurfaceFormat::DefaultColorSpace, profile > QSurfaceFormat::NoProfile) > Version: 3.0 > Supports deprecated functions false > is OpenGL ES: true > > QPA OpenGL Detection Info > supportsDesktopGL: true > supportsAngleD3D11: true > isQtPreferAngle: true > > Hardware Information > > GPU Acceleration: angle > Memory: 12126 Mb > Number of Cores: 4 > Swap Location: C:/Users/Yed/AppData/Local/Temp > > Current Settings > > Current Swap Location: C:/Users/Yed/AppData/Local/Temp > Current Swap Location writable: true > Undo Enabled: true > Undo Stack Limit: 400 > Use OpenGL: true > Use OpenGL Texture Buffer: true > Use AMD Vectorization Workaround: false > Canvas State: OPENGL_SUCCESS > Autosave Interval: 300 > Use Backup Files: true > Number of Backups Kept: 1 > Backup File Suffix: ~ > Backup Location: Same Folder as the File > Backup Location writable: false > Use Win8 Pointer Input: false > Use RightMiddleTabletButton Workaround: false > Levels of Detail Enabled: false > Use Zip64: false > > > Display Information > Number of screens: 1 > Screen: 0 > Name: \\.\DISPLAY1 > Depth: 32 > Scale: 1 > Resolution in pixels: 1600x900 > Manufacturer: > Model: > Refresh Rate: 60 > > Current Settings > > Current Swap Location: C:/Users/Yed/AppData/Local/Temp > Current Swap Location writable: true > Undo Enabled: true > Undo Stack Limit: 400 > Use OpenGL: true > Use OpenGL Texture Buffer: true > Use AMD Vectorization Workaround: false > Canvas State: OPENGL_SUCCESS > Autosave Interval: 300 > Use Backup Files: true > Number of Backups Kept: 1 > Backup File Suffix: ~ > Backup Location: Same Folder as the File > Backup Location writable: false > Use Win8 Pointer Input: false > Use RightMiddleTabletButton Workaround: false > Levels of Detail Enabled: false > Use Zip64: false It seems the issue happens when airbrush option is on in the brush settings. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 424319] Modifier shortcut keys stop working
https://bugs.kde.org/show_bug.cgi?id=424319 --- Comment #20 from stephen --- (In reply to Boudewijn Rempt from comment #19) > Did you manage to do the testing? This is one of the last bugs blocking our > 4.4.0 release, and we haven't been able to reproduce it ourselves. Alright. I did tests. Wasn't able to reproduce the issue. However, on random occasions, when I get back to the app, cursor behavior is confused with space. As a result, even without pressing space, the hand tool is like, in use, and moving the pen around leads to panning the canvas. Doesn't happen with mouse. When this happens, I restart a service from my tablet driver to stop it. And for a while, even after I lose focus or get krita in focus, the issue doesn't occur. Stopping my tablet driver service doesn't fix non-responsive modifier keys though. For this one, I must either press Tab key once at least then avoid losing focus again, or restart Krita. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 426291] UI Improvement ideas
https://bugs.kde.org/show_bug.cgi?id=426291 stephen changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INTENTIONAL |--- Summary|UI Options Bar |UI Improvement ideas |Customization | --- Comment #7 from stephen --- (In reply to Tymond from comment #5) > This is just something that is both quite technical and something that > shouldn't be Krita's job to do. See that on Linux on some desktop > environments (sets of programs that make up the graphical side of the > system) for example KDE Plasma you can already do that for every program: > https://i.imgur.com/QCeJac4.png - this is with Firefox. And Firefox doesn't > have any special code inside, of course, it is the desktop environment > controlling that, not Firefox. > > Adding this option in Krita would require lots of work for something that > would probably make Krita even more buggy with several windows and several > displays on several systems and stuff like that. So adding this option would > be dangerous for stability. So we really cannot help you here, sorry. > > Maybe try full screen mode instead. Alright. I'm reopening this, sorry. But not necessarily to ask for options menus to be put on the title bar. So I reformulate my feedback. I have suggestive ideas for the improvement of Krita's visual interface. I will support them with a few images from which studies can be made, with hope that this time you would understand what led me to the suggestion. It's just because I care about Krita having a better UI. Now, granted it's work to take care of stuff like this. So for the code going along with the matching design, I can wait a few more years. And if I make a good net worth, donation for support will be made from me, time will tell. So... Maybe the following suggestions would be applicable only to Krita 5.0+ or Krita 6.0+. It's only about design directions which I think really work in terms of aesthetics and ergonomics. Listing them now : // Dockable sub-windows which can be easily converted into tabs if multiple of them are docked together in the same place; these sub-windows can also have multiple tabs each and there's no need to put again the option to choose between subwindows or tabs since it's an all-in-one feature. I_00 // No rounded corners for the rectangles of docked tabs' labels. You may take example on the picture with red marked parts for this. References here : 1) https://i.ibb.co/VVB1G51/image.png I_01 // Simple dark lines to separate dockable areas, options bar and menu bar. For this I would suggest reference 1) again for this. But I have other references : 2) https://i.ibb.co/yQ7jckL/image.png (you may put your magnifier onto the separation especially the red marked area) 3) https://forum.affinity.serif.com/uploads/monthly_2018_12/image.png.2945c395b5212dcf3f7bb5bcc9f6f5ed.png I_02 // Seamless and slightly smaller options bar buttons but also slightly smaller height of the options bar. Made a suggestive image quick mockup for this. Please zoom in for the details. Reference here : 4) https://i.ibb.co/4JkYz5J/FEED-UI-1.png I_03 // Brush settings UI : the part where the brush tip is shown ought to be always visible whether a predefined tip is used or not. It should also be interactive and offer the possibility to change brush tip angle and ratio visually, with a hold and drag use case. Part marked in red in the following reference : 5) https://i.ibb.co/BG0J1pG/feed-UI-brush.png Suggestive design comes from Photoshop. But I hope you can understand why. 6) https://i.ibb.co/rKP6fsG/image.png If having space to show the predefined tip is an issue, you can add the predefined tips UI as another collapsed part of the brush settings menu, just like how you did with the brush presets in the following reference : 7) https://i.ibb.co/TcjPhcM/image.png With these put here, I end my feedback. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 426291] UI Improvement ideas
https://bugs.kde.org/show_bug.cgi?id=426291 stephen changed: What|Removed |Added Version|4.3.0-beta2 |4.4.0-beta2 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 426291] UI Improvement ideas
https://bugs.kde.org/show_bug.cgi?id=426291 --- Comment #8 from stephen --- And also, one last thing guys. Please avoid making subwindows stay under the viewport. They should be like floating windows instead. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 426291] UI Improvement ideas
https://bugs.kde.org/show_bug.cgi?id=426291 --- Comment #11 from stephen --- Oh, well. But I thank you. Thank you Tymond. I needed that missing info for effective feature request. Which plugins are you talking about though ? You seem to know them ? On Sep 30, 2020 10:30, "Tymond" wrote: > https://bugs.kde.org/show_bug.cgi?id=426291 > > --- Comment #10 from Tymond --- > Also, > > - please don't reopen wish reports, especially those closed as > "intentional", > *especially* with ideas that are very different from what you already > suggested, > > - all wishes that are about changes in behaviour or look or about big > features > should first go to krita-artists.org . Actually if you look there, you > can find > old threads with similar or contradictory wishes and even a plugin that > will > make some of changes you suggested here possible, > > - and read this manual page: > https://docs.krita.org/en/untranslatable_pages/new_features.html to learn > how > to suggest changes and new features effectively. > > -- > You are receiving this mail because: > You reported the bug. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 424319] Modifier shortcut keys stop working
https://bugs.kde.org/show_bug.cgi?id=424319 --- Comment #22 from stephen --- Hi Dmitry. I'm using a Huion H610 Pro. On Oct 1, 2020 11:33, "Dmitry Kazakov" wrote: > https://bugs.kde.org/show_bug.cgi?id=424319 > > --- Comment #21 from Dmitry Kazakov --- > Hi, stephen! > > Could you tell me, what tablet do you use? > > -- > You are receiving this mail because: > You are on the CC list for the bug. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 427335] New: Render brush cursor separately from the canvas pixels ?
https://bugs.kde.org/show_bug.cgi?id=427335 Bug ID: 427335 Summary: Render brush cursor separately from the canvas pixels ? Product: krita Version: 4.4.0-beta2 Platform: unspecified OS: Microsoft Windows Status: REPORTED Severity: wishlist Priority: NOR Component: General Assignee: krita-bugs-n...@kde.org Reporter: tgdev...@gmail.com Target Milestone: --- SUMMARY Greetings guys. Can you please separate the brush cursor's render process from that of the Canvas' ? There's a weird and slight stutter/delay just after the end of each stroke while painting. The issue is even more obvious with Instant Preview mode active. STEPS TO REPRODUCE 1. with a pixel engine brush selected, paint multiple strokes like if you wanted to do hatching lines. Instant preview is inactive. 2. repeat step 1 by painting as fast as you can and see if the brush cursor doesn't jump to catch up(might be frame drop at the end of each stroke, I don't know) 3. repeat step 1 with but this time with Instant Preview active. OBSERVED RESULTS At the end of each Stroke, the brush cursor stops moving or freezes for a brief amount of time then jumps to its correct position. With instant preview inactive, the impact is dampened. But with Instant preview active, it's just obvious. Tested on a Krita plus stable build : version 4.4.1 alpha(git b20cb06). OS : Windows 10 1909 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 427335] Render brush cursor separately from the canvas pixels ?
https://bugs.kde.org/show_bug.cgi?id=427335 stephen changed: What|Removed |Added Resolution|NOT A BUG |LATER -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 427335] Render brush cursor separately from the canvas pixels ?
https://bugs.kde.org/show_bug.cgi?id=427335 --- Comment #2 from stephen --- (In reply to Boudewijn Rempt from comment #1) > Sorry, but, no, that cannot be done. If that can not be done, then how did you manage to implement the brush Cursor Shape which moves effectively in real time according to user input ? It never lags, it's always responsive, and we need those pros for the Outline Shape as well. But, do you, at least, understand the issue ? It's what matter the most; if you do, then it's good and we can expect for change sooner or later. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 427335] Render brush cursor separately from the canvas pixels ?
https://bugs.kde.org/show_bug.cgi?id=427335 --- Comment #4 from stephen --- (In reply to Boudewijn Rempt from comment #3) > Of course I understand the issue. I first ran into this in 2004. Cursors are > drawn by the display manager of the window system. That system cannot be > used to draw the brush outline. > > Btw, do not change the status of bugs: only developers should do that. OK... But there's got to be a way. Maybe this would help you in the future. https://docs.microsoft.com/en-us/windows/win32/learnwin32/setting-the-cursor-image -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 427487] New: Wish : make interaction tools compatible with raster or paint layers
https://bugs.kde.org/show_bug.cgi?id=427487 Bug ID: 427487 Summary: Wish : make interaction tools compatible with raster or paint layers Product: krita Version: 4.4.0-beta2 Platform: unspecified OS: All Status: REPORTED Severity: wishlist Priority: NOR Component: Tools Assignee: krita-bugs-n...@kde.org Reporter: tgdev...@gmail.com Target Milestone: --- SUMMARY This goes into the wishlist and targets Interaction tools' added compatibility with Paint layers. STEPS TO REPRODUCE 1. Select multiple paint/vector layers(at least a total of three selected layers in the stack) 2. Execute any alignment or distribution function in the interaction tools OBSERVED RESULT Currently impossible to align or distribute paint layers(a little bummer; why didn't you think about it earlier ?) EXPECTED RESULT Whether vector or raster layers are selected, they are disposed according to the executed interaction tool. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 427488] New: Feature proposal : dynamic option bar UX according to selected tool
https://bugs.kde.org/show_bug.cgi?id=427488 Bug ID: 427488 Summary: Feature proposal : dynamic option bar UX according to selected tool Product: krita Version: 4.4.0-beta2 Platform: unspecified OS: All Status: REPORTED Severity: wishlist Priority: NOR Component: Tools Assignee: krita-bugs-n...@kde.org Reporter: tgdev...@gmail.com Target Milestone: --- SUMMARY This goes into the wishlist and targets the options bar. The idea is to have different options displayed or not according to the selected tool. For instance, selecting the move tool will display interaction tools buttons on the option bar and remove unnecessary options(opacity or flow) instead of graying them. STEPS TO REPRODUCE 1. Select for instance the brush tool, then switch to the gradient/fill tool then, switch to the move tool. OBSERVED RESULT For the moment, the options bar keeps its options and is static rather than dynamic. This means the possibility for more options is not really possible as of now. EXPECTED RESULT Depending on the tool selected, the options that support the currently selected tool are shown. For instance, selecting the brush tool will display opacity, flow, brush size, brush tip, foreground/background colors etc. Selecting the gradient/fill tool displays opacity, foreground/background color, gradient types, etc, etc. This probably needs to be discussed. I might have to search the krita-artists website for a similar topic or create one if none existed yet. But I leave this here meanwhile. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 440763] Krita 5.0.0 prealpha bug : Unexpected pen pressure failure
https://bugs.kde.org/show_bug.cgi?id=440763 stephen changed: What|Removed |Added Resolution|NOT A BUG |--- Status|RESOLVED|REPORTED --- Comment #2 from stephen --- (In reply to Halla Rempt from comment #1) > Sorry, not a Krita bug. Krita does not contain any code whatsoever that > handles tablet api's directly. If something breaks it's either a local > problem, and OS problem or a driver problem, but it cannot be a bug in > Krita's code. Please, if it's not a bug, then at least, allow Krita to re-detect the tablet without restarting itself. This issue nevertheless is real and annoying. The fact that I reinstalled my tablet didn't fix it. Once again, this issue is only happening with Krita 5 build, not the 4.x ones. Do something if it can help. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 440763] Krita 5.0.0 prealpha bug : Unexpected pen pressure failure
https://bugs.kde.org/show_bug.cgi?id=440763 --- Comment #3 from stephen --- *re-installed my tablet driver...* -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 439848] New: Request : prevent showing/hiding guides to cancel/commit transform mode
https://bugs.kde.org/show_bug.cgi?id=439848 Bug ID: 439848 Summary: Request : prevent showing/hiding guides to cancel/commit transform mode Product: krita Version: 4.4.5 Platform: unspecified OS: All Status: REPORTED Severity: normal Priority: NOR Component: Tools/Transform Assignee: krita-bugs-n...@kde.org Reporter: tgdev...@gmail.com Target Milestone: --- SUMMARY Other than snap, hiding/showing guides cancels/commits an active transform mode. This is not a bug but a situation which is in my opinion, counter productive. I hope you can do something about it. STEPS TO REPRODUCE 1. Have some pixels painted on a layer. 2. Go in transform mode, I press "CTRL + T" on my side for that. 3. While in transform mode, toggle showing guides on/off OBSERVED RESULT Toggling the guide appearance on the canvas commits the active transform mode, and you exit it without wanting that. Like if it's necessary to exit transform mode to show/hide canvas guides. EXPECTED RESULT The transform mode is supposed to stay active, whether the guides display is toggled on or off. show_guides() != commit_transform(). SOFTWARE/OS VERSIONS Windows 10 1909 But it's probably applicable to all other OSs as well. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 440161] New: Feature request : Smart guides and smart snapping
https://bugs.kde.org/show_bug.cgi?id=440161 Bug ID: 440161 Summary: Feature request : Smart guides and smart snapping Product: krita Version: unspecified Platform: unspecified OS: All Status: REPORTED Severity: wishlist Priority: NOR Component: General Assignee: krita-bugs-n...@kde.org Reporter: tgdev...@gmail.com Target Milestone: --- Created attachment 140260 --> https://bugs.kde.org/attachment.cgi?id=140260&action=edit Smart_guides_smart_snap SUMMARY This is a request on the ability to activate/deactivate a kind of Smart Guides System. It will allow to display lines and distance units between the bounds or centers of multiple layers(check pictures attached for references). But also to help align a series of objects(at least two)on a single axis when the distance between their relative centers and/or bounds is the same. USE CASE 1 : 1. Have a layer with raster or vector data in it 2. Duplicate the layer and move the copy at a different location on the same vertical or horizontal axis than the original data it's copied from. 3. Try to align as best as you can on one of the axes to trigger a display of the distance(in px) between the two objects 4. Have another copy of the same layer data, duplicate the data from the newly created layer, and align it as well on the axis the two previous ones are on. 5. As you move this new copied layer data, you should notice hints or an indicator showing the repeating distance between the three objects when you're enough in reach. (Check picture attached for reference.) 6. Once you see this indicator, leave the copied data at its position to create even spaces between your objects. USE CASE 2 : Paint some objects and arrange them to create even spacings like in the example from the picture in the link below(focus only on the frames and help yourself with the arrange tools if needed, this suppose that the new arrange/interaction tools are fully compatible with paint/raster layers) : https://drive.google.com/file/d/1X8Eqw2GgsayNwz_hIou12VmHcYzIg-7Q/view?usp=sharing -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 440165] New: Transform tool hides layer after operation is committed(in-stack preview off)
https://bugs.kde.org/show_bug.cgi?id=440165 Bug ID: 440165 Summary: Transform tool hides layer after operation is committed(in-stack preview off) Product: krita Version: git master (please specify the git hash!) Platform: unspecified OS: All Status: REPORTED Severity: normal Priority: NOR Component: Tools/Transform Assignee: krita-bugs-n...@kde.org Reporter: tgdev...@gmail.com Target Milestone: --- SUMMARY This issue has to do with a pre alpha build of Krita 5.0(git version 48a5eb7) and is related to the Transform tool. Everytimes we exit transform after activation, the layer being transformed is unexpectedly hidden. And won't show unless we click the "hide/show" button again in the layer docker. STEPS TO REPRODUCE 1. Have some raster data on an active layer 2. Go into Transform Mode 3. Press Enter to exit Transform Mode OBSERVED RESULT Your raster data disappears from the Canvas after you exit the Transform mode. EXPECTED RESULT The raster data is meant to stay visible after we exit the transform mode. SOFTWARE/OS VERSIONS Windows 10 1909 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 440204] New: Request : make preview outline color to shifts between white/black as additional option
https://bugs.kde.org/show_bug.cgi?id=440204 Bug ID: 440204 Summary: Request : make preview outline color to shifts between white/black as additional option Product: krita Version: git master (please specify the git hash!) Platform: unspecified OS: All Status: REPORTED Severity: wishlist Priority: NOR Component: General Assignee: krita-bugs-n...@kde.org Reporter: tgdev...@gmail.com Target Milestone: --- SUMMARY The preview outline of the cursor is barely visible with greys and mid value colors. A color shift between black/white is recommendable. Even this version of Krita has this issue : v5.0.0 pre-alpha (git 48a5eb7). Requesting for an update in a certain future. STEPS TO REPRODUCE N/A -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 440204] Request : make preview outline color to shifts between white/black as additional option
https://bugs.kde.org/show_bug.cgi?id=440204 --- Comment #2 from stephen --- Created attachment 140286 --> https://bugs.kde.org/attachment.cgi?id=140286&action=edit cursor partly visible due to mid gray(bad ux) (In reply to Halla Rempt from comment #1) > The cursor outline color is already configurable I know it's configurable already. I said that the way it's configured however, impeaches its visibility to be clear with grays and mid value colors. Maybe I wasn't explicit enough. The request is to make the cursor shift between black/white, without displaying any intermediate value depending on the pixels it hovers on. Think of it as a strict binary color shift : either it's black or it's white, and nothing more. USE CASE : The pixels it hovers on are gray or mid-value : the cursor intuitively changes to black/white instead of gray. Initially, it would display black/white colors. If the pixels under it are black or mid grey, or with mid value color, it should show either black/white color. Any color darker than perfect 50% gray, even to the slightest, will trigger full white color. Any color lighter than perfect 50% gray, even to the slightest, will trigger full black color. Check the picture attached to better understand the issue. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 440204] Request : make preview outline color to shifts between white/black as additional option
https://bugs.kde.org/show_bug.cgi?id=440204 stephen changed: What|Removed |Added Resolution|WORKSFORME |--- Status|RESOLVED|REPORTED -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 440352] New: Too much inconsistency with the modifier keys(Krita 5.0 pre alpha)
https://bugs.kde.org/show_bug.cgi?id=440352 Bug ID: 440352 Summary: Too much inconsistency with the modifier keys(Krita 5.0 pre alpha) Product: krita Version: git master (please specify the git hash!) Platform: Other OS: Other Status: REPORTED Severity: normal Priority: NOR Component: General Assignee: krita-bugs-n...@kde.org Reporter: tgdev...@gmail.com Target Milestone: --- SUMMARY There's too much inconsistency with the modifier keys and it tends to freezes inputs and the cursor, up to the point that you have to wait a certain amount of time before being able to use Krita again. STEPS TO REPRODUCE 1. Keep your pen in detection and press CTRL+ALT several times 2. Continue until the cursor gets frozen OBSERVED RESULT The cursor gets frozen as well as many inputs. OTHER OBSERVATIONS : I. There's no way to reproduce this if your pen is not detected( if you are using your mouse.) II. The log viewer displays this before I pressed CTRL+ALT several times while having my pen detected, I pressed CTRL only once : --- WARNING: modifiers state became inconsistent! Trying to fix that... inputEvent->modifiers() = QFlags(ControlModifier) d->matcher.debugPressedKeys() = QVector() --- III. Then it shows this after I pressed CTRL+ALT several times(twice in this case) --- WARNING: modifiers state became inconsistent! Trying to fix that... inputEvent->modifiers() = QFlags(ControlModifier|AltModifier) d->matcher.debugPressedKeys() = QVector(Qt::Key_Menu, Qt::Key_Control) WARNING: modifiers state became inconsistent! Trying to fix that... inputEvent->modifiers() = QFlags(ControlModifier|AltModifier) d->matcher.debugPressedKeys() = QVector(Qt::Key_Menu, Qt::Key_Control) WARNING: modifiers state became inconsistent! Trying to fix that... inputEvent->modifiers() = QFlags(ControlModifier|AltModifier) d->matcher.debugPressedKeys() = QVector(Qt::Key_Menu, Qt::Key_Control) WARNING: modifiers state became inconsistent! Trying to fix that... inputEvent->modifiers() = QFlags(ControlModifier|AltModifier) d->matcher.debugPressedKeys() = QVector(Qt::Key_Menu, Qt::Key_Control) WARNING: modifiers state became inconsistent! Trying to fix that... inputEvent->modifiers() = QFlags(ControlModifier|AltModifier) d->matcher.debugPressedKeys() = QVector(Qt::Key_Menu, Qt::Key_Control) WARNING: modifiers state became inconsistent! Trying to fix that... inputEvent->modifiers() = QFlags(ControlModifier|AltModifier) d->matcher.debugPressedKeys() = QVector(Qt::Key_Menu, Qt::Key_Control) WARNING: modifiers state became inconsistent! Trying to fix that... inputEvent->modifiers() = QFlags(ControlModifier|AltModifier) d->matcher.debugPressedKeys() = QVector(Qt::Key_Menu, Qt::Key_Control) WARNING: modifiers state became inconsistent! Trying to fix that... inputEvent->modifiers() = QFlags(ControlModifier|AltModifier) d->matcher.debugPressedKeys() = QVector(Qt::Key_Menu, Qt::Key_Control) WARNING: modifiers state became inconsistent! Trying to fix that... inputEvent->modifiers() = QFlags(ControlModifier|AltModifier) d->matcher.debugPressedKeys() = QVector(Qt::Key_Menu, Qt::Key_Control) WARNING: modifiers state became inconsistent! Trying to fix that... inputEvent->modifiers() = QFlags(ControlModifier|AltModifier) d->matcher.debugPressedKeys() = QVector(Qt::Key_Menu, Qt::Key_Control) WARNING: modifiers state became inconsistent! Trying to fix that... inputEvent->modifiers() = QFlags(ControlModifier|AltModifier) d->matcher.debugPressedKeys() = QVector(Qt::Key_Menu, Qt::Key_Control) WARNING: modifiers state became inconsistent! Trying to fix that... inputEvent->modifiers() = QFlags(ControlModifier|AltModifier) d->matcher.debugPressedKeys() = QVector(Qt::Key_Menu, Qt::Key_Control) WARNING: modifiers state became inconsistent! Trying to fix that... inputEvent->modifiers() = QFlags(ControlModifier|AltModifier) d->matcher.debugPressedKeys() = QVector(Qt::Key_Menu, Qt::Key_Control) WARNING: modifiers state became inconsistent! Trying to fix that... inputEvent->modifiers() = QFlags(ControlModifier|AltModifier) d->matcher.debugPressedKeys() = QVector(Qt::Key_Menu, Qt::Key_Control) WARNING: modifiers state became inconsistent! Trying to fix that... inputEvent->modifiers() = QFlags(ControlModifier|AltModifier) d->matcher.debugPressedKeys() = QVector(Qt::Key_Menu, Qt::Key_Control) WARNING: modifiers state became inconsistent! Trying to fix that... inputEvent->modifiers() = QFlags(ControlModifier|AltModifier) d->matcher.debugPressedKeys() = QVector(Qt::Key_Menu, Qt::Key_Control) WARNING: modifiers state became inconsistent! Trying to fix that... input
[krita] [Bug 338002] Arrange for layers
https://bugs.kde.org/show_bug.cgi?id=338002 --- Comment #6 from stephen --- Please do not forget about aligning contents from different layers only. Not objects within the same layer like how Krita is currently made. Vector layers are no exception. This would simply lead to a confusing workflow, and aligning abjects from different layers is more intuitive. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 440763] New: Krita 5.0.0 prealpha bug : Unexpected pen pressure failure
https://bugs.kde.org/show_bug.cgi?id=440763 Bug ID: 440763 Summary: Krita 5.0.0 prealpha bug : Unexpected pen pressure failure Product: krita Version: git master (please specify the git hash!) Platform: Other OS: Microsoft Windows Status: REPORTED Severity: normal Priority: NOR Component: General Assignee: krita-bugs-n...@kde.org Reporter: tgdev...@gmail.com Target Milestone: --- SUMMARY An unexpected failure about pen pressure detection STEPS TO REPRODUCE 1. Open Krita and create a new document 2. Keep the windows unfocused for about 8-6 hours 3. Return to Krita and try paint to see if pressure is there OBSERVED RESULT you would notice that the pen pressure detection has failed and pen input is registered as mouse input EXPECTED RESULT No pen detection failure due to having Krita not being actively used after 6-8 hours SOFTWARE/OS VERSIONS Windows 10 1909 Krita git hash : v5.0.0(11dd91c) -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 439549] New: Request : prevent snap toggle to cancel/commit transform mode
https://bugs.kde.org/show_bug.cgi?id=439549 Bug ID: 439549 Summary: Request : prevent snap toggle to cancel/commit transform mode Product: krita Version: 4.4.5 Platform: unspecified OS: All Status: REPORTED Severity: wishlist Priority: NOR Component: Tools/Transform Assignee: krita-bugs-n...@kde.org Reporter: tgdev...@gmail.com Target Milestone: --- SUMMARY The snap toggle feature cancels/commits an active transform mode. This is not a bug but a situation which is in my opinion, counter productive. I hope you can do something about it. STEPS TO REPRODUCE 1. Have some pixels painted on a layer. 2. Go in transform mode, I press "CTRL + T" on my side for that. 3. While in transform mode, toggle any snapping on or off OBSERVED RESULT Toggling the snapping commits the active transform mode, and you exit it without wanting that. Like if it's necessary to exit transform mode for the snapping to be enabled/disabled. EXPECTED RESULT The transform mode is supposed to stay active, whether the snap is toggled on or off. Snap_toggle() != commit_transform(). SOFTWARE/OS VERSIONS Windows 10 1909 But it's probably applicable to all other OSs as well. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 439654] New: Bug : input stuck on panning after clicking/right-clicking on a floating window(brush list windows, brush settings windows, etc)
https://bugs.kde.org/show_bug.cgi?id=439654 Bug ID: 439654 Summary: Bug : input stuck on panning after clicking/right-clicking on a floating window(brush list windows, brush settings windows, etc) Product: krita Version: 4.4.5 Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: normal Priority: NOR Component: Shortcuts and Canvas Input Settings Assignee: krita-bugs-n...@kde.org Reporter: tgdev...@gmail.com Target Milestone: --- SUMMARY For some reason, Krita loves to randomly get stuck on panning even when the spacebar key is not pressed. Happens only from detection of a pen with a drawing tablet. If you put the pen out of range, the key isn't pressed. But if you bring it range, it pans on its own. STEPS TO REPRODUCE Unsure. But it happens when : *you go out of focus by switching from Krita to another app's Windows. *After right click events ? Try the following : Case 1 : 1. Open/create a document 2. show the brush list floating window 3. hover over a brush and right-click to cast a context menu. 4. hover over the canvas to see if the panning bug doesn't start Case 2 : 1. Go out of focus of Krita by switching to another opened app 2. Switch back to Krita from this app and hover over the canvas OBSERVED RESULT Everytime your tablet pen is detected, it instantly gets stuck on panning. Pressing spacebar doesn't cancel the issue. EXPECTED RESULT No unexpected and random key input bug which executes an unwanted command on its own, no panning at the detection of your pen if the proper key isn't pressed and held. SOFTWARE/OS VERSIONS Windows: 10 1909 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 427335] Render brush cursor separately from the canvas pixels ?
https://bugs.kde.org/show_bug.cgi?id=427335 --- Comment #5 from stephen --- (In reply to stephen from comment #4) > (In reply to Boudewijn Rempt from comment #3) > > Of course I understand the issue. I first ran into this in 2004. Cursors are > > drawn by the display manager of the window system. That system cannot be > > used to draw the brush outline. > > > > Btw, do not change the status of bugs: only developers should do that. > > OK... > But there's got to be a way. > Maybe this would help you in the future. > https://docs.microsoft.com/en-us/windows/win32/learnwin32/setting-the-cursor- > image Alright. It turns out, things are much smoother with OpenGL renderer active rather than DX11 ANGLE. And so, brush cursor spped might not be an issue anymore. However the Black/White color change option is still awaited, guys. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 427080] Bug : Inconsistent functionality of the line tool
https://bugs.kde.org/show_bug.cgi?id=427080 stephen changed: What|Removed |Added Ever confirmed|1 |0 Resolution|WAITINGFORINFO |--- Status|NEEDSINFO |REPORTED --- Comment #5 from stephen --- (In reply to vanyossi from comment #3) > Hi stephen, I tested the line tool and at least on macOS results are as > expected. > > Could you record a video of what you are getting? Line tool varies depending > on the pressure during the entire line stroke gesture. So you can trace > different pressure levels depending on the distance. If you see no line at > the very begging or end it might mean you almost had no pressure on your > stroke and the preset you are using does not paint at that "pressure" at > that point in the line. (its quoted as the line can vary depending on any > sensor you set). > > Readjust your brush preset so it paints at any sensor state during the > tracing. My first comment contains already a video recording of my tests. You may check that to see it helps. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 435204] New: Krita 4.4.4 wont's save file(happens at random)
https://bugs.kde.org/show_bug.cgi?id=435204 Bug ID: 435204 Summary: Krita 4.4.4 wont's save file(happens at random) Product: krita Version: git master (please specify the git hash!) Platform: Other OS: Microsoft Windows Status: REPORTED Severity: grave Priority: NOR Component: General Assignee: krita-bugs-n...@kde.org Reporter: tgdev...@gmail.com Target Milestone: --- SUMMARY I'm bitterly reporting that thanks to Krita being somewhere unstable, it wiped of my long work progress today. At random, the program won't dare save progress. And when it happens, you can't save anything more. This, hurts me like I can't explain it. Especially given the fact that I was doing professional work with the app. STEPS TO REPRODUCE I don't know how to reproduce the issue. The saving system of your app is unstable and that's all. OBSERVED RESULT Firstly it writes autosave, but it's stuck at a level in the progress bar. It didn't budge for lots of minutes. So I cancelled it. I then continued to work and tried to save again using all possible ways, but no saved file anymore. And the saving progress bar won't ever show up again after you confirm save location and file name in the save dialog. EXPECTED RESULT The save system should be flawless. By the way, this isn't common to this version of Krita only. It also happens with 4.4.2 and 4.4.3. SOFTWARE/OS VERSIONS Windows 10 1909 Additional information. App used : Krita stable git version 4.4.4 alpha(7d4dcb1) As soon as I noticed that I couldn't save to a new file, I wanted to copy all the layers. But when I did so, Krita immediately crashed ! -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 435204] Krita 4.4.4 wont's save file(happens at random)
https://bugs.kde.org/show_bug.cgi?id=435204 --- Comment #2 from stephen --- (In reply to Tiar from comment #1) > Can you please attach the content of Help -> Show Krita log for bug reports? > And please do tell how was your work (the one you lost progress in) called. Here's the log data ! --- WARNING: The Krita usage log file doesn't exist.File name and location: C:/Users/Yed/AppData/Local/krita.log Krita Version: 4.4.4-alpha (git 7d4dcb1) Qt Version (compiled): 5.12.9 Version (loaded): 5.12.9 OS Information Build ABI: x86_64-little_endian-llp64 Build CPU: x86_64 CPU: x86_64 Kernel Type: winnt Kernel Version: 10.0.18363 Pretty Productname: Windows 10 (10.0) Product Type: windows Product Version: 10 OpenGL Info Vendor: "Google Inc." Renderer: "ANGLE (NVIDIA GeForce GT 640M Direct3D11 vs_5_0 ps_5_0)" Version: "OpenGL ES 3.0 (ANGLE 2.1.0.57ea533f79a7)" Shading language: "OpenGL ES GLSL ES 3.00 (ANGLE 2.1.0.57ea533f79a7)" Requested format: QSurfaceFormat(version 3.0, options QFlags(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::DoubleBuffer, swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile QSurfaceFormat::CompatibilityProfile) Current format:QSurfaceFormat(version 3.0, options QFlags(), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples 0, swapBehavior QSurfaceFormat::DefaultSwapBehavior, swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile QSurfaceFormat::NoProfile) Version: 3.0 Supports deprecated functions false is OpenGL ES: true QPA OpenGL Detection Info supportsDesktopGL: true supportsAngleD3D11: true isQtPreferAngle: true Hardware Information Memory: 9 Gb Cores: 4 Swap: C:/Users/Yed/AppData/Local/Temp --- The work was called : A5_P03A_450ppi_new.kra It's the file for a comic page. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 435545] New: Krita 4.4.4 alpha stable :Crop tool won't do anything if "Enter" key is pressed.
https://bugs.kde.org/show_bug.cgi?id=435545 Bug ID: 435545 Summary: Krita 4.4.4 alpha stable :Crop tool won't do anything if "Enter" key is pressed. Product: krita Version: git master (please specify the git hash!) Platform: Other OS: Microsoft Windows Status: REPORTED Severity: normal Priority: NOR Component: Tools Assignee: krita-bugs-n...@kde.org Reporter: tgdev...@gmail.com Target Milestone: --- SUMMARY In the last Krita plus stable build(git 27d5b12), a new bug causes the crop tool to ignore action on "Enter" pressing. It basically behaves like if, for some reason, "Enter" key cancels action of the crop tool. It wasn't the case before. STEPS TO REPRODUCE 1. Have your crop tool selected 2. Define the limits of your cropping area 3. Press "Enter" key. OBSERVED RESULT Pressing "Enter" key does nothing. It doesn't even register in the history states. EXPECTED RESULT Pressing "Enter" should apply cropping according to your defined cropping area. SOFTWARE/OS VERSIONS Windows: 10 1909 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 423240] Advanced Color selector - slow performance
https://bugs.kde.org/show_bug.cgi?id=423240 --- Comment #8 from stephen --- (In reply to Ahab Greybeard from comment #7) > I don't see this with the 4.3.0 appimage or the 4.3.0 portable .zip on > Windows 10. > I also don't see it with the latest nightly builds on Linux or Windows 10. > > There was the same description lag bug in the 4.3.0 prealphas in mid-April > as reported here: > https://bugs.kde.org/show_bug.cgi?id=420159 > That bug was fixed for an unknown reason. > > HSV click-drag response is not affected by canvas graphics acceleration > being enabled or disabled. (If you try toggling cga in 4.3.0, that has a > separate canvas lock-up bug that has now been fixed.) > > @stephen: Can you do Help -> Show system information for bug reports and > post the full output here? I'm on Windows 10. The issue is still present from my side. Even with Krita 4.3.0 Here's the system info for the bug report : Krita Version: 4.3.1-alpha (git 62566d1) Languages: en_US, en, en_US, en, en_US, en, en_US, en, en_US, en, en_US, en, en_US, en, en_US, en, en_US, en Hidpi: true Qt Version (compiled): 5.12.8 Version (loaded): 5.12.8 OS Information Build ABI: x86_64-little_endian-llp64 Build CPU: x86_64 CPU: x86_64 Kernel Type: winnt Kernel Version: 10.0.18363 Pretty Productname: Windows 10 (10.0) Product Type: windows Product Version: 10 OpenGL Info Vendor: "Google Inc." Renderer: "ANGLE (NVIDIA GeForce GT 640M Direct3D11 vs_5_0 ps_5_0)" Version: "OpenGL ES 3.0 (ANGLE 2.1.0.57ea533f79a7)" Shading language: "OpenGL ES GLSL ES 3.00 (ANGLE 2.1.0.57ea533f79a7)" Requested format: QSurfaceFormat(version 3.0, options QFlags(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::DoubleBuffer, swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile QSurfaceFormat::CompatibilityProfile) Current format:QSurfaceFormat(version 3.0, options QFlags(), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples 0, swapBehavior QSurfaceFormat::DefaultSwapBehavior, swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile QSurfaceFormat::NoProfile) Version: 3.0 Supports deprecated functions false is OpenGL ES: true QPA OpenGL Detection Info supportsDesktopGL: true supportsAngleD3D11: true isQtPreferAngle: true Hardware Information GPU Acceleration: angle Memory: 12126 Mb Number of Cores: 4 Swap Location: C:/Users/Yed/AppData/Local/Temp Current Settings Current Swap Location: C:/Users/Yed/AppData/Local/Temp Current Swap Location writable: true Undo Enabled: true Undo Stack Limit: 400 Use OpenGL: true Use OpenGL Texture Buffer: true Use AMD Vectorization Workaround: false Canvas State: OPENGL_SUCCESS Autosave Interval: 300 Use Backup Files: false Number of Backups Kept: 1 Backup File Suffix: ~ Backup Location: Same Folder as the File Backup Location writable: false Use Win8 Pointer Input: false Use RightMiddleTabletButton Workaround: false Levels of Detail Enabled: true Use Zip64: false Display Information Number of screens: 1 Screen: 0 Name: \\.\DISPLAY1 Depth: 32 Scale: 1 Resolution in pixels: 1600x900 Manufacturer: Model: Refresh Rate: 60 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 423520] Weird GLITCH with Krita's rendering Engine
https://bugs.kde.org/show_bug.cgi?id=423520 --- Comment #3 from stephen --- Here's a file for inspecting the issue. By the way, it happens mostly while using Eraser mode. On Mon, Jul 27, 2020 at 10:31 PM Tymond wrote: > https://bugs.kde.org/show_bug.cgi?id=423520 > > Tymond changed: > >What|Removed |Added > > > Resolution|--- |WAITINGFORINFO >Keywords||triaged > Status|REPORTED|NEEDSINFO > > --- Comment #2 from Tymond --- > Setting to Needs Info. > > -- > You are receiving this mail because: > You reported the bug. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 424954] New: Wish : Cursor tweaks : system cursor speed and white/black color shift
https://bugs.kde.org/show_bug.cgi?id=424954 Bug ID: 424954 Summary: Wish : Cursor tweaks : system cursor speed and white/black color shift Product: krita Version: unspecified Platform: unspecified OS: Unspecified Status: REPORTED Severity: wishlist Priority: NOR Component: General Assignee: krita-bugs-n...@kde.org Reporter: tgdev...@gmail.com Target Milestone: --- Created attachment 130602 --> https://bugs.kde.org/attachment.cgi?id=130602&action=edit Krita_Cursor_newOptions_feed SUMMARY This is not a bug but a wish consisting in two things for the cursor's behavior. Currently using Krita 4.3.1(Krita plus alpha stable version, git 62566d1). So here's a description : 1. Cursor speed : it's a minor thing but it matters still for an illusion of smoothness. The cursor speed would be substituted by the system's cursor, in other words, it'd move at exact same speed than the Windows cursor. This means you'd have to find a way to make the OUTLINE SHAPE to display "as CURSOR SHAPE". 2. Cursor color behavior set as black/white instead of inverted color : Here, it's just about adding an option to make the cursor's color either black/white depending on the value of the underneath pixels. Strictly black/white though, no inversed color effect. This way the cursor will remain always visible, even on gray pixels. Yes, right now, it's almost impossible to see the cursor color while painting gray. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 429165] New: Bug : Messy rendering with Layer styles
https://bugs.kde.org/show_bug.cgi?id=429165 Bug ID: 429165 Summary: Bug : Messy rendering with Layer styles Product: krita Version: nightly build (please specify the git hash!) Platform: unspecified OS: Microsoft Windows Status: REPORTED Severity: normal Priority: NOR Component: layer styles Assignee: krita-bugs-n...@kde.org Reporter: tgdev...@gmail.com Target Milestone: --- Created attachment 133368 --> https://bugs.kde.org/attachment.cgi?id=133368&action=edit Messy layer style render updates SUMMARY STEPS TO REPRODUCE 1. Create a layer 2. Set layer style on the created layer, option : stroke@inside, blend_mode = normal, opacity = 100%. 3. Paint on the layer and see what's happening. OBSERVED RESULT Inconsistent and messy pixels on the part that renders the layer style. EXPECTED RESULT Clean smooth rendering of the layer style in real-time. OS Version : Windows 10 1909 You may take the opportnity to try check whether or not other layer styles render in a messy way. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 473459] Line Tool produces wobbly lines
https://bugs.kde.org/show_bug.cgi?id=473459 stephen changed: What|Removed |Added CC||tgdev...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 448288] New: Krita 5.1.0 preaplpha issue : Weirdly filled blank space
https://bugs.kde.org/show_bug.cgi?id=448288 Bug ID: 448288 Summary: Krita 5.1.0 preaplpha issue : Weirdly filled blank space Product: krita Version: nightly build (please specify the git hash!) Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: normal Priority: NOR Component: OpenGL Canvas Assignee: krita-bugs-n...@kde.org Reporter: tgdev...@gmail.com Target Milestone: --- Created attachment 145343 --> https://bugs.kde.org/attachment.cgi?id=145343&action=edit EmptySpaceFillIssue SUMMARY Krita git hash is 6db92d4. There's like an issue with weirdly filled blank space which occurs in two cases. STEPS TO REPRODUCE Case 1 : Using Eraser on blank space 1.1. select an eraser brush or activate the erase mode 1.2. erase in an already blank or empty area on a layer. Case 2 : with opaque pixel data on a layer 2.1. Paint a little shape on a new layer 2.2. Flip the painted data left, right, up, down OBSERVED RESULT Case 1 : blank space is filled in the layer thumbnail Case 2 : Krita "abnormally" fills the empty space travelled by the pixel data on the layer, unnecessarily causing memory use. It result in a big rect shape with tiny pixel data in it. Use transform tool to verify. EXPECTED RESULT Empty layer should be empty and not behave like it's filled, be it on the layer thumbnail, or with the layer pixel data itself. Warning : Might want to check whether it's happening with vector layers too. Also this issue might've been hidden and present in many previous versions and current versions. SOFTWARE/OS VERSIONS Windows : 10 21H1 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 442198] Krita 5.1.0 prealpha(git 8376871) : brush texture blending modes not behaving correctly
https://bugs.kde.org/show_bug.cgi?id=442198 stephen changed: What|Removed |Added Resolution|WAITINGFORINFO |--- Status|NEEDSINFO |REPORTED --- Comment #10 from stephen --- (In reply to Dmitry Kazakov from comment #8) > I'll mark the bug as needsinfo for now. Hello Dmitry. I can confirm that the bug has been fixed. Or if it's not the case, I simply had modified the resource sqlite file so that I wouldn't experience the bug(I let Krita recreate a new one, without trying to fetch settings from older Krita version.) So far, things work well with the brush texture blending modes. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 439654] Bug : input stuck on panning after clicking/right-clicking on a floating window(brush list windows, brush settings windows, etc)
https://bugs.kde.org/show_bug.cgi?id=439654 stephen changed: What|Removed |Added Resolution|WAITINGFORINFO |--- Status|NEEDSINFO |REPORTED --- Comment #3 from stephen --- (In reply to Will Stephenson from comment #1) > What actions do you have assigned to your pen nib/buttons? Which tablet is > it? > > Couldn't reproduce yet on 5.0.0beta5. Greetings. I have assigned "right-click" and "switch brush" actions to my pen buttons. I use a Huion HS610. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 424319] Modifier shortcut keys stop working
https://bugs.kde.org/show_bug.cgi?id=424319 --- Comment #33 from stephen --- (In reply to Dmitry Kazakov from comment #32) > Hi, Stephen! > > What browser do you use? Is it Chrome/Chromium? > > And did you test the packages I linked? Hi Dmitry. So after testing the packages, it turns out that the in cursor gets locked and can't be moved anymore -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 431615] New: Last icon disapears in menu
https://bugs.kde.org/show_bug.cgi?id=431615 Bug ID: 431615 Summary: Last icon disapears in menu Product: plasmashell Version: 5.20.4 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Task Manager and Icons-Only Task Manager Assignee: h...@kde.org Reporter: k...@stephenscott.io CC: plasma-b...@kde.org Target Milestone: 1.0 Created attachment 134865 --> https://bugs.kde.org/attachment.cgi?id=134865&action=edit Screenshot of the konsole icon missing despite it being open. SUMMARY The last icon in the icon-only task manager will disapear in certain situations. It seems to happen only when there is a spacer somewhere in the panel and the first pinned application is not active. STEPS TO REPRODUCE 1. Add a spacer to the panel 2. Have exactly three icons in the manager with the first one not active. 3. The last icon will not show, but there will be a spcace for it. 4. I can reproduce with different applications/icons and in different size configurations. I've attached a screenshot with the missing icon and my system information. OBSERVED RESULT Konsole icon missing EXPECTED RESULT Konsole icon visible SOFTWARE/OS VERSIONS Linux/KDE Plasma: 5.9.16-1-Manjaro KDE Plasma Version: 5.20.4 KDE Frameworks Version: 5.77.0 Qt Version: 5.15.2 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 431616] New: Panel height plus and minus buttons are opposite when panel is at top of screen.
https://bugs.kde.org/show_bug.cgi?id=431616 Bug ID: 431616 Summary: Panel height plus and minus buttons are opposite when panel is at top of screen. Product: plasmashell Version: 5.20.4 Platform: Manjaro OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Panel Assignee: plasma-b...@kde.org Reporter: k...@stephenscott.io Target Milestone: 1.0 SUMMARY When editing the panel height with the plus/minus buttons when the panel is at the top of the screen, the plus button will substract and the minus button will add. STEPS TO REPRODUCE 1. Put panel to top of screen 2. Click the '+' button for the panel height. It will go from 25 -> 23 3. Click the '-' button for panel height. It will go from 23 -> 25 OBSERVED RESULT '+' button will decrease the height, and '-' will increase the height. EXPECTED RESULT The opposite. SOFTWARE/OS VERSIONS Linux/KDE Plasma: 5.9.16-1-MANJARO KDE Plasma Version: 5.20.4 KDE Frameworks Version: 5.77.0 Qt Version: 5.15.2 ADDITIONAL INFORMATION I've attached a video of the behavior. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 431616] Panel height plus and minus buttons are opposite when panel is at top of screen.
https://bugs.kde.org/show_bug.cgi?id=431616 --- Comment #1 from Stephen --- Created attachment 134866 --> https://bugs.kde.org/attachment.cgi?id=134866&action=edit Movie of bug. This is a clip of the bug happening. Note the icon also dissapears as the size is adjusted. I've filed a separate bug report for that issue. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 431615] Last icon disapears in menu
https://bugs.kde.org/show_bug.cgi?id=431615 --- Comment #3 from Stephen --- Created attachment 134946 --> https://bugs.kde.org/attachment.cgi?id=134946&action=edit Video of icon disapearing. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 431615] Last icon disapears in menu
https://bugs.kde.org/show_bug.cgi?id=431615 --- Comment #4 from Stephen --- Does adjusting the height make a difference? I added a video of the icon disappearing and reappearing as I adjusted the height. -- You are receiving this mail because: You are watching all bug changes.
