[krita] [Bug 486417] Canvas turns black when background caching animation frames
https://bugs.kde.org/show_bug.cgi?id=486417 --- Comment #2 from Ralek Kolemios --- Scratch that, the bug appears in the docker as well and is directly related to the 'limit cached frame size' both in and out of docker. New bug description: When the max cache frame size is smaller than the canvas size, and opengl is on, scrubbing quickly or pressing play will turn the canvas black until turning canvas acceleration off or reloading the file, -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 486417] Canvas turns black when background caching animation frames
https://bugs.kde.org/show_bug.cgi?id=486417 --- Comment #1 from Ralek Kolemios --- This bug doesn't seem to occur with the same system settings, preferences, and hardware when run inside of the Krita docker. Here are the differences between the buggy install and the docker: Docker: Ubuntu 20.04.6 LTS Vendor: Mesa/X.org Renderer: llvmpipe (LLVM 12.0.0, 256 bits) Driver Version: 4.5 (Core Profile) Mesa 21.2.6 OpenGL Version: 4.5 Buggy system: Ubuntu 23.10 Vendor: NVIDIA Corporation Renderer: NVIDIA GeForce RTX 4090/PCIe/SSE2 Driver Version: 4.6.0 NVIDIA 535.171.04 OpenGL Version: 4.6 All other components appeared the same or nearly the same. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 486419] New: Selection fills entire canvas if selection already exists when using reference layers.
https://bugs.kde.org/show_bug.cgi?id=486419 Bug ID: 486419 Summary: Selection fills entire canvas if selection already exists when using reference layers. Classification: Applications Product: krita Version: git master (please specify the git hash!) Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Tools/Selection Assignee: krita-bugs-n...@kde.org Reporter: i...@ralek.art Target Milestone: --- When selecting with the contiguous selection tool set to the 'color reference layer' method, all options are ignored and the entire canvas is selected if a selection already exists. To recreate: - Make a box on a color labeled layer. - Make a selection by any method (lasso, contiguous, etc) - Set the contiguous selection tool to 'sample color label' and set it to the color of the box layer. - Make a selection inside the box What happens: - The entire canvas is selected. (Edge case: If action type is set to 'subtract', it will leave the original selection unselected, showing that whatever function is creating the new selection is returning the full canvas and ignoring the reference layer entirely.) What should happen: - The selection fills the box, or if shift is held, should add the box to the initial selection. This bug doesn't occur if there is no previous selection, or if the reference layer is single/full image. Tt works as expected. 6060b8ee -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 486417] New: Canvas turns black when background caching animation frames
https://bugs.kde.org/show_bug.cgi?id=486417 Bug ID: 486417 Summary: Canvas turns black when background caching animation frames Classification: Applications Product: krita Version: git master (please specify the git hash!) Platform: Kubuntu OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Animation Assignee: krita-bugs-n...@kde.org Reporter: i...@ralek.art Target Milestone: --- When animating, scrolling through the timeline quickly or pressing play will turn the canvas black. The canvas cannot be restored unless the document is reopened, or graphics acceleration is turned off. To reproduce: Open a new document, create three blank keyframes, scrub through them quickly or press play. Things of note: - If canvas acceleration is off, this does not occur - If 'enable background cache generation' is off, this only occurs when pressing play and not when scrubbing. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 457957] Group transformations snap back to original location in preview when containing a filter layer.
https://bugs.kde.org/show_bug.cgi?id=457957 --- Comment #2 from Ralek Kolemios --- Can still confirm this in 5.3 prealpha, though it manifests slightly differently. The original transformation of group 31 finishes correctly now, but undoing the operation afterwards doesn't update the canvas. (The undo does still work behind the scenes, like in the original report) Move tool is still non-functional on Group 31. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 428317] Tracking rulers update at <1 FPS when non brush tool selected.
https://bugs.kde.org/show_bug.cgi?id=428317 --- Comment #3 from Ralek Kolemios --- In 5.3 this no longer seems to be an issue, either the ruler updates at correct speed with drawing tools, or it doesn't show at all (for tools in which I feel there's no need for a ruler, such as the paint bucket or eye dropper. I think it can be closed. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 485574] Recorder states it's recording, but isn't.
https://bugs.kde.org/show_bug.cgi?id=485574 --- Comment #2 from Ralek Kolemios --- (In reply to Freya Lupen from comment #1) > Could that have been the cause here? That does seem plausible, I rewatched the recording but unfortunately it started after I had already supposedly just opened the file. It's possible that right before the recording I may have created or opened a document and then closed it. I'll keep that in mind when I'm on master. I recreated the bug you were talking about, and the symptoms seem to be the same- green dot never turns red, but docker appears as if it's recording. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 485574] New: Recorder states it's recording, but isn't.
https://bugs.kde.org/show_bug.cgi?id=485574 Bug ID: 485574 Summary: Recorder states it's recording, but isn't. Classification: Applications Product: krita Version: git master (please specify the git hash!) Platform: Kubuntu OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Dockers/Recorder Assignee: krita-bugs-n...@kde.org Reporter: i...@ralek.art Target Milestone: --- I can't reproduce this myself with a new file, but I do have proof that it can and has happened. I don't know what specifically caused/causes it. I'll provide as much detail as I can. I worked for about 5 hours on a drawing, with recording enabled. It produced about 2700 drawings in the KritaRecorder folder. The next day I opened the same file again, made sure the recorder was running, and finished the picture in another 5 hours. When I exported the timelapse, only the first session was saved. I searched, but it appears that Krita did not save any timelapse snapshots for the entire second session despite the recorder stating that it was running. The entire second session was recorded with OBS, and the recorder docker is visibly greyed out with a 'stop' button through the entire session. The bottom 'recording' green/red dot is also visible, but notably- the green dot did not turn red for the entire 5 hours of drawing. Something I didn't notice until I rewatched the recording. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 485515] New: Recorder final preview doesn't show.
https://bugs.kde.org/show_bug.cgi?id=485515 Bug ID: 485515 Summary: Recorder final preview doesn't show. Classification: Applications Product: krita Version: git master (please specify the git hash!) Platform: Kubuntu OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Dockers/Recorder Assignee: krita-bugs-n...@kde.org Reporter: i...@ralek.art Target Milestone: --- When exporting a timelapse, the final frame doesn't show for the amount of selected time in 'Extend result for', but rather the video ends immediately once the last frame is reached. May be related to or a side effect of bug #485514 ffmpeg 6.0-6ubuntu1 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 485514] New: Recorder starting preview overwrites timelapse
https://bugs.kde.org/show_bug.cgi?id=485514 Bug ID: 485514 Summary: Recorder starting preview overwrites timelapse Classification: Applications Product: krita Version: git master (please specify the git hash!) Platform: Kubuntu OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Dockers/Recorder Assignee: krita-bugs-n...@kde.org Reporter: i...@ralek.art Target Milestone: --- - Record a timelapse of (for example) 300 frames - Set the input FPS to 30 so that the timelapse should take 10 seconds - Set the 'Enable preview for' to 9 seconds. Result: The final result shows for 9 seconds, and the timelapse starts 90% of the way through and plays for 1 second. Expected: The final result shows for 9 seconds, and the timelapse starts from scratch and plays for 10 seconds, for a total duration of 19 seconds. ffmpeg 6.0-6ubuntu1 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 485506] New: Recorder snapshots interrupt lasso tools
https://bugs.kde.org/show_bug.cgi?id=485506 Bug ID: 485506 Summary: Recorder snapshots interrupt lasso tools Classification: Applications Product: krita Version: git master (please specify the git hash!) Platform: Kubuntu OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Dockers/Recorder Assignee: krita-bugs-n...@kde.org Reporter: i...@ralek.art Target Milestone: --- If a document is being recorded and a snapshot is taken, any 'actively selecting' tool will suddenly interrupt. For ease of reproduction, set the recording interval to 5 seconds or so. Then, after making a change such as a brush stroke, try to make a selection using the box/circle/free/polygon selection tool. What happens: The selection stops, as if you lifted your pen. Expected: The selection continues and it either delays the saving until after the selection, or saves in the background without interrupting the selection. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 485502] New: Recorder incorrectly resizes stages with different aspect ratios
https://bugs.kde.org/show_bug.cgi?id=485502 Bug ID: 485502 Summary: Recorder incorrectly resizes stages with different aspect ratios Classification: Applications Product: krita Version: nightly build (please specify the git hash!) Platform: Kubuntu OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Dockers/Recorder Assignee: krita-bugs-n...@kde.org Reporter: i...@ralek.art Target Milestone: --- Created attachment 168470 --> https://bugs.kde.org/attachment.cgi?id=168470=edit Showing how canvas aspect ratio squishes the image when exported. When exporting timelapses, Krita squishes and stretches my timelapse to fit the final resolution (Which is not always the resolution or ratio I start with). This causes weird distortion in exported timelapses with a final resolution aspect ratio different than the starting canvas aspect ratio. See attached. To fix this, some extra arguments in the complex filter are necessary. This is an example complex filter Krita currently uses: ``` -filter_complex " [0]loop=$LAST_FRAME_SEC*$IN_FPS:size=1:start=$FRAMES[main1]; [main1]scale=$WIDTH:$HEIGHT[main2]; [main2]loop=1:size=1:start=0[main3]; [main3]setpts=PTS-STARTPTS[main4]; [1]split [first1][transition1]; [transition1]scale=$WIDTH:$HEIGHT [transition2]; [transition2]loop='if(gte($FIRST_FRAME_SEC, 1), 1*$IN_FPS, 0)':size=1:start=1[transition3]; [transition3]setpts=PTS-STARTPTS[transition4]; [transition4][main4]xfade=transition=smoothright:duration=0.5:offset=0[v1]; [v1]setpts=PTS-STARTPTS[v2]; [v2]trim=start_frame=1[v3]; [first1]loop='if(gte($FIRST_FRAME_SEC, 1), ($FIRST_FRAME_SEC*$IN_FPS) - 0.5*$IN_FPS, $FIRST_FRAME_SEC*$IN_FPS)':size=1:start=1[preview1]; [preview1]scale=$WIDTH:$HEIGHT[preview2]; [preview2]setpts=PTS-STARTPTS[preview3]; [preview3][v3] concat [final1]; [final1] setpts=PTS-STARTPTS[final2]; [final2] trim=start_frame=1 " ``` This is my modified complex filter that maintains aspect ratio: ``` -filter_complex " [0]loop=$LAST_FRAME_SEC*$IN_FPS:size=1:start=$FRAMES[main1]; [main1]scale=$WIDTH:$HEIGHT:force_original_aspect_ratio=decrease,pad=$WIDTH:$HEIGHT:(ow-iw)/2:(oh-ih)/2[main2]; [main2]loop=1:size=1:start=0[main3]; [main3]setpts=PTS-STARTPTS[main4]; [1]split [first1][transition1]; [transition1]scale=$WIDTH:$HEIGHT:force_original_aspect_ratio=decrease,pad=$WIDTH:$HEIGHT:(ow-iw)/2:(oh-ih)/2[transition2]; [transition2]loop='if(gte($FIRST_FRAME_SEC, 1), 1*$IN_FPS, 0)':size=1:start=1[transition3]; [transition3]setpts=PTS-STARTPTS[transition4]; [transition4][main4]xfade=transition=smoothright:duration=0.5:offset=0[v1]; [v1]setpts=PTS-STARTPTS[v2]; [v2]trim=start_frame=1[v3]; [first1]loop='if(gte($FIRST_FRAME_SEC, 1), ($FIRST_FRAME_SEC*$IN_FPS) - 0.5*$IN_FPS, $FIRST_FRAME_SEC*$IN_FPS)':size=1:start=1[preview1]; [preview1]scale=$WIDTH:$HEIGHT:force_original_aspect_ratio=decrease,pad=$WIDTH:$HEIGHT:(ow-iw)/2:(oh-ih)/2[preview2]; [preview2]setpts=PTS-STARTPTS[preview3]; [preview3][v3] concat [final1]; [final1] setpts=PTS-STARTPTS[final2]; [final2] trim=start_frame=1 " ``` This fixes the issue by ensuring each step of the filter is scaled down to fit in the final resolution, using `force_original_aspect_ratio=decrease` after each stage to maintain aspect ratio. On top of that, to prevent errors from transition stages having different resolutions, I then pad the output with black pixels. This creates letterboxing sometimes, but I believe nearly every artist would prefer black lines occasionally over a completely squashed and stretched timelapse. If the letterbox could be a blurred and scaled version of the image itself instead of black boxes that could be cool, but I don't know how feasible that is with ffmpeg and the amount of processing it'd take. I believe all that's needed to fix this would be changing all scale filters to have the extra force ratio/pad scale=$WIDTH:$HEIGHT To scale=$WIDTH:$HEIGHT:force_original_aspect_ratio=decrease,pad=$WIDTH:$HEIGHT:(ow-iw)/2:(oh-ih)/2 But I wouldn't know the specifics of how Krita does this, I'm just an artist. This is the fix I apply to every timelapse to fix the weird distortion that happens so I figured I'd report the bug. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 475385] New: Pasting a transform mask crashes Krita immediately
https://bugs.kde.org/show_bug.cgi?id=475385 Bug ID: 475385 Summary: Pasting a transform mask crashes Krita immediately Classification: Applications Product: krita Version: nightly build (please specify the git hash!) Platform: Kubuntu OS: Linux Status: REPORTED Severity: crash Priority: NOR Component: Layer Stack Assignee: krita-bugs-n...@kde.org Reporter: i...@ralek.art Target Milestone: --- If you select a transform mask on any layer, copy it, and attempt to paste it on a different layer, Krita immediately crashes. Version: 5.3.0-prealpha (git 27302a3) -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 475111] Pen stroke lacks pressure and has significant delay on first stroke if under filter layer.
https://bugs.kde.org/show_bug.cgi?id=475111 --- Comment #1 from Ralek Kolemios --- Today I discovered this also applies if you switch frames in an animation. The first stroke lacks pen pressure regardless of if there is a filter layer involved. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 475111] New: Pen stroke lacks pressure and has significant delay on first stroke if under filter layer.
https://bugs.kde.org/show_bug.cgi?id=475111 Bug ID: 475111 Summary: Pen stroke lacks pressure and has significant delay on first stroke if under filter layer. Classification: Applications Product: krita Version: nightly build (please specify the git hash!) Platform: Kubuntu OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Filter Layers Assignee: krita-bugs-n...@kde.org Reporter: i...@ralek.art Target Milestone: --- Created attachment 162012 --> https://bugs.kde.org/attachment.cgi?id=162012=edit Filter layer bug example file SUMMARY After moving the canvas in any way, (panning, zooming, rotating), the first and only the first brush stroke is severely delayed and, if it's a tablet pen, occasionally lacks pen pressure. A less severe version of the bug occurs if the layer is not in a group.I've divided them into bug 1 and 2. Bug 1. If the layer is in a group and under a filter layer, this bug happens every time the canvas is moved. Bug 2. If the layer is outside of a group but under a filter later, the bug only happens the first time the layer is moved under the filter layer in the stack. STEPS TO REPRODUCE BUG 1 1. Open the attached file, select the 'Layer' Layer. 2. Move the canvas in any way 3. Draw a brush stroke. Observe that the pen lacks pressure sensitivity, and the stroke itself is heavily delayed in rendering. BUG 2 1. Open the attached file, move both 'Filter' and "Layer' layers outside of the group. 2. Move the 'Layer' layer above the filter layer 3. Move the 'Layer' layer below the filter layer. 4. Draw a brush stroke Observe that the same bug as bug #1 occurs, but that it only happens once and never again until the layer is moved again. System information Krita Version: 5.3.0-prealpha (git 27302a3) Qt Version (compiled): 5.15.7 Version (loaded): 5.15.7 OS Information Build ABI: x86_64-little_endian-lp64 Kernel Version: 6.2.0-33-generic Pretty Productname: Ubuntu 23.04 OpenGL Info Vendor: "NVIDIA Corporation" Renderer: "NVIDIA GeForce RTX 4090/PCIe/SSE2" Driver version: "4.6.0 NVIDIA 535.104.05" Shading language: "4.60 NVIDIA" Requested format: QSurfaceFormat(version 3.3, options QFlags(), 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 4.6, options QFlags(), 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) GL version: 4.6 Supports deprecated functions false Is OpenGL ES: false supportsBufferMapping: true supportsBufferInvalidation: true forceDisableTextureBuffers: false QPA OpenGL Detection Info supportsDesktopGL: true supportsOpenGLES: true isQtPreferOpenGLES: false Detected renderers: (Supported) NVIDIA GeForce RTX 4090/PCIe/SSE2 (OpenGL ES 3.2 NVIDIA 535.104.05) (Supported) NVIDIA GeForce RTX 4090/PCIe/SSE2 (4.6.0 NVIDIA 535.104.05) Hardware Information Memory: 61 Gb Cores: 32 Swap: /tmp -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 464257] Layer effects not saved if they're the only thing changed.
https://bugs.kde.org/show_bug.cgi?id=464257 Ralek Kolemios changed: What|Removed |Added Resolution|WAITINGFORINFO |--- Status|NEEDSINFO |CONFIRMED --- Comment #5 from Ralek Kolemios --- (In reply to Tiar from comment #3) > @Ralek could you please check Krita Next and see if this issue is resolved? I've tested the latest nightly and I can't seem to get it to save layer styles incorrectly, looks good to me! -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 464256] Tablet pen is incorrectly offset when using non-default QT_SCALE_FACTOR in recent builds
https://bugs.kde.org/show_bug.cgi?id=464256 --- Comment #5 from Ralek Kolemios --- I've discovered this is a QT specific bug that made its way into the recent Krita QT update. Bug was reported here: https://bugreports.qt.io/browse/QTBUG-77826 Workaround to get Krita to correctly track the mouse position is to set the QT_XCB_TABLET_LEGACY_COORDINATES environment variable to an empty string "" like so > QT_XCB_TABLET_LEGACY_COORDINATES="" application -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 464255] X11 connection broken on startup.
https://bugs.kde.org/show_bug.cgi?id=464255 Ralek Kolemios changed: What|Removed |Added Status|NEEDSINFO |RESOLVED Resolution|WAITINGFORINFO |FIXED --- Comment #12 from Ralek Kolemios --- This does seem to have cleared up with a restart, must have been something with the system. Thank you. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 464255] X11 connection broken on startup.
https://bugs.kde.org/show_bug.cgi?id=464255 Ralek Kolemios changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #10 from Ralek Kolemios --- Recently the latest nightly builds (I've tried 8eccca2) have begun to give the same or similar error again, so I'll be reopening this bug. > The X11 connection broke: No error (code 0) > XIO: fatal IO error 22 (Invalid argument) on X server ":0" > after 481 requests (481 known processed) with 0 events remaining. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 466287] Timers cannot have negative intervals crash on startup
https://bugs.kde.org/show_bug.cgi?id=466287 --- Comment #2 from Ralek Kolemios --- Not sure what is causing the crash at startup then, as that's the entire console output. It acts similarly to the bug from not too long ago with the X11 window system, where it wouldn't even make it to the splash screen. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 466287] New: Timers cannot have negative intervals crash on startup
https://bugs.kde.org/show_bug.cgi?id=466287 Bug ID: 466287 Summary: Timers cannot have negative intervals crash on startup Classification: Applications Product: krita Version: nightly build (please specify the git hash!) Platform: Kubuntu OS: Linux Status: REPORTED Severity: crash Priority: NOR Component: * Unknown Assignee: krita-bugs-n...@kde.org Reporter: i...@ralek.art Target Milestone: --- In the latest several nightly master releases, Krita crashes on startup. The output it gives when run in terminal is this: > krita.lib.pigment: Replacing color space factory "LABA" "L*a*b* (16-bit > integer/channel, unmanaged)" with "LABA" "L*a*b*/Alpha (16-bit > integer/channel)" > krita.lib.pigment: Replacing color space factory "RGBA" "RGB (8-bit > integer/channel, unmanaged)" with "RGBA" "RGB/Alpha (8-bit integer/channel)" > krita.lib.pigment: Replacing color space factory "RGBA16" "RGB (16-bit > integer/channel, unmanaged)" with "RGBA16" "RGB/Alpha (16-bit > integer/channel)" > QObject::startTimer: Timers cannot have negative intervals > /tmp/.mount_krita-MpqDCc/usr/lib/krita-python-libs/krita added to PYTHONPATH I have tested from 0e85ce2a to the latest d92f026c -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 464256] Tablet pen is incorrectly offset when using non-default QT_SCALE_FACTOR in recent builds
https://bugs.kde.org/show_bug.cgi?id=464256 --- Comment #4 from Ralek Kolemios --- (In reply to Ralek Kolemios from comment #3) > The pen offset has disappeared entirely, as far as I can tell. It is worth noting this workaround does not apply to dialog windows. Dialog windows are dependent on QT_SCALE_FACTOR. They work properly so long as the top left of the dialog matches exactly with the top left of the screen they are on, otherwise they are offset by the scale amount down and to the right. (Or up and to the left for scale factors smaller than 1) -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 464256] Tablet pen is incorrectly offset when using non-default QT_SCALE_FACTOR in recent builds
https://bugs.kde.org/show_bug.cgi?id=464256 --- Comment #3 from Ralek Kolemios --- Created attachment 155570 --> https://bugs.kde.org/attachment.cgi?id=155570=edit Possible offset origin An update- The amount that the pen is offset on the y axis is not dependent on resolution or scale, it is a product of the monitor's position as viewable by the command xrandr By moving my drawing tablet monitor to have a '0' y axis offset, as reported by xrandr: >DP-0 connected 3840x2160+5440+0 (normal left inverted right x axis y axis) >522mm x 293mm The pen offset has disappeared entirely, as far as I can tell. Within the monitor settings GUI, this is visible as the drawing monitor being neither above nor below the 'bounding box' of all monitors. See attachment -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 464255] X11 connection broken on startup.
https://bugs.kde.org/show_bug.cgi?id=464255 --- Comment #6 from Ralek Kolemios --- This build works and runs for me, thanks! -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 459829] Line tool improperly adjusts pressure points to new line length when end is above the start
https://bugs.kde.org/show_bug.cgi?id=459829 --- Comment #4 from Ralek Kolemios --- Created attachment 155358 --> https://bugs.kde.org/attachment.cgi?id=155358=edit Example #2 5c98a (In reply to Ralek Kolemios from comment #3) > Unfortunately 5c98a and newer builds don't work on my system because of bug > #464255 , but it is still a problem on my last available working build of > 8e8c855 I realize now 5c is the build right before the nonworking one, I've tried it out on that one just now and the problem still persists. See attachment. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 459829] Line tool improperly adjusts pressure points to new line length when end is above the start
https://bugs.kde.org/show_bug.cgi?id=459829 Ralek Kolemios changed: What|Removed |Added Resolution|WAITINGFORINFO |--- Status|NEEDSINFO |REPORTED --- Comment #3 from Ralek Kolemios --- Unfortunately 5c98a and newer builds don't work on my system because of bug #464255 , but it is still a problem on my last available working build of 8e8c855 I took a look at the code a while ago and it appears that every movement of the mouse calls a function which 'repositions' the pen pressure readings onto the new line as the user moves the preview around. Unfortunately because there is a floor() in this function, and the positions are pulled from the last result of the function, and it's called several hundred times a second, the pen pressure readings naturally move up and to the left of the origin of the line as they get rounded down constantly. This effect isn't visible if you're not using pen pressure, and it becomes more noticeable as canvas FPS increases. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 464301] New: Force convert PNG to 8-bit on export option produces significantly worse results than manually downsampling.
https://bugs.kde.org/show_bug.cgi?id=464301 Bug ID: 464301 Summary: Force convert PNG to 8-bit on export option produces significantly worse results than manually downsampling. Classification: Applications Product: krita Version: nightly build (please specify the git hash!) Platform: Kubuntu OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: File formats Assignee: krita-bugs-n...@kde.org Reporter: i...@ralek.art Target Milestone: --- Created attachment 155297 --> https://bugs.kde.org/attachment.cgi?id=155297=edit left- 'Force convert to 8 bit', right - manual merge and convert to 8 bit I've attached a comparison between the two. For some reason, selecting 'Force convert to 8-bit' when exporting as a PNG compresses the image significantly more than manually flattening the image and changing the bit depth to 8 bit. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 464255] X11 connection broken on startup.
https://bugs.kde.org/show_bug.cgi?id=464255 --- Comment #2 from Ralek Kolemios --- (In reply to wolthera from comment #1) > Are you on a wayland session, by any chance? I am not, $XDG_SESSION_TYPE states I'm on x11 right now. I tried Wayland a while ago but it would never initialize a new document, so I've been on x11 until that is officially supported. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 464257] New: Layer effects not saved if they're the only thing changed.
https://bugs.kde.org/show_bug.cgi?id=464257 Bug ID: 464257 Summary: Layer effects not saved if they're the only thing changed. Classification: Applications Product: krita Version: nightly build (please specify the git hash!) Platform: Kubuntu OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: layer styles Assignee: krita-bugs-n...@kde.org Reporter: i...@ralek.art Target Milestone: --- Created attachment 155266 --> https://bugs.kde.org/attachment.cgi?id=155266=edit Outline test document Hello, I'm having an issue right now on 8e8c855 where stroke effects (and other layer effects, as I've found out) cannot be saved if nothing else in the image has been changed, sometimes. I open the file, change the stroke width or color, ctrl+s or file>save, then close and reopen the file to find my changes have not been saved. For some reason this problem is reasonably hard to recreate and I have not been able to reproduce it from a fresh document. I've attached a document with the problem that I can reliable reproduce it on. To reproduce: 1. Open the document, right click 'Group 10' and choose 'Layer Style...' 2. Under 'stroke', set the color to something else, like white. 3. Click 'okay', then 'okay' again. Observe the outline color has changed. 4. ctrl+s or file > save. Notice the * goes away next to the document name. 5. Close the document, and reopen under 'recent documents' 6. Stroke color is the old color I've experimented with other layer styles and it seems to affect most if not all of them as well. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 464256] New: Tablet pen is incorrectly offset when using non-default QT_SCALE_FACTOR in recent builds
https://bugs.kde.org/show_bug.cgi?id=464256 Bug ID: 464256 Summary: Tablet pen is incorrectly offset when using non-default QT_SCALE_FACTOR in recent builds Classification: Applications Product: krita Version: nightly build (please specify the git hash!) Platform: Kubuntu OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: * Unknown Assignee: krita-bugs-n...@kde.org Reporter: i...@ralek.art Target Milestone: --- My current nightly build works fine, build 8e8c855 from a little while ago. When attempting to update to a newer nightly ( 5c98a72 ), I found that my pen is incorrectly offset when using the environment variable QT_SCALE_FACTOR set to anything but 1. For me it is set to 1.5. The distance the pen is offset seems to be proportional to this value. Krita seems to believe the pen is further toward the bottom of the screen than anticipated. As my tablet is 4k and my main monitor is not, and KDE does not currently support fractional scaling, I must scale Krita using QT_SCALE_FACTOR in a bash script before launch. This has worked fine for a couple years now, but no longer works and I'm not sure exactly which build the problem began. OS Information Build ABI: x86_64-little_endian-lp64 Build CPU: x86_64 CPU: x86_64 Kernel Type: linux Kernel Version: 5.19.0-29-generic Pretty Productname: Ubuntu 22.10 Product Type: ubuntu Product Version: 22.10 OpenGL Info Vendor: "NVIDIA Corporation" Renderer: "NVIDIA GeForce RTX 4090/PCIe/SSE2" Version: "4.6.0 NVIDIA 525.60.11" Shading language: "4.60 NVIDIA" 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 4.6, 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) Version: 4.6 Supports deprecated functions true is OpenGL ES: false supportsBufferMapping: true supportsBufferInvalidation: true forceDisableTextureBuffers: false -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 464255] New: X11 connection broken on startup.
https://bugs.kde.org/show_bug.cgi?id=464255 Bug ID: 464255 Summary: X11 connection broken on startup. Classification: Applications Product: krita Version: nightly build (please specify the git hash!) Platform: Kubuntu OS: Linux Status: REPORTED Severity: crash Priority: NOR Component: * Unknown Assignee: krita-bugs-n...@kde.org Reporter: i...@ralek.art Target Milestone: --- On and after master nightly build #1877 ( 68b9c60 ), Krita refuses to launch. It doesn't show the splash screen, and running from console logs this: The X11 connection broke: No error (code 0) XIO: fatal IO error 2 (No such file or directory) on X server ":0" after 474 requests (474 known processed) with 0 events remaining. Builds 15a1672 and 5d13870 suffer the same fate. 5c98a72, which is right before the affected one, does not. OS Information Build ABI: x86_64-little_endian-lp64 Build CPU: x86_64 CPU: x86_64 Kernel Type: linux Kernel Version: 5.19.0-29-generic Pretty Productname: Ubuntu 22.10 Product Type: ubuntu Product Version: 22.10 OpenGL Info Vendor: "NVIDIA Corporation" Renderer: "NVIDIA GeForce RTX 4090/PCIe/SSE2" Version: "4.6.0 NVIDIA 525.60.11" Shading language: "4.60 NVIDIA" 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 4.6, 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) Version: 4.6 Supports deprecated functions true is OpenGL ES: false supportsBufferMapping: true supportsBufferInvalidation: true forceDisableTextureBuffers: false -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 462832] Brush preset docker preview icon resets size when restarting Krita
https://bugs.kde.org/show_bug.cgi?id=462832 Ralek Kolemios changed: What|Removed |Added Resolution|WAITINGFORINFO |WORKSFORME Status|NEEDSINFO |RESOLVED --- Comment #2 from Ralek Kolemios --- Hey, I can't seem to reproduce this bug any more as well. I have rebuilt my computer and reinstalled my OS since filing this report, (from Kubuntu 22.04 to 22.10, maintaining home directory) and it seems the bug has disappeared. Marking as resolved for now. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 457957] Group transformations snap back to original location in preview when containing a filter layer.
https://bugs.kde.org/show_bug.cgi?id=457957 --- Comment #1 from Ralek Kolemios --- Similarly, I have also recently noticed that undoing a transformation like this does not 'work'. It works behind the scenes like the original transformation, but it does not update the canvas. 5.2.0-prealpha (git 220e4cd) -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 463051] Krita crash or close when I make a new canva for animation
https://bugs.kde.org/show_bug.cgi?id=463051 Ralek Kolemios changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 463051] Krita crash or close when I make a new canva for animation
https://bugs.kde.org/show_bug.cgi?id=463051 --- Comment #9 from Ralek Kolemios --- Good to know! If you think this bug should be looked further into, be sure to reopen this bug and include that Krita log file so that we can find out what exactly is going wrong with the graphics acceleration. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 463051] Krita crash or close when I make a new canva for animation
https://bugs.kde.org/show_bug.cgi?id=463051 Ralek Kolemios changed: What|Removed |Added Resolution|--- |WAITINGFORINFO Status|REPORTED|NEEDSINFO --- Comment #7 from Ralek Kolemios --- Alrighty, I'm not seeing anything so far that would cause a crash under normal circumstances, and I can't seem to reproduce it on my end. In Krita, can you go to Help > Show Krita Log and then click 'save to file' and upload that? Did turning off 'Canvas Graphics Acceleration' in Settings > Configure > Display help? -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 463051] Krita crash or close when I make a new canva for animation
https://bugs.kde.org/show_bug.cgi?id=463051 Ralek Kolemios changed: What|Removed |Added CC||i...@ralek.art Resolution|--- |WAITINGFORINFO Status|REPORTED|NEEDSINFO --- Comment #1 from Ralek Kolemios --- Hey there! Unfortunately to help we're going to need a bit more information. Some of the most useful stuff you can give would be a crash report, see this link for how to do that: https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports The next best thing would be to be as specific as possible. Can you provide a screen cap of the 'create new' screen before the crash? What sort of hardware does your laptop have on it? Personally this sounds like a GPU canvas acceleration problem. Can you go into your Krita settings and find "canvas acceleration" and set it to 'software' and see if the problem persists? Any more information you can provide will be helpful, thanks. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 462832] New: Brush preset docker preview icon resets size when restarting Krita
https://bugs.kde.org/show_bug.cgi?id=462832 Bug ID: 462832 Summary: Brush preset docker preview icon resets size when restarting Krita Classification: Applications Product: krita Version: nightly build (please specify the git hash!) Platform: Ubuntu OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Usability Assignee: krita-bugs-n...@kde.org Reporter: i...@ralek.art Target Milestone: --- I keep the brush presets list on 'details' view, with the icon size slid all the way down. Krita no longer saves this, and I must resize the preview icons down each time I open Krita. It does not overwrite the saved 'size', but it rather ignores it, opting for the default size. The last correctly working build I have is 61580cbc5b, with 2ab6b4fdde being the first time I noticed the bug. The regression has continued up to the latest nightly build. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 462831] New: Change 'Merge with layer below' to 'Merge selected' when more than one layer selected.
https://bugs.kde.org/show_bug.cgi?id=462831 Bug ID: 462831 Summary: Change 'Merge with layer below' to 'Merge selected' when more than one layer selected. Classification: Applications Product: krita Version: nightly build (please specify the git hash!) Platform: Ubuntu OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: Usability Assignee: krita-bugs-n...@kde.org Reporter: i...@ralek.art Target Milestone: --- To help usability for new users, the layer docker context menu option 'Merge with layer below' should automatically change to 'Merge selected', 'Merge layers', 'Merge selected layers' or similar when more than one layer is selected. This reads easier and is more contextually correct since the functionality changes and the layers are no longer merging down, but rather together. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 461393] New: QFileDialog no longer allows sorting by column in detail view.
https://bugs.kde.org/show_bug.cgi?id=461393 Bug ID: 461393 Summary: QFileDialog no longer allows sorting by column in detail view. Classification: Applications Product: krita Version: nightly build (please specify the git hash!) Platform: Ubuntu OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Usability Assignee: krita-bugs-n...@kde.org Reporter: i...@ralek.art Target Milestone: --- When using the inbuilt file browser in detail view, the files are unsortable. Right clicking still brings up the column toggle dialog, but left click does not sort by that column. Appimage 5.2.0-prealpha (git 1febf2b) -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 460875] Krita crashes while using ctrl+c and ctrl+v in Vector layers.
https://bugs.kde.org/show_bug.cgi?id=460875 Ralek Kolemios changed: What|Removed |Added Resolution|WORKSFORME |FIXED Status|NEEDSINFO |RESOLVED --- Comment #5 from Ralek Kolemios --- No problem, glad it's resolved! -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 460875] Krita crashes while using ctrl+c and ctrl+v in Vector layers.
https://bugs.kde.org/show_bug.cgi?id=460875 --- Comment #3 from Ralek Kolemios --- (In reply to 458068792 from comment #2) > NO, it isn't. I was copying the element within a layer and paste it into the > same layer, then it crashed. I can't seem to reproduce it on my end, Linux with Krita 5.1.1. Can you download the 5.1.1 update and see if it still happens? If so, could you provide the steps needed so others can reproduce it? -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 460875] Krita crashes while using ctrl+c and ctrl+v in Vector layers.
https://bugs.kde.org/show_bug.cgi?id=460875 Ralek Kolemios changed: What|Removed |Added Resolution|--- |WORKSFORME CC||i...@ralek.art Status|REPORTED|NEEDSINFO --- Comment #1 from Ralek Kolemios --- I believe this is a duplicate of bug 458115, does updating to 5.1.1 fix this issue for you? -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 460863] contiguous selection not functioning
https://bugs.kde.org/show_bug.cgi?id=460863 Ralek Kolemios changed: What|Removed |Added Status|REPORTED|NEEDSINFO Resolution|--- |WORKSFORME CC||i...@ralek.art --- Comment #1 from Ralek Kolemios --- Hello! Unfortunately we're going to need a bit more information to figure out what exactly is going on. When you make a selection, does it not select anything? Does it select everything? Can you take a screen recording of the problem, or maybe a screencap of your current tool options? Does it still happen if you update to the newest version available? -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 460214] New: 'Background image' option for canvas window doesn't work.
https://bugs.kde.org/show_bug.cgi?id=460214 Bug ID: 460214 Summary: 'Background image' option for canvas window doesn't work. Classification: Applications Product: krita Version: nightly build (please specify the git hash!) Platform: Ubuntu OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: OpenGL Canvas Assignee: krita-bugs-n...@kde.org Reporter: i...@ralek.art Target Milestone: --- When setting the background image in General -> Window, the background image does not show behind the canvas after a restart, unless I'm misunderstanding what it's supposed to do. I've tried multiple images, png and jpg, locally and mounted, ext4 and ntfs and no luck. 5.2.0-prealpha (git ff161e4) (Appimage) -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 459829] Line tool improperly adjusts pressure points to new line length when end is above the start
https://bugs.kde.org/show_bug.cgi?id=459829 --- Comment #1 from Ralek Kolemios --- Checking out the math of the tool, it looks like the points along the line slowly get adjusted up and to the left due to floor rounding errors when the angle of the line changes. The same mathematical issue that causes the rotate tool to slide the canvas up and to the left. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 459829] New: Line tool improperly adjusts pressure points to new line length when end is above the start
https://bugs.kde.org/show_bug.cgi?id=459829 Bug ID: 459829 Summary: Line tool improperly adjusts pressure points to new line length when end is above the start Classification: Applications Product: krita Version: nightly build (please specify the git hash!) Platform: Ubuntu OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Tools Assignee: krita-bugs-n...@kde.org Reporter: i...@ralek.art Target Milestone: --- Created attachment 152501 --> https://bugs.kde.org/attachment.cgi?id=152501=edit Examples When using the line tool and drawing from bottom to top, the pressure data is scooted the wrong way if: - The end point is above the start point - The line has been shortened since the last update I believe this is a problem related to negative vectors in the adjustPointsToDDA function in the line tool helper. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 459767] New: Delay before modifier keys can be used after selecting tool is too long.
https://bugs.kde.org/show_bug.cgi?id=459767 Bug ID: 459767 Summary: Delay before modifier keys can be used after selecting tool is too long. Classification: Applications Product: krita Version: nightly build (please specify the git hash!) Platform: Ubuntu OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Usability Assignee: krita-bugs-n...@kde.org Reporter: i...@ralek.art Target Milestone: --- After selecting a tool, using a modifier key when re-entering the canvas is disabled for too long. This leads to unwanted canvas inputs, especially considering the delay is measured from entering the canvas to pressing the modifier key, and not actually using the tool. To reproduce: 1. Make a selection 2. Switch to another selection tool or click the same tool you were using. 3. Hold shift or alt to add or subtract the selection, either while the cursor is still hovering over the tool docker, or within half a second or so of re-entering the canvas. 4. Make the selection Expected: Holding shift will add to the selection, holding alt will remove from selection. Observed: Tool acts as if modifier key is not held down. I understand that there may have to be a delay to differentiate between modifier keys being captured by the tool docker vs the canvas, but it's long enough right now where I run into this issue every time I try to add to a selection. Especially considering I select the tool with the intention of holding shift or alt immediately after, and I can't hold shift or alt while drawing the selection itself. This limitation of the 'earliest' I can hit a modifier, and the 'latest' I can hit a modifier leaves a minuscule gap of time between selecting the tool and drawing to hit it without the selection messing up. With even a modest drawing speed, this gap of time is nonexistent. I don't recall this happening in previous versions, and only noticed it come full force in recent weeks. 5.2.0-prealpha (git b0022ad) -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 459365] Filter layers cause crash on save.
https://bugs.kde.org/show_bug.cgi?id=459365 --- Comment #1 from Ralek Kolemios --- The problem crops up in that specific nightly build, the previous build before it, 477bf9f, does not have the problem. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 459365] New: Filter layers cause crash on save.
https://bugs.kde.org/show_bug.cgi?id=459365 Bug ID: 459365 Summary: Filter layers cause crash on save. Classification: Unclassified Product: krita Version: nightly build (please specify the git hash!) Platform: Ubuntu OS: Linux Status: REPORTED Severity: crash Priority: NOR Component: Filter Layers Assignee: krita-bugs-n...@kde.org Reporter: i...@ralek.art Target Milestone: --- Files containing a filter layer usually crash on save. I've tried about 5 filters and all of them did it. Repro: Create a new file, add a filter layer such as blur, save. Version: 5.2.0-prealpha (git 31ed09f) -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 458804] laggy brush after installation window 11
https://bugs.kde.org/show_bug.cgi?id=458804 Ralek Kolemios changed: What|Removed |Added Resolution|WORKSFORME |NOT A BUG Status|NEEDSINFO |RESOLVED --- Comment #3 from Ralek Kolemios --- Glad to hear it! I'll go ahead and mark this as resolved. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 458804] laggy brush after installation window 11
https://bugs.kde.org/show_bug.cgi?id=458804 Ralek Kolemios changed: What|Removed |Added CC||i...@ralek.art Resolution|--- |WORKSFORME Status|REPORTED|NEEDSINFO --- Comment #1 from Ralek Kolemios --- Hello! If this update to Windows 11 is affecting multiple programs, it unfortunately likely isn't a Krita-specific problem and won't get much help here. If it's a framerate issue, it could be that Windows 11 is too strenuous for your system and more CPU-demanding programs like Krita and Rebelle may lag behind. If it's an issue where lines are not as smooth as they should be, it could be a tablet driver issue. Either way, if it can't be recreated locally on our computers and it's not limited to just Krita, then there's more than likely not really a way to resolve it through code. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 419766] Magic wand doesn't take into account alpha channel with the threshold
https://bugs.kde.org/show_bug.cgi?id=419766 Ralek Kolemios changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 423087] Closing a second open image tab will mess up the rendering of the canvas on the first.
https://bugs.kde.org/show_bug.cgi?id=423087 Ralek Kolemios changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #2 from Ralek Kolemios --- This was fixed shortly after posting, closing. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 419767] Pixel data reference layer(s) to select from
https://bugs.kde.org/show_bug.cgi?id=419767 Ralek Kolemios changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Ralek Kolemios --- Closing request as fixed, glorious work as always. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 413009] Re-initializing canvas interactions/shortcuts after messing with other dockers.
https://bugs.kde.org/show_bug.cgi?id=413009 Ralek Kolemios changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #8 from Ralek Kolemios --- I'm not sure exactly how this got fixed, but quickly moving from dockers to zooming/rotating the canvas no longer captures the shortcut and draws lines instead. Closing this as fixed. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 457957] New: Group transformations snap back to original location in preview when containing a filter layer.
https://bugs.kde.org/show_bug.cgi?id=457957 Bug ID: 457957 Summary: Group transformations snap back to original location in preview when containing a filter layer. Product: krita Version: git master (please specify the git hash!) Platform: Appimage OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: OpenGL Canvas Assignee: krita-bugs-n...@kde.org Reporter: i...@ralek.art Target Milestone: --- Created attachment 151354 --> https://bugs.kde.org/attachment.cgi?id=151354=edit Snap example Under specific circumstances that I haven't been able to reproduce from scratch, transforming a group that contains a filter layer will snap back to its original position in the canvas preview once the transformation completes. This only happens on the 'accurate with instant preview' setting. I've attached a test file that has this problem, simply transform 'group 31' with the transformation tool and press enter. Probably related, the 'move' tool also doesn't work on this group. Both tools do their jobs properly behind the scenes, but the preview does not update until the layer is hidden and re-shown. Version: 5.2.0-prealpha (git 78cca8f) -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 457820] "trim to selection" not working with contiguous selection tool, before or after inverting
https://bugs.kde.org/show_bug.cgi?id=457820 Ralek Kolemios changed: What|Removed |Added Status|REPORTED|CONFIRMED Ever confirmed|0 |1 Keywords||triaged --- Comment #1 from Ralek Kolemios --- Can confirm this happens on nightly appimage builds. Further info: Using the box select tool set to 'intersect' and covering the entirety of the selection fixes this state and allows the original shape to be trimmed to. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 457784] New: Filter layers generate incorrect preview when bounds change.
https://bugs.kde.org/show_bug.cgi?id=457784 Bug ID: 457784 Summary: Filter layers generate incorrect preview when bounds change. Product: krita Version: git master (please specify the git hash!) Platform: Other OS: All Status: REPORTED Severity: normal Priority: NOR Component: Filter Layers Assignee: krita-bugs-n...@kde.org Reporter: i...@ralek.art Target Milestone: --- Created attachment 151268 --> https://bugs.kde.org/attachment.cgi?id=151268=edit Example corruption Occurs on both Linux and Windows builds, on master and on 5.0.6. I have tried reverting 81f9b1aac8 with no luck. When transforming or cropping filter layers, the final preview is incorrect. The canvas shows large holes in the filter layer. See attached. These corruptions are cosmetic, and fix themselves if the affected filter layer is hidden and re-shown. To reproduce : 1. Create a new document 2. Create a new layer other than background and fill with a darker color 3. Create a filter layer above the dark layer. As far as I have tested, it doesn't matter which. 4. Transform the adjustment layer. I've found it seems to show up more the longer the transform process takes. Sometimes it doesn't show up unless you undo the transformation. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 457571] Cmake prebuilt deps download error
https://bugs.kde.org/show_bug.cgi?id=457571 Ralek Kolemios changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |WORKSFORME --- Comment #1 from Ralek Kolemios --- An outdated CMake installation still being referenced by the Krita build environment variables was to blame. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 457571] New: Cmake prebuilt deps download error
https://bugs.kde.org/show_bug.cgi?id=457571 Bug ID: 457571 Summary: Cmake prebuilt deps download error Product: krita Version: git master (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: i...@ralek.art Target Milestone: --- After following along with the Krita build steps for Windows in the documentation, CMake encounters a warning and an error in `download-ext_cideps.cmake` in which `file()` on `127` returns a generic TLS error. The file URL can be accessed manually in a browser as well as through other command line tools such as wget. Occurs both in Windows 10 and 11, and with or without firewall or proxies. Still unsure if it's something specific to my environment. As well as this, there is a warning stating that timout is not supported when using DNS despite the CMake script not defining any timeout. This problem can be circumvented by simply downloading and extracting the prebuilt dependencies yourself, but for the sake of the end user it may be worth it to triage this if it is reproducible. [ 12%] Performing download step (download and verify) for 'ext_cideps' -- File already exists but no hash specified (use URL_HASH): file='C:/krita-dev/fetch-deps/download/krita-deps.zip' Old file will be removed and new file downloaded from URL. -- Downloading... dst='C:/krita-dev/fetch-deps/download/krita-deps.zip' timeout='none' inactivity timeout='none' -- Using src='https://binary-factory.kde.org/job/Krita_Nightly_Windows_Dependency_Build/lastSuccessfulBuild/artifact/krita-deps.zip' CMake Error at ext_cideps-stamp/download-ext_cideps.cmake:168 (message): Each download failed! error: downloading 'https://binary-factory.kde.org/job/Krita_Nightly_Windows_Dependency_Build/lastSuccessfulBuild/artifact/krita-deps.zip' failed status_code: 35 status_string: "SSL connect error" log: --- LOG BEGIN --- timeout on name lookup is not supported Trying 46.4.53.123:443... Connected to binary-factory.kde.org (46.4.53.123) port 443 (#0) schannel: disabled automatic use of client certificate schannel: ALPN, offering h2 schannel: ALPN, offering http/1.1 schannel: initial InitializeSecurityContext failed: SEC_E_ILLEGAL_MESSAGE (0x80090326) - This error usually occurs when a fatal SSL/TLS alert is received (e.g. handshake failed). More detail may be available in the Windows System event log. Closing connection 0 --- LOG END --- mingw32-make.exe[2]: *** [CMakeFiles\ext_cideps.dir\build.make:97: ext_cideps-prefix/src/ext_cideps-stamp/ext_cideps-download] Error 1 mingw32-make.exe[1]: *** [CMakeFiles\Makefile2:82: CMakeFiles/ext_cideps.dir/all] Error 2 mingw32-make.exe: *** [Makefile:90: all] Error 2 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 456998] Performance degrades heavily over time, RAM usage peaks at 11GB.
https://bugs.kde.org/show_bug.cgi?id=456998 --- Comment #18 from Ralek Kolemios --- Created attachment 151084 --> https://bugs.kde.org/attachment.cgi?id=151084=edit Standard stroke completion -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 456998] Performance degrades heavily over time, RAM usage peaks at 11GB.
https://bugs.kde.org/show_bug.cgi?id=456998 --- Comment #17 from Ralek Kolemios --- Created attachment 151083 --> https://bugs.kde.org/attachment.cgi?id=151083=edit Slow stroke completion > Do I understand that correctly, if you just load a lot of documents that > occupy 30GiB of RAM, Krita is not sluggish, but if you work for a long > period of time with these documents, Krita becomes sluggish? Yes. I can make Krita use a lot of ram quickly, but even if it's using 40+gb of ram, it doesn't inherently mean it's sluggish. I've felt it get sluggish when it's been as low as 10gb of ram, and I can also make it smooth while also using 40gb. > If yes, should these doucments (you work with for the long time) be huge in > size? Or any documents will work? The sluggishness only seems to happen with larger documents. This could be correlation though, as larger documents are the only ones I work on for more than 4 hours at a time, while smaller ones usually get finished before then. > 1) What value do you have set in "Undo Limit" option? I have it set to 700 > 2) What maximum size you have assigned to the swap file (on the Performance > tab)? I think when I noticed these first issues cropping up, it was set at 50% or 40GB. I've since changed it to 10GB, but it's hard to tell if it's made a difference as I've had a string of smaller projects recently. >Could you explain in more detail, what do you mean by "sluggish"? Some >specific tools work slower? Or zooming/panning? Or menus? The entire program acts as though I have a worse processor installed. Basically everything that takes time takes more time. Brush stroke rendering, undoing, redoing, filters, hiding/unhiding layers, transforming layers, magic wand, fill tool, etc. I don't notice a difference in menus but the difference may be too small to be noticeable. Panning and zooming doesn't seem to be affected *as* much, but it does seem ever so slightly choppier. > Perhaps you could make a video of this state? Next time I notice it happening I definitely will take more videos, it's just a bit difficult for the large stuff such as transformations as much of what I draw is inappropriate. Right now I only have video of the brush 'stopping' after every stroke, which is usually a sign that Krita is in this 'state'. Compare the two attachments I have added and notice after each stroke, the brush circle stays behind, as if Krita is processing something now that the line is completed. >1) Go to Krita settings, Performance and set "swap undo after" to some really >small value, like 50MiB >2) Restart Krita >3) Open your standard huge document Unfortunately not. Manipulating a large document is still snappy when I first open it. My swap file is on a 7gbps read/write drive so I kind of figured that shouldn't be bottlenecking it. I'm going to be working on some larger documents soon, so I'm going to set my `swap undo after` back to 40GB, and up my undo up to 1000 and see if I can get it acting up so i can do some tests. Thanks for the help! -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 457390] New: Color reference layer method re-computes layer data each time.
https://bugs.kde.org/show_bug.cgi?id=457390 Bug ID: 457390 Summary: Color reference layer method re-computes layer data each time. Product: krita Version: nightly build (please specify the git hash!) Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: minor Priority: NOR Component: Tools/Selection Assignee: krita-bugs-n...@kde.org Reporter: i...@ralek.art Target Milestone: --- When using the fill or wand tool with color reference layers selected, each instance of a fill/select must first re-compute all matching color layers before the operation can continue. This can be a very long process if a large canvas or many layers are included. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 456998] Performance degrades heavily over time, RAM usage peaks at 11GB.
https://bugs.kde.org/show_bug.cgi?id=456998 --- Comment #11 from Ralek Kolemios --- (In reply to Dmitry Kazakov from comment #4) > What is the size of the image you work with? I mean, size in pixels and > average numbel of layers? Theyre at 16bpc, and can be anywhere from 2kx2k to 5kx5k, and have between 10 to 90 layers. I'll give the new nightlies a try and see if I notice any difference. I'm not too familiar with memory leaks, if it doesn't get to the point where I'm running out of memory, shouldn't it theoretically not slow down? By the time Krita gets sluggish I still have a good 90gb or so left of ram. And I doubt it's getting up to that much usage from a leak, I can just as easily open/close a bunch of documents and get Krita's ram usage up to 30gb and still not notice any performance decrease. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 456998] Performance degrades heavily over time, RAM usage peaks at 11GB.
https://bugs.kde.org/show_bug.cgi?id=456998 --- Comment #3 from Ralek Kolemios --- (In reply to Dmitry Kazakov from comment #2) > 1) Does the performance degradation persist if you close the document and > reopen it **without** restarting Krita? > 2) Does the performance degradation persist if you close **all the > documents** and then reopen the document in question **without** restarting > Krita? > 3) Does the performance degradation persist if you close the document, > **restart** Krita and then reopen the document? Heyo! Had a medium length session today and got to try these out. The ram peaked at 6gb, but a previous session I noticed it was 33GB, so the '11gb limit' in the initial post wasn't true. To answer your questions: 1. Yes 2. Yes 3. No? I swear it did before, but with all documents closed I restarted Krita and it went back down to ~300mb of memory. Usually if I restart it seems to keep it. In fact the 'Krita.exe' process in task manager even says Krita remains 'open' even when I close the window. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 456998] Performance degrades heavily over time, RAM usage peaks at 11GB.
https://bugs.kde.org/show_bug.cgi?id=456998 --- Comment #1 from Ralek Kolemios --- Neglected to mention that this is not Windows 11 or 5.2 specific, I believe this has been a problem for me for a couple years now. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 456998] New: Performance degrades heavily over time, RAM usage peaks at 11GB.
https://bugs.kde.org/show_bug.cgi?id=456998 Bug ID: 456998 Summary: Performance degrades heavily over time, RAM usage peaks at 11GB. 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: i...@ralek.art Target Milestone: --- I draw for 5-8 hours at a time, generally. I notice significant performance decreases over time, peaking at around the 2 hour mark and then remaining. Upon opening Krita and a medium size document, memory usage is around 2.3gb. After several hours of drawing, this peaks at around 11GB. I've never seen it go much over that, regardless of document size. I have allocated 80GB of memory to Krita, and I swap undo after 25GB. Swap file size limit is 64GB If I restart Krita and re-open the document, the performance decrease remains, so I'm not sure if it's an undo history problem. This doesn't seem to be true with a full restart, or if Krita is off for a long enough time(?). [ All comparisons are done on the same document, with the same number of layers, after drawing for 4 hours vs restarting computer and opening the document fresh. ] 'Performance decreases' include: - Lower brush rendering speed (40fps vs 65 usual) - Significant delay (110ms vs <16ms) after brush strokes end before the cursor becomes responsive again - Much slower hiding/unhiding of layers. (1-2 seconds vs 30-50ms) - Layer transformation previewing and processing. Beginning a transformation can take multiple seconds for a preview to load. Applying a transformation can take several seconds vs less than a second. - Undo/Redo gets a significant delay (unmeasured, but I can feel it) I haven't noticed much else, but considering most of these make up 95% of my time in front of Krita, it does become very noticeable. Any advice for how to track the cause down on my end during my usual drawing sessions, without negatively impacting my ability to work would be appreciated. - System specs: Windows 11 dev snapshot 22622 AMD 5800X hyperthreading disabled 128GB 3600mhz RAM C: WD Black Gen4 NVME Nvidia RTX 3090 21GB Krita system info dump: Krita Version: 5.2.0-prealpha (git d700876) 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.22622 Pretty Productname: Windows 10 (10.0) Product Type: windows Product Version: 10 OpenGL Info Vendor: "Google Inc. (NVIDIA)" Renderer: "ANGLE (NVIDIA, NVIDIA GeForce RTX 3090 Direct3D11 vs_5_0 ps_5_0, D3D11-30.0.15.1277)" Version: "OpenGL ES 3.0.0 (ANGLE 2.1.0 git hash: f2280c0c5f93+krita_qt5.12.12)" Shading language: "OpenGL ES GLSL ES 3.00 (ANGLE 2.1.0 git hash: f2280c0c5f93+krita_qt5.12.12)" 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 forceDisableTextureBuffers: true -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 413009] Re-initializing canvas interactions/shortcuts after messing with other dockers.
https://bugs.kde.org/show_bug.cgi?id=413009 --- Comment #7 from Ralek Kolemios --- (In reply to vanyossi from comment #4) > After a short consultation with dmitry this actually is intended: There is a > delya implemented to allow for better discrimation of shortcut events from > canvas vs dockers. > > Fixing this is not trivial. If fixing is difficult because it was an intentional delay, can there be a way to allow the user to set this delay themselves if the delay is impeding their workflow? -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 452528] New: Reference images cause low canvas FPS when taking up a large part of the screen.
https://bugs.kde.org/show_bug.cgi?id=452528 Bug ID: 452528 Summary: Reference images cause low canvas FPS when taking up a large part of the screen. Product: krita Version: nightly build (please specify the git hash!) Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: normal Priority: NOR Component: Tools/Reference Images Assignee: krita-bugs-n...@kde.org Reporter: i...@ralek.art Target Milestone: --- 5.1.0-prealpha (git af77a5f) But I've noticed this as far back as 4 When having any sized reference image up, if you zoom too far in while the ref is still on-screen, the FPS can drop as low as 10% of the normal canvas FPS (220 down to 22). To reproduce: - Open a canvas - paste or open a reference image of any size - monitor canvas FPS when panning at various zoom levels on the ref image. Things that affect the FPS directly: - The relative resolution of the canvas docker on the screen (4k screens and full-screen mode have it bad, less noticeable on 1080p screens.) - The percentage of the screen taken up by the reference image. (This variable can go over 100% if more than one reference image is overlaid on top of each other, try placing 5 refs in the same place and make them take up the full screen. Things that DON'T seem to affect the FPS directly: - Canvas zoom level - Scale of the reference image - resolution of the reference image (2000x2000 vs 10x10) - Total number of refs (only percentage of screen taken up) - Color mode or channels of ref images - Whether they're referenced to a file or copied off clipboard - Whether they're overlaid on or off the side of the canvas -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 447522] New: Deleting colorize mask swatch switches to second open canvas and occasionally crashes.
https://bugs.kde.org/show_bug.cgi?id=447522 Bug ID: 447522 Summary: Deleting colorize mask swatch switches to second open canvas and occasionally crashes. Product: krita Version: nightly build (please specify the git hash!) Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: crash Priority: NOR Component: Tools/Colorize Assignee: krita-bugs-n...@kde.org Reporter: i...@ralek.art Target Milestone: --- 5.1.0-prealpha (b27fb80) 1. Create 2 new canvases 2. On the first, create a new layer and add a colorize mask to it 3. Add a stroke on the mask, which creates a color swatch 4. Delete the color swatch 5. Krita switches my current focused canvas to the second one, and occasionally crashes during that. I haven't been able to reliably find a way to reproduce the crash, though it has happened twice in my testing so far. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 445714] New: Regression: Transform tool allows sub-pixel translation
https://bugs.kde.org/show_bug.cgi?id=445714 Bug ID: 445714 Summary: Regression: Transform tool allows sub-pixel translation Product: krita Version: nightly build (please specify the git hash!) Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: normal Priority: NOR Component: Tools/Transform Assignee: krita-bugs-n...@kde.org Reporter: i...@ralek.art Target Milestone: --- Created attachment 143704 --> https://bugs.kde.org/attachment.cgi?id=143704=edit Loss in quality over multiple translations In 5.1.0, both in modern builds (git 4807d9c) and in builds prior to the addition of the 'Preview' transform tool option (git 9ae7dce), translation of a layer with the transform tool introduces sub-pixel translation of layers. When the transformation has been finished and the layer resampled, this introduces a loss in layer quality which can compound over time. (See attached) This is less noticeable on the 'nearest neighbor' resampling method, though has been shown to in rare cases affect this as well, primarily on the edge of the layer. This bug does not occur on the latest main 4.4.8 release -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 443422] New: Textured smudge brush causes square artifacts when drawing on a transparency mask
https://bugs.kde.org/show_bug.cgi?id=443422 Bug ID: 443422 Summary: Textured smudge brush causes square artifacts when drawing on a transparency mask Product: krita Version: nightly build (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: i...@ralek.art Target Milestone: --- Created attachment 142229 --> https://bugs.kde.org/attachment.cgi?id=142229=edit Artifacting of smudge brush on transparency mask This is probably the most specific bug report I've ever made, but here's how to reproduce it: 1. Fill a layer with black 2. Add a transparency mask to the layer 3. Fill the transparency mask with grey (the most obvious color it shows up on) 4. Set your brush to any textured smudge engine brush with any settings and any color and draw You then end up with the attached 5.0.0-beta2 (git 6d23534) -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 443378] Smudge engine brushes do not react to texture settings.
https://bugs.kde.org/show_bug.cgi?id=443378 --- Comment #3 from Ralek Kolemios --- (In reply to Dmitry Kazakov from comment #2) > The fix for this bug is in this MR: > https://invent.kde.org/graphics/krita/-/merge_requests/1081 I can confirm my texture settings are now working on the newest nightly build that included this MR -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 443378] New: Smudge engine brushes do not react to texture settings.
https://bugs.kde.org/show_bug.cgi?id=443378 Bug ID: 443378 Summary: Smudge engine brushes do not react to texture settings. Product: krita Version: 5.0.0-beta1 Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: normal Priority: NOR Component: Brush engines Assignee: krita-bugs-n...@kde.org Reporter: i...@ralek.art Target Milestone: --- In my current version, 5.0.0-beta1 (git 9bd5348), I cannot add any texture settings to a newly created smudge engine brush. The brush acts as if it doesn't consider the 'pattern' and 'strength' settings at all, regardless of any combination of other settings I use. I have yet to get even a semblance of a change in the brush, so I assume it is broken or deprecated on my version. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 439188] Pixel brush and 45 degree lines with line tool creates weird bumps
https://bugs.kde.org/show_bug.cgi?id=439188 --- Comment #3 from Ralek Kolemios --- (In reply to wolthera from comment #2) The only solution I can come up with is a new pixel art brush engine. Each brush position update, calculate if affected pixel's 'center' points are within the circle of the brush, if so, color it in. If not, don't. I'd image the extremely simplified calculations would allow the spacing to be not only extremely small, but possibly even interpolated even further between updates ensuring there's no gaps like what show up currently. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 436422] Concentric ellipse assistant tool fails to draw a perfect circle when using "snap to assistants"
https://bugs.kde.org/show_bug.cgi?id=436422 --- Comment #15 from Ralek Kolemios --- (In reply to Ahab Greybeard from comment #14) > *** Bug 440108 has been marked as a duplicate of this bug. *** > Having to move 200 pixels is excessive but this has been seen before. > It may be that you have a large ppi setting for your image. > > *** This bug has been marked as a duplicate of bug 436422 *** This was it, I was showing a friend what PPI meant a long time ago and set it to 1 for an example. I forgot to change it back or neglected to since I figured it didn't affect anything other than print settings and metadata. +1 for making the distance snapping related to something other than relative real world distance. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 424015] Dragging the title bar out of fullscreen resizes Krita to massive proportions
https://bugs.kde.org/show_bug.cgi?id=424015 --- Comment #4 from Ralek Kolemios --- (In reply to Tiar from comment #1) > Does it not happen for other programs? (I guess not, but I'm asking since I > would guess a dragging from a fullscreen is not something one do with every > program). Especially Qt-based ones like Kdenlive? I've seen it happen with one or two other programs over the years, but they seem to be issues with those specific programs and not with the OS' handling of windows in general as other applications are fine. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 440335] New: Last selected brush is not saved between restarts. Can cause crash if one isn't chosen.
https://bugs.kde.org/show_bug.cgi?id=440335 Bug ID: 440335 Summary: Last selected brush is not saved between restarts. Can cause crash if one isn't chosen. Product: krita Version: nightly build (please specify the git hash!) Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: crash Priority: NOR Component: Resource Management Assignee: krita-bugs-n...@kde.org Reporter: i...@ralek.art Target Milestone: --- When starting Krita for the first time after a full system restart, a default brush is not selected in the brush presets docker. If you attempt to change brush size or draw with any brush-utilizing tool that isn't the basic brush tool without first selecting a brush, Krita will crash without warning or dialogue. 5.0.0 1780194 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 440108] 'Safe zone' before brush begins drawing along assistant is significantly too large.
https://bugs.kde.org/show_bug.cgi?id=440108 Ralek Kolemios changed: What|Removed |Added Resolution|WAITINGFORINFO |--- Assignee|krita-bugs-n...@kde.org |i...@ralek.art Status|NEEDSINFO |REPORTED --- Comment #2 from Ralek Kolemios --- Created attachment 140244 --> https://bugs.kde.org/attachment.cgi?id=140244=edit Spline handles size The distance needed is in canvas pixels, regardless of zoom level or canvas size. You have to move the pen entirely across a 200x200 canvas before it registers. Problem happens with pen or mouse, and at either 100% or 200% dpi (1080 vs 4k) Strange behaviors by assistant type: 2-point: standard, doesn't draw until 200 pixels away from origin Concentric ellipse: If the ellipse is a circle with a diameter of 200 pixels, the pen must move exactly 2rad around the circle before registering. At a diameter of 400 pixels, it moves when it reaches 1rad away. Fisheye: Same as concentric ellipse Infinite: No matter where you start, the next update will be 200 pixels along the line in either direction, starting from the closest point on the line to your origin. It will also draw a line from origin to the infinite ruler before continuing normally, which I think isn't intended. Parallel: Standard. Moves 200 pixels either direction along the guideline. Perspective: Same as 2-point Ruler: The only assistant that seems to work as intended,with no 200-px snapping Spline: Very oddly sized spline 'endpoints' on smaller canvases. I feel like this sort of local vs global size issue might be the same root cause of the 200 pixel snapping. See attached image. Vanishing: Same as 2 point -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 440108] New: 'Safe zone' before brush begins drawing along assistant is significantly too large.
https://bugs.kde.org/show_bug.cgi?id=440108 Bug ID: 440108 Summary: 'Safe zone' before brush begins drawing along assistant is significantly too large. Product: krita Version: nightly build (please specify the git hash!) Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: normal Priority: NOR Component: Tool/Assistants Assignee: krita-bugs-n...@kde.org Reporter: i...@ralek.art Target Milestone: --- When trying to draw using any assistant, the pen must move over 200 pixels in any direction before the line begins drawing. This means you cannot use assistants to draw any lines smaller than 200 pixels. 5.0.0-prealpha (git 672de37), though this started over several weeks ago, as far as I could tell. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 439188] Pixel brush and 45 degree lines with line tool creates weird bumps
https://bugs.kde.org/show_bug.cgi?id=439188 Ralek Kolemios changed: What|Removed |Added CC||i...@ralek.art --- Comment #1 from Ralek Kolemios --- Can confirm this happens on Windows 10 4.4.4-alpha (git cc5d52c) This bug isn't specific to the line tool, it's rather a quirk of how the brush engine works under the hood. You can try to lower the 'spacing' in the brush tools, but so long as the brush 'updates' are delegated by distance rather than at the pixel level, I believe pixel brushes will always suffer from this unless a pixel-art-specific brush engine is created. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 439106] Low pointer polling rates cause inconsistent frame 'timings' in functions tied to pointer movement.
https://bugs.kde.org/show_bug.cgi?id=439106 --- Comment #2 from Ralek Kolemios --- Created attachment 139652 --> https://bugs.kde.org/attachment.cgi?id=139652=edit Proposed fix Text taken from https://krita-artists.org/t/what-makes-kritas-canvas-operations-feel-so-wrong/25377/20?u=ralek My concept for how to fix this. Of course I don't understand the inner working of QT or Krita, I'm just an artist, so this is going off of theoretical data and my desire to help. In the background, asynchronously, a pointer pseudoposition function is constantly receiving inputs from the actual pointer. It keeps the last 2 (or more if you’re a math major) of these positions and timings in-memory for later reference. At any point in time that an action requires an ‘up to date’ and ‘consistent’ but not necessarily extremely accurate pointer position, such as for panning, zooming, rotating, etc, instead of grabbing the current pointer position, it calls the pointerPseudoposition function. This function grabs the current microtime, and extrapolates a ‘current’ pointer position given the previous 2 mouse positions and microtime. I’d imagine the math would look something like: x1 = last known x position x2 = last x position before x1 y1 = last known y position y2 = last y position before y1 time1 = time int in microseconds of last known pointer input time2 = time int in microseconds of previously known pointer input before time1 currentTime = the microseconds of when the function is called newX = x1 + ( (currentTime - time1) / (time1 - time2) * (x1 - x2)) newY = y1 + ( (currentTime - time1) / (time1 - time2) * (y1 - y2)) This will output an X and Y position of the ‘mouse’ which should slot into whatever function the current pan/rotate/zoom function uses when it calls for the mouse position. This will cause slightly weird behavior if the pointer changes directions instantaneously, but for natural movements such as tablet pens, this could be a lifesaver. Perhaps it could be a toggle-able feature called ‘polling rate compensation’. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 439106] Low pointer polling rates cause inconsistent frame 'timings' in functions tied to pointer movement.
https://bugs.kde.org/show_bug.cgi?id=439106 Ralek Kolemios changed: What|Removed |Added CC||i...@ralek.art --- Comment #1 from Ralek Kolemios --- Created attachment 139651 --> https://bugs.kde.org/attachment.cgi?id=139651=edit polling rate comparison A graphic describing why I believe this issue happens. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 409460] Canvas pan & zoom frame 'spacing' inconsistent
https://bugs.kde.org/show_bug.cgi?id=409460 Ralek Kolemios changed: What|Removed |Added Resolution|--- |MOVED Status|REOPENED|RESOLVED -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 439106] New: Low pointer polling rates cause inconsistent frame 'timings' in functions tied to pointer movement.
https://bugs.kde.org/show_bug.cgi?id=439106 Bug ID: 439106 Summary: Low pointer polling rates cause inconsistent frame 'timings' in functions tied to pointer movement. 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: i...@ralek.art Target Milestone: --- Created attachment 139637 --> https://bugs.kde.org/attachment.cgi?id=139637=edit Timelapse of a canvas pan using various input methods 4.4.7-alpha (git 4e4db6a) but is likely widespread. This originally started with bug #409460 I believe that low (<200hz) polling rates in pointer devices causes Krita to receive outdated pointer positions. These outdated positions are taken as truth, and operations such as panning, zooming, and rotating suffer because of it. This causes a weird off-time stuttering seen in the attached images. Attached are several timelapse images of me panning a small canvas across the screen with various devices of different polling rates. I noticed that regardless of device type, the one factor that most closely aligned with the stuttering was that the device polling rate was low. If I had to make an educated guess as an artist and by no means a developer, I feel like when Krita begins to draw a new frame, it asks for the last recorded pointer position. When the pointer's location is updated once every 8ms (125hz, middle-grade Cintiq), this position may be anywhere from 1-8ms old. This causes the stuttering shown in the pictures. On the other hand, when device polling rate is high, such as 1000hz, I believe Krita always receives a <1ms old pointer position, and the problem disappears. I believe fixing this issue one way or the other will be beneficial to myself and other artists, as nearly every tablet on the market polls at around ~100hz, with only top of the line models reaching near 180hz, which still isn't high enough to avoid this issue. A thread was started at https://krita-artists.org/t/what-makes-kritas-canvas-operations-feel-so-wrong/25377 as I was trying to figure out what exactly was causing the issue before filing the bug report, but most necessary information has been condensed into this report. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 409460] Canvas pan & zoom frame 'spacing' inconsistent
https://bugs.kde.org/show_bug.cgi?id=409460 Ralek Kolemios changed: What|Removed |Added Version|4.2.2 |nightly build (please ||specify the git hash!) -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 409460] Canvas pan & zoom frame 'spacing' inconsistent
https://bugs.kde.org/show_bug.cgi?id=409460 Ralek Kolemios changed: What|Removed |Added Status|RESOLVED|REOPENED Ever confirmed|0 |1 Resolution|FIXED |--- --- Comment #58 from Ralek Kolemios --- I'm going to open this issue back up since both 4.4.7 and 5.0 nightly builds have this issue still. Not sure if the fix got lost or overwritten somehow. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 437271] Brush size shortcuts don't affect liquify tool brush size
https://bugs.kde.org/show_bug.cgi?id=437271 Ralek Kolemios changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |NOT A BUG --- Comment #2 from Ralek Kolemios --- (In reply to Halla Rempt from comment #1) Noted, I'll start up a feature request -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 437271] New: Brush size shortcuts don't affect liquify tool brush size
https://bugs.kde.org/show_bug.cgi?id=437271 Bug ID: 437271 Summary: Brush size shortcuts don't affect liquify tool brush size Product: krita Version: nightly build (please specify the git hash!) Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: minor Priority: NOR Component: Tools/Transform Assignee: krita-bugs-n...@kde.org Reporter: i...@ralek.art Target Milestone: --- Brush size increment/decrement shortcuts affect all brush sizes in the program other than the liquify tool 'brush' size. Don't know if intentional or an oversight. 4.4.4 git cc5d52c -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 435201] New: 'Enter' Key doesn't confirm crop.
https://bugs.kde.org/show_bug.cgi?id=435201 Bug ID: 435201 Summary: 'Enter' Key doesn't confirm crop. Product: krita Version: nightly build (please specify the git hash!) Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: normal Priority: NOR Component: Tools Assignee: krita-bugs-n...@kde.org Reporter: i...@ralek.art Target Milestone: --- After selecting an area to crop, hitting the 'enter' key cancels the crop. The only way to confirm a crop is to click the 'crop' button in the tool options docker. Version: 4.4.4-alpha (git 14e244c) -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 423768] Brush presets docker being too large affects performance of brush rendering and UI.
https://bugs.kde.org/show_bug.cgi?id=423768 Ralek Kolemios changed: What|Removed |Added Status|NEEDSINFO |RESOLVED Resolution|WAITINGFORINFO |FIXED --- Comment #6 from Ralek Kolemios --- As far as I can tell, this is no longer an issue in the latest nightly builds. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 433513] New: Only one unnamed autosave works per session.
https://bugs.kde.org/show_bug.cgi?id=433513 Bug ID: 433513 Summary: Only one unnamed autosave works per session. 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: i...@ralek.art Target Milestone: --- d41048c Just crashed after working a couple hours on an unsaved doodle (I know, my bad). Had autosave on every minute since I like to bug report nightly builds, but when I crashed I noticed the only unnamed autosave file in my temp folder was from 4 hours ago, and was from a previous autosaved unnamed sketch that wasn't open anymore. For some reason, my second unnamed sketch didn't save anywhere. Is it possible to add the ability for more than one autosave to be saved? Krita Version: 5.0.0-prealpha (git d41048c) Languages: en_US, en Hidpi: true 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.19042 Pretty Productname: Windows 10 (10.0) Product Type: windows Product Version: 10 OpenGL Info Vendor: "Google Inc." Renderer: "ANGLE (NVIDIA GeForce RTX 2080 Ti 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 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 419767] Pixel data reference layer(s) to select from
https://bugs.kde.org/show_bug.cgi?id=419767 --- Comment #2 from Ralek Kolemios --- Yes, the implementation you provided with the color labels has been an absolute lifesaver hundreds of times so far since being implemented, and I'd consider it a solution to this request. Thank you! -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 401940] More than one Assistant Tool causes black rectangle to appear
https://bugs.kde.org/show_bug.cgi?id=401940 --- Comment #20 from Ralek Kolemios --- I've never experienced this with the vanishing point ruler, but I've intermittently experienced it with small parallel rulers, and very often with fisheye perspective rulers -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 428317] New: Tracking rulers update at <1 FPS when non brush tool selected.
https://bugs.kde.org/show_bug.cgi?id=428317 Bug ID: 428317 Summary: Tracking rulers update at <1 FPS when non brush tool selected. Product: krita Version: nightly build (please specify the git hash!) Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: normal Priority: NOR Component: Tool/Assistants Assignee: krita-bugs-n...@kde.org Reporter: i...@ralek.art Target Milestone: --- When using rulers that track the cursor, such as the vanishing point ruler, the update speed can drop as low as 1 or less FPS, or even freeze, when any tool that doesn't use a brush is selected. (Selection shapes, vector tools, crop tool, wand, etc) Version: 4.4.1-alpha (git 6b4d1ed) -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 428315] New: Freehand selection artifacts when interacting with some guide ruler lines.
https://bugs.kde.org/show_bug.cgi?id=428315 Bug ID: 428315 Summary: Freehand selection artifacts when interacting with some guide ruler lines. 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: i...@ralek.art Target Milestone: --- Created attachment 132778 --> https://bugs.kde.org/attachment.cgi?id=132778=edit Artifacting example When in the process of drawing a freehand selection, it can create 'artifacting' if a guide ruler also draws a line over the cursor position. Attached is an example. How to reproduce: Add some vanishing point guides create a freehand selection and take note of the area surrounding the cursor position. Version: 4.4.1-alpha (git 6b4d1ed) -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 427466] New: Attempting to load reference image from clipboard throws error.
https://bugs.kde.org/show_bug.cgi?id=427466 Bug ID: 427466 Summary: Attempting to load reference image from clipboard throws error. Product: krita Version: nightly build (please specify the git hash!) Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: normal Priority: NOR Component: Tools/Reference Images Assignee: krita-bugs-n...@kde.org Reporter: i...@ralek.art Target Milestone: --- When using the clipboard button in the reference image tool options menu, it will always throw the error "Could not load reference image from clipboard", regardless if the clipboard is empty, if it contains non-image data, or any image format of any size. Krita 4.4.1-alpha (git c0166ba) Qt 5.12.9 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 413009] Re-initializing canvas interactions/shortcuts after messing with other dockers.
https://bugs.kde.org/show_bug.cgi?id=413009
--- Comment #5 from Ralek Kolemios ---
Regardless if it's trivial or not, it's causing multiple other problems for me.
For instance my recent bug report https://bugs.kde.org/show_bug.cgi?id=425087
was later found to be caused by this way of handling shortcuts.
After getting fed up with not being able to reproduce the issue, I decided to
constantly record my screen and inputs until it happened again. Sure enough it
did, and upon reviewing the footage, I found that my 'zoom' keyboard shortcut,
set to `G`, was switching my current active layer to "Group".
Why this is a major problem:
Let's say I want to switch layers, and then zoom into the canvas. Simple right?
How it should work:
- I click the layer.
- I hold my drag-zoom shortcut
- I drag my pen on the canvas to zoom
How I currently have to do it to workaround this issue:
- I click the layer
- I click the canvas to make it focus, which draws a dot
- I press my eraser toggle shortcut to switch to eraser
- I erase the dot I was just forced to make
[Alternatively I can hit undo]
- I hold my drag-zoom shortcut
- I drag my pen on the canvas to zoom
Solution:
Either make clicking on the canvas docker /only/ focus it, or make it
automatically focus on hover ("Focus" being, disable all other docker-specific
shortcuts like "G" selecting a group layer in the layers docker). Anything else
is extremely annoying.
--
You are receiving this mail because:
You are watching all bug changes.
[krita] [Bug 425575] New: Separate opacity curve for eraser.
https://bugs.kde.org/show_bug.cgi?id=425575 Bug ID: 425575 Summary: Separate opacity curve for eraser. Product: krita Version: unspecified Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: wishlist Priority: NOR Component: Brush engines Assignee: krita-bugs-n...@kde.org Reporter: i...@ralek.art Target Milestone: --- I have several 'sketch' brushes which have a curve that barely ever reaches 100% unless I push hard, and when I want the line to be thicker I do push harder. However when switching to eraser mode, it keeps the same curve and is thus nearly impossible for me to fully erase a line, since the eraser also almost never reaches 100% opacity. I have to push very hard to erase a line completely, and even go over it several times. I've started getting hand cramps from having to push so hard. "Separate opacity for brush and eraser" setting doesn't help, because I want the dynamic range of opacity available for my actual brush, while the eraser version either has a separate curve altogether, or simply ignores the pressure curve and goes by the opacity setting. (Maybe a toggle to ignore the curve?) -- You are receiving this mail because: You are watching all bug changes.
