[kdenlive] [Bug 487957] New: Cancelling a job (or dragging to timeline) causes Segmentation fault
https://bugs.kde.org/show_bug.cgi?id=487957 Bug ID: 487957 Summary: Cancelling a job (or dragging to timeline) causes Segmentation fault Classification: Applications Product: kdenlive Version: 24.05.0 Platform: Other OS: Linux Status: REPORTED Severity: critical Priority: NOR Component: User Interface Assignee: j...@kdenlive.org Reporter: k...@mortalpowers.com Target Milestone: --- SUMMARY Every time I try to start a new project, I get a Segmentation Fault. It seems to be related to job cancellation as it happens when I cancel jobs, or when I drag affected clips with zombie / boken jobs to the timeline. STEPS TO REPRODUCE 1. Drag files into bin 2. Cancel processing jobs after they stall Video of reproduction: https://youtu.be/hsTIyWICfKw OBSERVED RESULT ``` https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports ``` EXPECTED RESULT Clips successfully imported or moved to timeline. SOFTWARE/OS VERSIONS Linux/KDE Plasma: 6.8.0-31-generic #31-Ubuntu SMP PREEMPT_DYNAMIC Sat Apr 20 00:40:06 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux KDE Plasma Version: 5.27.11 KDE Frameworks Version: 5.115.0 Qt Version: 5.15.13 Graphics Platform: X11 Kdenlive 24.05.0 AppImage Distribution ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 461319] WireGuard connection doesn't save persistent-keepalive value.
https://bugs.kde.org/show_bug.cgi?id=461319 Stephen Robinson changed: What|Removed |Added CC||stephen.robin...@eqware.net -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 479179] KDE Network Manager creates unusable name for wireguard and fails to save
https://bugs.kde.org/show_bug.cgi?id=479179 Stephen Robinson changed: What|Removed |Added CC||stephen.robin...@eqware.net --- Comment #6 from Stephen Robinson --- I created a merge request to solve this by adding an interface name field to the wireguard configuration widget: https://invent.kde.org/plasma/plasma-nm/-/merge_requests/339 -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 412795] Wireguard set up fails with erros -settings lost
https://bugs.kde.org/show_bug.cgi?id=412795 --- Comment #12 from Stephen Robinson --- Antti, I changed the BUG number in my merge request and commit to 479179. -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 412795] Wireguard set up fails with erros -settings lost
https://bugs.kde.org/show_bug.cgi?id=412795 --- Comment #10 from Stephen Robinson --- I have created a merge-request to resolve this: https://invent.kde.org/plasma/plasma-nm/-/merge_requests/339 -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 412795] Wireguard set up fails with erros -settings lost
https://bugs.kde.org/show_bug.cgi?id=412795 --- Comment #9 from Stephen --- I looked at the other network-manager editors (eg nm-connection-editor), and they do include a separate "interface" field that is distinct from the name. I have looked into the plasma-nm repo, and I think I have my head wrapped around how to make this change. I haven't done any KDE work before, so I'm getting kdesrc-build set up. Then I am going to take a crack at fixing this issue. -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 412795] Wireguard set up fails with erros -settings lost
https://bugs.kde.org/show_bug.cgi?id=412795 Stephen changed: What|Removed |Added CC||kdeb...@drsudo.com --- Comment #8 from Stephen --- I experienced this too, and was very frustrated by it (especially the default name being invalid and losing my config). I thought that I could add a little bit of explanation to it. The name of the connection is being used as the Linux interface name (The list of names that you get if you type "ip link" at a terminal). AFAIK, other VPN types (such as OpenVPN) in the network manager don't do this. I have an OpenVPN connection up right now, and it gets the interface name "tun0". This has nothing to do with the name that I put in the network manager. The consistent behavior would be to have the wireguard network get named something like "wg0" regardless of what it is called in the network manager. On the other hand having the Linux interface get a nice name is really cool. I think the ideal would be if there was "interface name" field in the wireguard setup UI, and the connection name was decoupled from the interface name. -- You are receiving this mail because: You are watching all bug changes.
[KScreen] [Bug 482974] Resolution changes after switching off the monitor
https://bugs.kde.org/show_bug.cgi?id=482974 --- Comment #6 from Stephen Baker --- My situation is so different that it may be completely unrelated: I am on Wayland, my card is an AMD 7800XT, and I am using the open source mesa drivers. Unlike boospy I cannot not reproduce on demand, I have seen it happen 2 or 3 times since upgrading to KDE 6. It may be helpful to ignore my situation until I can at least gather some more information and see if the root cause is the same or not. -- You are receiving this mail because: You are watching all bug changes.
[KScreen] [Bug 482974] Resolution changes after switching off the monitor
https://bugs.kde.org/show_bug.cgi?id=482974 Stephen Baker changed: What|Removed |Added CC||cyco...@hotmail.com --- Comment #1 from Stephen Baker --- I have seen this twice myself since switching to KDE 6. In my case my normal resolution is 3840x2160 and it switches to 1280x1024. I am able to restore everything through display settings, but only if I switch to an intermediate resolution like 1920x1080 first; otherwise I'm unable to click the Apply button and it automatically reverts. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 412011] Changing cursor color to black in settings makes the brush outline to disappear
https://bugs.kde.org/show_bug.cgi?id=412011 stephen changed: What|Removed |Added CC||tgdev...@gmail.com --- Comment #4 from stephen --- (In reply to Tiar from comment #3) > I think this might be closed as INTENTIONAL... or changed to wish. Ahab's > explanation on why this happens is correct. I guess a simple fix would be to > use a grey outline instead. Not gray outline. But pure white/black outline depending on the color it hovers on. Can be added as a new color mode for the cursor. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 482109] New: Crash opening CorsixTH
https://bugs.kde.org/show_bug.cgi?id=482109 Bug ID: 482109 Summary: Crash opening CorsixTH Classification: Applications Product: kdevelop Version: 5.12.230805 Platform: Arch Linux OS: Linux Status: REPORTED Severity: crash Priority: NOR Component: All build tools Assignee: kdevelop-bugs-n...@kde.org Reporter: cyco...@hotmail.com Target Milestone: --- Created attachment 166227 --> https://bugs.kde.org/attachment.cgi?id=166227=edit backtrace for all threads SUMMARY kdevelop crashes when opening CorsixTH. It happens every time, but does not happen with other cmake projects. STEPS TO REPRODUCE 1. git clone g...@github.com:CorsixTH/CorsixTH.git 2. git checkout 2ff725815dab3adbc060130fcf7ef971efba96e0 # current master 3. ensure dependencies are installed: sdl2, sdl2_mixer, catch2, doxygen, ffmpeg, wxwidgets, lua, freetype 4. open kdevelop 5. click open/import project 6. select the CMakeList.txt file from CorsixTH root directory 7. click Finish 8. under "Extra arguments" add "-DBUILD_ANIMVIEW=ON" # it does not crash without this option 9. click OK OBSERVED RESULT kdevelop begins to open the project, then at some % (varies) it crashes. EXPECTED RESULT project should be opened SOFTWARE/OS VERSIONS Linux/KDE Plasma: (available in About System) KDE Plasma Version: 5.27.10 KDE Frameworks Version: 5.115.0 Qt Version: 5.15.12 ADDITIONAL INFORMATION I use wayland -DBUILD_ANIMVIEW pulls in wxwidgets, that's the most distinguishing feature of that option; but I can't say it's the cause of the crash. -- You are receiving this mail because: You are watching all bug changes.
[kdiff3] [Bug 478707] New: Support starting a merge with one side chosen everywhere
https://bugs.kde.org/show_bug.cgi?id=478707 Bug ID: 478707 Summary: Support starting a merge with one side chosen everywhere Classification: Applications Product: kdiff3 Version: unspecified Platform: Other OS: Other Status: REPORTED Severity: wishlist Priority: NOR Component: application Assignee: reeves...@gmail.com Reporter: stephen.g.jenni...@gmail.com Target Milestone: --- SUMMARY jj is a Git-compatible source control system that encourages editing revisions in-place. To edit a revision, several commands open a diff editor. For example, `jj diffedit` opens a directory comparison with a diff editor, and expects the right (side B) to be edited in-place. KDiff3 works for this purpose, but requires the user to explicitly "Choose B Everywhere". This is the command line used by default. I experimented but could not find any options that would do what I wanted: kdiff3 --merge --cs CreateBackFiles=0 $left $right For comparison, Beyond Compare can open the diff editor with the right side editable with the following command line: bcomp $left $right /leftreadonly Meld does this with: meld $left $right POSSIBLE IMPLEMENTATION OPTIONS One option would be a command line option --inplace which would edit the output directory in-place when used with --merge. I think this would have to be mutually exclusive with -o. Another option would be command line options --edit-a and --edit-b to make the A or B sides of a diff (opened with `kdiff3 $left $right`) editable. A third option would be a command line option that instructs KDiff3 to start with "Choose B Everywhere" in all files, something like: kdiff3 --merge --choose-b-everywhere $left $right -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 477082] New: Clock widget's seconds not actually aligned to seconds
https://bugs.kde.org/show_bug.cgi?id=477082 Bug ID: 477082 Summary: Clock widget's seconds not actually aligned to seconds Classification: Plasma Product: plasmashell Version: 5.27.9 Platform: Debian testing OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: Digital Clock Assignee: plasma-b...@kde.org Reporter: s.horv...@ieee.org Target Milestone: 1.0 Created attachment 163212 --> https://bugs.kde.org/attachment.cgi?id=163212=edit A screenshot of the clock widget with a Konsole window running `watch -n 0.1 date`, the clock widget is a second behind. SUMMARY The Clock Widget with seconds enabled can be up to a whole second behind (see attachment). For performance reasons I am okay if it doesn't tick *exactly* on the second, but I'd hope it to be not that noticeable (e.g. maybe it syncs up once a minute, and has a ~1000ms interval after then?) STEPS TO REPRODUCE 1. Have the clock widget with shown seconds added somewhere 2. Load up another clock, I just used `watch -n 0.1 date` 3. Compare the clocks OBSERVED RESULT The clock usually doesn't tick anywhere near exactly on the second, but rather sometime after. EXPECTED RESULT The clock would be visually in time with any other clock on the system. SOFTWARE/OS VERSIONS KDE Plasma Version: 5.27.9 KDE Frameworks Version: 5.107.0 Qt Version: 5.15.10 ADDITIONAL INFORMATION Sorry if this is a very minor issue, I just noticed it while waiting for an exam to start, and it was all I could think about. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 473459] Line Tool produces wobbly lines
https://bugs.kde.org/show_bug.cgi?id=473459 stephen changed: What|Removed |Added CC||tgdev...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[plasma-systemmonitor] [Bug 470474] new nvidia beta driver (535 series) not showing statistics
https://bugs.kde.org/show_bug.cgi?id=470474 --- Comment #8 from Stephen Greenham --- Observed yesterday this is affecting more than just Plasma System Monitor. The built-in in-game overlay in Overwatch 2 used to be able to display GPU temperature but now displays 0C. So I guess the way NVIDIA provides the data has fundamentally changed. Nice of them to tell anyone... -- You are receiving this mail because: You are watching all bug changes.
[plasma-systemmonitor] [Bug 471193] New: GPU Graphs no longer pulling data
https://bugs.kde.org/show_bug.cgi?id=471193 Bug ID: 471193 Summary: GPU Graphs no longer pulling data Classification: Applications Product: plasma-systemmonitor Version: 5.27.5 Platform: Archlinux OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: general Assignee: ksysguard-b...@kde.org Reporter: stephen.green...@gmail.com CC: ahiems...@heimr.nl, plasma-b...@kde.org Target Milestone: --- Created attachment 159763 --> https://bugs.kde.org/attachment.cgi?id=159763=edit Screenshot of system monitor with GPU graphs SUMMARY *** NOTE: If you are reporting a crash, please try to attach a backtrace with debug symbols. See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** STEPS TO REPRODUCE 1. Update to Nvidia drivers version 535.54.03 on a system with an Nvidia GPU 2. Look at graphs in the system monitor OBSERVED RESULT See attachment, GPU graphs are no longer populating EXPECTED RESULT GPU graphs populating (This was working before the driver upgrade) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 461367] xfreerdp /multimon Does Not Work with Legacy Scaling set to "Apply Scaling Themselves"
https://bugs.kde.org/show_bug.cgi?id=461367 --- Comment #8 from Stephen Ackerman --- Still an issue with Plasma Wayland under Debian Testing packaged: Plasma 5.27.5 Frameworks 5.103.0 Qt 5.15.8 Mesa 22.3.6 Kernel 6.3.7 (Mainline + Debian Config) -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 469217] 23.04.0 is leading to "INVALID" renders and corrupted files
https://bugs.kde.org/show_bug.cgi?id=469217 --- Comment #6 from Stephen Fluin --- The errors have changed, but not been fixed. Using kdenlive-master-574-linux-gcc-x86_64.AppImage, and the same project file as above. When I try to load the file I get a sequence of 3 errors that result in an empty project. Screenshots here: https://photos.app.goo.gl/uys4bokQtyXKo8h1A 1. '"" the project contains missing clips or files' 2. 'Found an invalid sequence clip in Bin' 3. 'Could not recover corrupted file' -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 469217] 23.04.0 is leading to "INVALID" renders and corrupted files
https://bugs.kde.org/show_bug.cgi?id=469217 Stephen Fluin changed: What|Removed |Added Resolution|WAITINGFORINFO |--- Status|NEEDSINFO |REPORTED --- Comment #2 from Stephen Fluin --- I can confirm it was still happening with the hotfix release, I was using AppImage kdenlive-23.04.0a-x86_64.AppImage . (In reply to Julius Künzel from comment #1) > Hi Stephen, > > thanks for your report and sorry, you're having trouble. We published a > hotfix release yesterday, which might fix your issue. See > https://kdenlive.org/en/2023/04/23-04-0a-hotfix-release/ > > Please tell us if the issue still exists with hotfix release. I can promise > you we are working hard to fix remaining bugs introduced by the new nested > timeline feature. If it is essential to you to have the most stable version > of Kdenlive a general recommendation would be to use *.3 (bugfix) release as > they are the most stable ones, while *.0 releases contain new features which > are more likely to introduce regressions that have not been uncovered yet. > > Please remember to set the correct bug status when you answer (either back > to REPORTED or to RESOLVED CLOSE) -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 463982] A Portrait clip Proxied as Landscape
https://bugs.kde.org/show_bug.cgi?id=463982 --- Comment #3 from Stephen Esseenyne --- Created attachment 157542 --> https://bugs.kde.org/attachment.cgi?id=157542=edit portrait clip proxied rendered as portrait The problem is the proxy has taken it upon itself to rotate etc. Which means to the naked eye it looks fine. But in the render it is portrait. This is not in the overnight build back in January. This is in _stable_ version 22.12.2, KDE F/w 5.102.0, Qt 5.15.8 -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 463982] A Portrait clip Proxied as Landscape
https://bugs.kde.org/show_bug.cgi?id=463982 --- Comment #2 from Stephen Esseenyne --- Created attachment 157541 --> https://bugs.kde.org/attachment.cgi?id=157541=edit Portrait (unproxied) as Portrait -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 463982] A Portrait clip Proxied as Landscape
https://bugs.kde.org/show_bug.cgi?id=463982 --- Comment #1 from Stephen Esseenyne --- Created attachment 157540 --> https://bugs.kde.org/attachment.cgi?id=157540=edit Portrait clip proxied as Landscape -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 466859] My Huion tablet doesn't seem to work on your system.
https://bugs.kde.org/show_bug.cgi?id=466859 Stephen Wilson changed: What|Removed |Added CC||c...@stephenawilson.ca --- Comment #1 from Stephen Wilson --- Hmm, it may be related to the tablet input method. Under Settings -> configure Krita -> Tablet Settings, try changing to WinTab or Windows Ink and restart. That may fix the issue, and you can also check the tablet tester to see what Krita is registering. Krita can also provide a more detailed account of your OS and Krita versions under Help -> Show System Info -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 465874] Invalid tablet's input handling
https://bugs.kde.org/show_bug.cgi?id=465874 Stephen Wilson changed: What|Removed |Added CC||c...@stephenawilson.ca --- Comment #1 from Stephen Wilson --- Can also confirm this is an issue for me as well Krita Version: 5.2.0-prealpha (git fc87a54) Installation type: installer / portable package Hidpi: true Qt Version (compiled): 5.15.7 Version (loaded): 5.15.7 OS Information Build ABI: x86_64-little_endian-llp64 Build CPU: x86_64 CPU: x86_64 Kernel Type: winnt Kernel Version: 10.0.22621 Pretty Productname: Windows 10 Version 2009 Product Type: windows Product Version: 10 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 447010] Documents created from templates unexpectedly reuse template's metadata such as total editing time, created/modified date, revision number
https://bugs.kde.org/show_bug.cgi?id=447010 Stephen Wilson changed: What|Removed |Added Version Fixed In|5.2.0 | -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 447010] Documents created from templates unexpectedly reuse template's metadata such as total editing time, created/modified date, revision number
https://bugs.kde.org/show_bug.cgi?id=447010 Stephen Wilson changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 447010] Documents created from templates unexpectedly reuse template's metadata such as total editing time, created/modified date, revision number
https://bugs.kde.org/show_bug.cgi?id=447010 Stephen Wilson changed: What|Removed |Added Latest Commit||https://invent.kde.org/grap ||hics/krita/-/commit/26c48dc ||4af5c80ac6930ea8a0bc0dd2ea1 ||c6cc6b Version Fixed In||5.2.0 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 447010] Documents created from templates unexpectedly reuse template's metadata such as total editing time, created/modified date, revision number
https://bugs.kde.org/show_bug.cgi?id=447010 Stephen Wilson changed: What|Removed |Added See Also||https://invent.kde.org/grap ||hics/krita/-/merge_requests ||/1769 --- Comment #7 from Stephen Wilson --- MR opened: https://invent.kde.org/graphics/krita/-/merge_requests/1769 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 466771] KDE 5.26.x/5.27.x has terrible uptime ...
https://bugs.kde.org/show_bug.cgi?id=466771 --- Comment #2 from Stephen --- toggling the desktop effects... After toggling the desktop effects, it clears up the painting issue, but only briefly. Between minutes to maybe an hour or two. It's a temporary hack to return the desktop's usability, but whatever's causing issue is not corrected entirely (resetting via init S or rebooting resets things to the 2-3 days state before the issue appears). -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 466771] KDE 5.26.x/5.27.x has terrible uptime ...
https://bugs.kde.org/show_bug.cgi?id=466771 --- Comment #1 from Stephen --- Immediately after I filed this report, it started happening again. I tried toggling the desktop effects (Alt+Shift+F12) and its seems to have cleared it up ... -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 466771] New: KDE 5.26.x/5.27.x has terrible uptime ...
https://bugs.kde.org/show_bug.cgi?id=466771 Bug ID: 466771 Summary: KDE 5.26.x/5.27.x has terrible uptime ... Classification: Plasma Product: kwin Version: 5.27.0 Platform: Fedora RPMs OS: Linux Status: REPORTED Severity: major Priority: NOR Component: compositing Assignee: kwin-bugs-n...@kde.org Reporter: ywre6...@gmail.com Target Milestone: --- KDE starts beautifully, then eventually decays to visible un-usability ... *** After a reboot KDE/Plasma runs beautifully. However after a certain amount of time, usually 3-5 days, windows "appear" to be (re)painted completely black, or are not painted at all (it's hard to tell since it happens so fast). (In X, everything is a window of some type; menus, window contents (I haven't seen decorations do this behaviour yet, but have seen it with all components of the task bar.)) When this happens the following are sometimes TRUE: 1. when resizing is available, sometimes resizing the window provides visibility to its painted contents (this is hit or miss and the contents will flash correctly or not); 2. sometimes iconifing the window, or closing and re-opening the window will allow visibility to its painted contents; and likewise dismissing and reengaging a menu (window) will allow the menu to be visibility painted. 3. This happens across all applications, even programs written in basic X (e.g. /usr/bin/xv) to wildly complex programs like firefox and everything in between. My workspace consists of 4 virtual desktops and switching to another desktop and back has no effect on windows painted as "black." > I really don't know if the window is "properly" rendered then over-painted as > the process is too quick for the eye ...? When it happens, I have to exit the workspace and init S/control-D to reload everything back to "clean the slate," but this is temporary and eventually the cycle repeats. I had hoped 5.27 would have cleaned this up, but it's still there. *** STEPS TO REPRODUCE: 1. Run the workspace for several days including cycles of screen locking, etc. 2. Use the workspace normally (I run several konsoles, firefox, thunderbird, and a few other applications on and off). OBSERVED RESULT Eventually, some windows will be painted as "black." Kinda happens infrequently at first, then becomes more and more common as time progresses. EXPECTED RESULT I'm used to uptimes measured in the years and expect no less from my workspace. I upgraded from Fedora 34 KDE (exactly the same hardware) and have never seen this happen. HACKS TRIED: - most of the kernels released under Fedora 37 - NVIDIA-Linux-x86_64-515.76.run, NVIDIA-Linux-x86_64-520.56.06.run, NVIDIA-Linux-x86_64-525.60.11.run, and NVIDIA-Linux-x86_64-525.89.02.run. - I did NOT think to disable desktop effects (I will if it happens again) to see what happens. SOFTWARE/OS VERSIONS: Operating System: Fedora Linux 37 KDE Plasma Version: 5.27.0 KDE Frameworks Version: 5.103.0 Qt Version: 5.15.8 Kernel Version: 6.1.12-200.fc37.x86_64 (64-bit) Graphics Platform: X11 Processors: 16 × AMD Ryzen 7 1700 Eight-Core Processor Memory: 62.7 GiB of RAM Graphics Processor: NVIDIA GeForce GTX 1060 3GB/PCIe/SSE2 ADDITIONAL INFORMATION Appearance - Breeze Dark Application style - Breeze Plasma Style - Infinity-plasma Windows decorations - Breeze DESKTOP EFFECTS: Magnifier, Mouse Mark, Translucency, Wobbly Windows Virtual Desktop Switching - slide w/desktop background DISABLEd WINDOW BEHAVIOUR: Focus under mouse w/raise on hover after 750ms 4x Virtual desktops on TWO physical monitors xwininfo: Window id: 0x1c00011 "Desktop — Plasma" Absolute upper-left X: 2560 Absolute upper-left Y: 0 Relative upper-left X: 0 Relative upper-left Y: 0 Width: 2560 Height: 1440 Depth: 32 Visual: 0x7a Visual Class: TrueColor Border width: 0 Class: InputOutput Colormap: 0x1c00010 (not installed) Bit Gravity State: NorthWestGravity Window Gravity State: NorthWestGravity Backing Store State: NotUseful Save Under State: no Map State: IsViewable Override Redirect State: no Corners: +2560+0 -0+0 -0-0 +2560-0 -geometry 2560x1440-0+0 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 461367] xfreerdp /multimon Does Not Work with Legacy Scaling set to "Apply Scaling Themselves"
https://bugs.kde.org/show_bug.cgi?id=461367 --- Comment #7 from Stephen Ackerman --- Further testing with Debian Frameworks 5.103 + Plasma 5.27.0-1 (shows as 5.26.90 in System Settings? Looks like 5.27.2 is pending a release into Testing) revealed the following behavior: The off-by-one-pixel issue went away if I used 125% scaling instead of 130%, as inspired by Plasma X11 only allowing 6.25% scaling increments (eg, 125% / 131.25%). Could not get 131.25% to enter into Plasma Wayland's config menu. The rendering issue is still present. The expected behavior is one window stretched across both screens. The current behavior is whichever screen has the mouse renders correctly, while the other renders both "screens" side-by-side, centered vertically. Expected: +---+---+ | 1 | 2 | +---+---+ Actual: +-+---+ | 1 2 | 2 | +-+---+ That would be with the mouse on Screen 2, it switches around when the mouse is on screen 1. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 461367] xfreerdp /multimon Does Not Work with Legacy Scaling set to "Apply Scaling Themselves"
https://bugs.kde.org/show_bug.cgi?id=461367 --- Comment #6 from Stephen Ackerman --- Did a bit more testing, and with 5.26.90, and it looks like even with scaling enabled, xfreerdp /multimon is just completely broken and unusable now. Whichever screen the mouse is on will (buggily) render halfway correctly with lots of flickering. The other screen will instead render as both images side-by-side, and not filling the screen, as if it's trying to render the texture for both windows/screens into each window separately. Results in a completely unusable experience with scaling on or off. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 461367] xfreerdp /multimon Does Not Work with Legacy Scaling set to "Apply Scaling Themselves"
https://bugs.kde.org/show_bug.cgi?id=461367 Stephen Ackerman changed: What|Removed |Added Status|RESOLVED|REPORTED Resolution|FIXED |--- --- Comment #5 from Stephen Ackerman --- With Plasma 5.26.90 (I believe that's 5.27 Beta, and should have the fix?) + Frameworks 5.102.0 + Qt 5.15.8, I get the following: xfreerdp /monitor-list * [0] 3840x2160 +3839+0 [1] 3840x2161 +0+0 Looks like the same output as 5.26.4. The second monitor is one pixel too large vertically, and the offset for the first monitor is reported as one pixel too small horizontally. -- You are receiving this mail because: You are watching all bug changes.
[Akonadi] [Bug 461312] Random crash
https://bugs.kde.org/show_bug.cgi?id=461312 --- Comment #4 from Stephen Greenham --- Created attachment 155517 --> https://bugs.kde.org/attachment.cgi?id=155517=edit New crash information added by DrKonqi akonadiserver (5.22.1 (22.12.1)) using Qt 5.15.8 Was running Nvidia eXec. Just "nvx start glmark2". -- Backtrace (Reduced): #5 0x7fb0f94b1a70 in QObject::event(QEvent*) () from /usr/lib/libQt5Core.so.5 #6 0x7fb0f948ddec in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/lib/libQt5Core.so.5 #7 0x7fb0f948e913 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /usr/lib/libQt5Core.so.5 [...] #12 0x7fb0f94d8b2c in QEventDispatcherGlib::processEvents(QFlags) () from /usr/lib/libQt5Core.so.5 #13 0x7fb0f94865ac in QEventLoop::exec(QFlags) () from /usr/lib/libQt5Core.so.5 -- You are receiving this mail because: You are watching all bug changes.
[Akonadi] [Bug 461312] Random crash
https://bugs.kde.org/show_bug.cgi?id=461312 Stephen Greenham changed: What|Removed |Added CC||stephen.green...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 463982] New: A Portrait clip Proxied as Landscape
https://bugs.kde.org/show_bug.cgi?id=463982 Bug ID: 463982 Summary: A Portrait clip Proxied as Landscape Classification: Applications Product: kdenlive Version: git-master Platform: Other OS: Other Status: REPORTED Severity: critical Priority: NOR Component: Video Display & Export Assignee: j...@kdenlive.org Reporter: stephens...@gmail.com Target Milestone: --- SUMMARY A .mp4 clip - portrait, ie 1080x1920 - was imported into Kdenlive and automatically proxied as landscape, ie 1920x1080. OBSERVED RESULT In proxy mode the clip is landscape. However when I render it it comes out as portrait. EXPECTED RESULT The proxied clip should be in the same orientation as the original clip. (And so should the Project Bin thumbnail, shouldn't it?) SOFTWARE/OS VERSIONS Microsoft Windows 10 22H2 (OS Build 19045.2364) KDE Plasma Version: N/A KDE Frameworks Version: 5.101.0 Qt Version: 5.15.7 (built against 5.15.7) ADDITIONAL INFORMATION MLT Version: 7.13.0 Kdenlive 23.03.70 (rev. f91ac500a) -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 462828] Krita 5.1.x+ : Undo history abnormally reduces performance when it's full (about 400 steps)
https://bugs.kde.org/show_bug.cgi?id=462828 --- Comment #5 from stephen --- (In reply to Halla Rempt from comment #4) > This is a bug tracker, not a user support forum, so it's not a place to go > when you need help. Alright. At least it's an encountered performance issue related to the Undo history. Since you're aware of it, I've already done my part. Yes it's indeed not a bug. It's a performance issue. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 462828] Krita 5.1.x+ : Undo history abnormally reduces performance when it's full (about 400 steps)
https://bugs.kde.org/show_bug.cgi?id=462828 --- Comment #3 from stephen --- (In reply to Halla Rempt from comment #1) > Sorry, but running out of steam isn't a bug. It's not properly recognizing > the limits of your system and working accordingly. If thisn't a bug, what is causing this issue? I mean, Krita is using 4GB or RAM only for itself out of my 12 GB RAM memory. It's not supposed to slow down, is it? I need some help about this issue. Saying that this isn't a bug doesn't help. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 462828] Krita 5.1.x+ : Undo history abnormally reduces performance when it's full (about 400 steps)
https://bugs.kde.org/show_bug.cgi?id=462828 --- Comment #2 from stephen --- (In reply to Halla Rempt from comment #1) > Sorry, but running out of steam isn't a bug. It's not properly recognizing > the limits of your system and working accordingly. If thisn't a bug, what is causing this issue? I mean, Krita is using 4GB or RAM only for itself out of my 12 GB RAM memory. It's not supposed to slow down, is it? I need some help about this issue. Saying that this isn't a bug doesn't help. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 352381] A request for zoom and radial blur option in blur filter.
https://bugs.kde.org/show_bug.cgi?id=352381 stephen changed: What|Removed |Added CC||tgdev...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 462828] New: Krita 5.1.x+ : Undo history abnormally reduces performance when it's full (about 400 steps)
https://bugs.kde.org/show_bug.cgi?id=462828 Bug ID: 462828 Summary: Krita 5.1.x+ : Undo history abnormally reduces performance when it's full (about 400 steps) Classification: Applications Product: krita Version: 5.1.3 Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: normal Priority: NOR Component: General Assignee: krita-bugs-n...@kde.org Reporter: tgdev...@gmail.com Target Milestone: --- SUMMARY This bug was experienced on a clean install of Windows 10 22H2. Windows 10 Pro - OS buildversion : 19045.2130 All drivers are up to date, and the issue is specific only to Krita among my art programs. All my other art programs are working fine, including Photoshop. STEPS TO REPRODUCE 1. Open an A4 blank canvas. 2. Make sure you have a limit of 400 undo steps set from the settings. 3. open the undo history docker and keep it in display somewhere on the UI. 4. make tiny strokes on the canvas and fill it scrupulously until the undo steps is full. 5. check the for the render delay of the brush cursor everytime you release your pen after a stroke. 6. Try to hold the Undo/redo after the history is full. OBSERVED RESULT 1. At a certain moment, the cursor starts to briefly stutters after each stroke( undo steps filled at about 300 or more ). 2. Once the undo history is full, every time you lift your pen as you perform strokes, Krita stutters for about half a second.. 3. The undo/redo operation is ten times slower when the undo history is full. And when you hold either shortcut, you notice stutters as well, as your strokes are undoing/redoing themselves EXPECTED RESULT 1. No stutter at all or notice of performance reduction while undoing/redoing. 2. No stutter at all just when you lift your pen after a stroke. 3. Krita's performance should remain as if the undo history was empty. ADDITIONAL INFORMATION Krita performance settings : 1. RAM Memory limit : 4096 MiB Swap Undo After : 512 MiB 2. Swap File Size Limit : 8GiB The bug was tested and consistent in Krita 5.1.0 beta2, Krita 5.1.0 to Krita 5.1.3 stable. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 461367] xfreerdp /multimon Does Not Work with Legacy Scaling set to "Apply Scaling Themselves"
https://bugs.kde.org/show_bug.cgi?id=461367 --- Comment #4 from Stephen Ackerman --- Testing with Debian 5.26.4, and it still reports: xfreerdp /monitor-list * [0] 3840x2161 +3839+0 [1] 3840x2161 +0+0 Is this expected to be fixed in 5.26.x, or 5.27? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 450068] Use of volatile connector IDs to map containments to screens cannot be made to work reliably and should be replaced with something else
https://bugs.kde.org/show_bug.cgi?id=450068 --- Comment #74 from Stephen Ackerman --- I've observed the "Desktop disappearing" behavior with just 2 LG monitors connected to a desktop. It seems they go into "Deep sleep" which registers as, to some extent, disconnecting (Previously had crashing issues similar to when you remove all displays whenever they went to sleep). Moving the mouse/typing on the keyboard does seem to properly wake them from sleep. (The system is not asleep, only the displays). I'm not touching the Displayport cables at all-- this is just "the displays go idle/sleep" followed a while later by "the screens turn on due to user input." This is on an RX 6700XT with a mainline kernel + Debian .config. Currently, (as of writing) my second monitor has the desktop panel for my first monitor, and my first monitor is just black (missing the desktop background). If I `plasmashell --replace` from KRunner, then things go back to normal. Over time, both monitors have lost the desktop background that I set, returning back to the default. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 461367] xfreerdp /multimon Does Not Work with Legacy Scaling set to "Apply Scaling Themselves"
https://bugs.kde.org/show_bug.cgi?id=461367 --- Comment #2 from Stephen Ackerman --- https://invent.kde.org/plasma/kwin/-/merge_requests/3215/ Seems like this PR may have some relevance to this issue, as it deals with X11 rounding issues, and being off by 1 pixel seems like it could possibly be a rounding problem. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 427861] Sometimes desktop loses its settings (wallpaper, widgets, icons settings) after re-login
https://bugs.kde.org/show_bug.cgi?id=427861 Stephen Ackerman changed: What|Removed |Added CC||stephenackerma...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 461367] xfreerdp /multimon Does Not Work with Legacy Scaling set to "Apply Scaling Themselves"
https://bugs.kde.org/show_bug.cgi?id=461367 --- Comment #1 from Stephen Ackerman --- With Plasma 5.26.3, things are much improved, but still not usable. Now, xfreerdp reports xfreerdp /monitor-list * [0] 3840x2161 +3839+0 [1] 3840x2161 +0+0 Seems that display 0 is 1 pixel off, and this causes xfreerdp to only display 1 window, instead of 2. (It appears to be trying to create a single window that spans both displays, instead of 2 windows; 1 for each separate display). -- You are receiving this mail because: You are watching all bug changes.
[kscreenlocker] [Bug 456210] Cannot unlock screen when using multiple monitors
https://bugs.kde.org/show_bug.cgi?id=456210 --- Comment #52 from Stephen Ackerman --- I consistently reproduce this on my system every time the displays have gone to sleep for more than a moment or two. The only way around it I've found so far (short of loginctl) is, when you wake the screens, type your password and hit enter twice. If you hit enter too slowly the second time, then it won't work. This is on Plasma 5.26, Frameworks 5.98, and Qt 5.15.6; as packaged by Debian Testing. If it at all matters, I've got an NVMe SSD for the root drive, and an MDADM RAID 6 of 5400RPM HDDs for /home... In case that effects timing somehow. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 450068] Use of volatile connector IDs to map containments to screens cannot be made to work reliably and should be replaced with something else
https://bugs.kde.org/show_bug.cgi?id=450068 Stephen Ackerman changed: What|Removed |Added CC||stephenackerma...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[kscreenlocker] [Bug 456210] Cannot unlock screen when using multiple monitors
https://bugs.kde.org/show_bug.cgi?id=456210 Stephen Ackerman changed: What|Removed |Added CC||stephenackerma...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 448555] [Wayland] Incorrect mouse sizing on mixed DPI displays and windows
https://bugs.kde.org/show_bug.cgi?id=448555 Stephen Ackerman changed: What|Removed |Added CC|stephenackerma...@gmail.com | -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 459161] Inconsistent cursor size
https://bugs.kde.org/show_bug.cgi?id=459161 Stephen Ackerman changed: What|Removed |Added CC||stephenackerma...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 451386] Black Screen with Movable Cursor after Screens Resume from Sleep
https://bugs.kde.org/show_bug.cgi?id=451386 --- Comment #17 from Stephen Ackerman --- With Plasma 5.26.0, Frameworks 5.98.0, and Qt 5.15.6 on Kernel 6.0.7, I have not observed this issue occurring anymore after allowing my screens to sleep multiple times over the last day or two. After entering my password, the Login screen appears to get stuck with just a "Login" button, and I have to use loginctl unlock-sessions to unlock, but the desktop is still functioning properly afterwards. Noticed Plasma bugging out a few times (eg black desktop background), but Kwin appears to be stable, so the desktop session continues (And I can 'fix' Plasma by just "plasmashell --replace") -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 461108] Taskbar Colour changes with full screen apps/desktop with white icons
https://bugs.kde.org/show_bug.cgi?id=461108 --- Comment #9 from Stephen Morris --- (In reply to Nate Graham from comment #8) > Ok, that's weird. I have a few questions so we can hopefully narrow down the > issue: > 1. What graphics hardware and drivers are you using? > 2. What Plasma theme are you using? > 3. Are you on Wayland or X11? > 3a. If you're on X11, does it change if you turn on or off compositing with > Alt+Shift+F12? > 4. Does it get better if you disable the "Floating panel" feature and use a > regular attached panel? > 5. Does it get better if yo make your panel always be opaque, rather than > adaptive or translucent? 1. I am using a 12GB Nvidia RTX 3080 with the driver built from the akmod-nvidia 520.56.06 package from the fedora rpmfusion repositories. 2. I was using the Breeze Global Theme, but I also tried the Breeze Dark Global theme, and now I have switched over to the Utterly Nord Light Global theme and all of them exhibit the issue. I am also using the Breeze Light plasma style as both the Breeze and Fedora Thirty-six style follow the colour theme. The colour issue I have sent the screenshots for also happens with the both the Nord light and Nord dark global themes. 3. I am on X11 as I've found that KDE still does not work properly with Wayland. 3a. It does change in that the taskbar background stays white, but the icons on the taskbar are no longer transparent and show their full colours. (This is using the opaque option). 4. I don't use the floating panel feature, I only use the hiding feature, but I did try the floating panel feature once and it made no difference. 5. I tried those options and none of them made any difference. I am running with the opaque option at the moment. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 461367] New: xfreerdp /multimon Does Not Work with Legacy Scaling set to "Apply Scaling Themselves"
https://bugs.kde.org/show_bug.cgi?id=461367 Bug ID: 461367 Summary: xfreerdp /multimon Does Not Work with Legacy Scaling set to "Apply Scaling Themselves" Classification: Plasma Product: kwin Version: 5.26.0 Platform: Debian testing OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: platform-x11-nested Assignee: kwin-bugs-n...@kde.org Reporter: stephenackerma...@gmail.com Target Milestone: --- SUMMARY When running xfreerdp with the /multimon option, nothing is displayed when x11 scaling is set to "Apply scaling themselves." Setting back to "Scaled by the system" results in xfreerdp properly displaying windows. STEPS TO REPRODUCE 1. Configure multiple (4K?) displays to 130% scaling 2. Set "Legacy Applications" to "Apply scaling themselves" 3. Run xfreerdp and connect to a remote system with the /multimon option OBSERVED RESULT No windows are displayed EXPECTED RESULT Both screens display a full-screen xfreerdp window SOFTWARE/OS VERSIONS Linux/KDE Plasma: Mainline Linux 6.0.6 + Debian config (available in About System) KDE Plasma Version: 5.26.0 KDE Frameworks Version: 5.98.0 Qt Version: 5.15.6 ADDITIONAL INFORMATION Monitor configuration: 2x 4K (3840x2160) LG Monitors at 130% scaling `xfreerdp /monitor-list` specifies [0] 3832x2160 +3839+0 [1] 3832x2160 +0+0 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 459373] Maximized xwayland apps leave some pixels on the right border
https://bugs.kde.org/show_bug.cgi?id=459373 Stephen Ackerman changed: What|Removed |Added CC||stephenackerma...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 460394] Let the "Application handles its own scaling" setting be per-application
https://bugs.kde.org/show_bug.cgi?id=460394 Stephen Ackerman changed: What|Removed |Added CC||stephenackerma...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 461108] Taskbar Colour changes with full screen apps/desktop with white icons
https://bugs.kde.org/show_bug.cgi?id=461108 --- Comment #7 from Stephen Morris --- Created attachment 153431 --> https://bugs.kde.org/attachment.cgi?id=153431=edit Colour issue with Taskbar This screenshot of the taskbar shows the Breeze Global theme, oxygen plasma style with firefox displaying a web site page with a white background. This screenshot also shows that it seems to only be the Oxygen Plasma Style that causes the colours to be shown optimally. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 461108] Taskbar Colour changes with full screen apps/desktop with white icons
https://bugs.kde.org/show_bug.cgi?id=461108 --- Comment #6 from Stephen Morris --- Created attachment 153430 --> https://bugs.kde.org/attachment.cgi?id=153430=edit Colour issue with Taskbar This shows the taskbar colouring with the Breeze Global theme, the oxygen plasma style with firefox showing an html5 game. This screenshot shows that it seems that only the oxygen plasma style seems to show the colours optimally. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 461108] Taskbar Colour changes with full screen apps/desktop with white icons
https://bugs.kde.org/show_bug.cgi?id=461108 --- Comment #5 from Stephen Morris --- Created attachment 153429 --> https://bugs.kde.org/attachment.cgi?id=153429=edit Col -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 461108] Taskbar Colour changes with full screen apps/desktop with white icons
https://bugs.kde.org/show_bug.cgi?id=461108 --- Comment #4 from Stephen Morris --- Created attachment 153428 --> https://bugs.kde.org/attachment.cgi?id=153428=edit Colour issue with Taskbar This shows the colour issue in the taskbar with the Breeze Global Scheme, the breeze light plasma style and firefox displaying a web site page with a white background. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 461108] Taskbar Colour changes with full screen apps/desktop with white icons
https://bugs.kde.org/show_bug.cgi?id=461108 --- Comment #3 from Stephen Morris --- Created attachment 153427 --> https://bugs.kde.org/attachment.cgi?id=153427=edit Colour issue with Taskbar This shows the colour issue with the Breeze Dark Global Scheme, the breeze dark plasma style and firefox display a web site with a white text background. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 461108] Taskbar Colour changes with full screen apps/desktop with white icons
https://bugs.kde.org/show_bug.cgi?id=461108 --- Comment #2 from Stephen Morris --- Created attachment 153426 --> https://bugs.kde.org/attachment.cgi?id=153426=edit Colour issue with Taskbar This file shows the colour issue in the taskbar with the breeze dark colour scheme, the dark breeze plasma style with the firefox application showing an html5 game. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 461257] Digikam crashes when displaying thumbnails for JP2 files
https://bugs.kde.org/show_bug.cgi?id=461257 --- Comment #3 from stephen.r.tho...@gmail.com --- Ok thanks for that! Regards, Steve T On 31/10/2022 22:06, Maik Qualmann wrote: > https://bugs.kde.org/show_bug.cgi?id=461257 > > Maik Qualmann changed: > > What|Removed |Added > > Ever confirmed|0 |1 > Status|REPORTED|CONFIRMED > > --- Comment #2 from Maik Qualmann --- > OK, problem is clear. Libjasper needs to be ported to API > 3. > jas_init_library() and jas_init_thread() must not be called twice in the same > thread (if 2 images or more are loaded at the same time). > > Maik > -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 461257] Digikam crashes when displaying thumbnails for JP2 files
https://bugs.kde.org/show_bug.cgi?id=461257 stephen.r.tho...@gmail.com changed: What|Removed |Added CC||stephen.r.tho...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 461257] New: Digikam crashes when displaying thumbnails for JP2 files
https://bugs.kde.org/show_bug.cgi?id=461257 Bug ID: 461257 Summary: Digikam crashes when displaying thumbnails for JP2 files Classification: Applications Product: digikam Version: 7.8.0 Platform: Other OS: Microsoft Windows Status: REPORTED Severity: crash Priority: NOR Component: Thumbs-Album Assignee: digikam-bugs-n...@kde.org Reporter: stephen.r.tho...@gmail.com Target Milestone: --- Created attachment 153360 --> https://bugs.kde.org/attachment.cgi?id=153360=edit Windows pop-ups displayed immediately prior to crash SUMMARY When opening a folder containing JP2 files, digikam crashes repeatably when trying to display the thumbnails. 2 Windows pop-ups are displayed just before crashing - see attached file errors.jpg. I just upgraded from V7.2.0, where this worked OK. STEPS TO REPRODUCE 1. Place a few JP2s in a folder, then open the folder. 2. 3. OBSERVED RESULT Crash EXPECTED RESULT SOFTWARE/OS VERSIONS Windows: V10 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 461108] New: Taskbar Colour changes with full screen apps/desktop with white icons
https://bugs.kde.org/show_bug.cgi?id=461108 Bug ID: 461108 Summary: Taskbar Colour changes with full screen apps/desktop with white icons Classification: Plasma Product: plasmashell Version: 5.26.2 Platform: Fedora RPMs OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Task Manager and Icons-Only Task Manager Assignee: plasma-b...@kde.org Reporter: steve.morris...@gmail.com Target Milestone: 1.0 SUMMARY *** NOTE: If you are reporting a crash, please try to attach a backtrace with debug symbols. See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** STEPS TO REPRODUCE 1. Start Plasma from sddm 2. Start different apps fullscreen, taskbar colour changes and icons go invisible. 3. OBSERVED RESULT With the desktop background the visibility is fine. If I start Thunderbird with the view pages having a white background, the taskbar colour goes white and all the displayed icons go white so that they are almost invisible. If I'm using Firefox playing a game I usually play the taskbar goes to a centre gradient colour ranging from yellow at both ends to white in the centre, with the icons going white and again almost invisible. EXPECTED RESULT Taskbar colour remains static and icons remain coloured. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: Fedora F36 (available in About System) KDE Plasma Version: 5.26.2 (also happened in earlier version of Plasma as well.) KDE Frameworks Version: 5.99.0 Qt Version: 5.15.6 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[kaffeine] [Bug 459593] New: Kaffeine set in permanent recording mode. After reboot, It is still in recording mode. Kubuntu 22.04
https://bugs.kde.org/show_bug.cgi?id=459593 Bug ID: 459593 Summary: Kaffeine set in permanent recording mode. After reboot, It is still in recording mode. Kubuntu 22.04 Classification: Applications Product: kaffeine Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: mche...@kernel.org Reporter: smstev...@gmail.com Target Milestone: --- SUMMARY *** NOTE: If you are reporting a crash, please try to attach a backtrace with debug symbols. See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** STEPS TO REPRODUCE 1. Press the instant record button. 2. 3. OBSERVED RESULT EXPECTED RESULT SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[kmymoney] [Bug 459020] noError and 2 Other Issues
https://bugs.kde.org/show_bug.cgi?id=459020 Stephen Leibowitz changed: What|Removed |Added CC||librestep...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[kmymoney] [Bug 459020] New: noError and 2 Other Issues
https://bugs.kde.org/show_bug.cgi?id=459020
Bug ID: 459020
Summary: noError and 2 Other Issues
Product: kmymoney
Version: git (master)
Platform: Other
OS: All
Status: REPORTED
Severity: minor
Priority: NOR
Component: general
Assignee: kmymoney-de...@kde.org
Reporter: librestep...@gmail.com
Target Milestone: ---
1. Remove noError. The variable noError in
MyMoneyQifWriter::writeInvestmentEntry seems unnecessary. Here is its
declaration at the top level of the function:
bool noError = true;
There are 10 “if (noError) {” lines. There is one place where noError is given
a value, aside from the declaration statement, but that value is not used:
noError = false;
return;
2. Shadow Variable. kmymoney/plugins/ofx/import/nodeparser.cpp has “list”
declared on lines 78 and 81. The second(inner) “list” is visible for lines
81-88. The first(outer) “list” is visible for lines 78-90, except for the scope
of the second “list”. I suggest that the second(inner) “list” be renamed
“list3” for clarity.
3. Argument Name Mismatch in kmymoney/plugins/ofx/import/ofxpartner.cpp.
The first argument to the definition of function OfxHttpRequest on line 284 is
“type”. I suggest it be changed to “method” to match the .h file. It should
also be changed on line 322. The argument refers to HTTP request methods, such
as "get". See https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods
The function is used with the argument "POST" on line 396 of
kmymoney/plugins/ofx/import/dialogs/konlinebankingsetupwizard.cpp
--
You are receiving this mail because:
You are watching all bug changes.
[krita] [Bug 458760] New: Annoying glitchy vector handles with select shape tool(noticeable with layer style rendering on)
https://bugs.kde.org/show_bug.cgi?id=458760
Bug ID: 458760
Summary: Annoying glitchy vector handles with select shape
tool(noticeable with layer style rendering on)
Product: krita
Version: git master (please specify the git hash!)
Platform: Microsoft Windows
OS: Microsoft Windows
Status: REPORTED
Severity: normal
Priority: NOR
Component: Layers/Vector
Assignee: krita-bugs-n...@kde.org
Reporter: tgdev...@gmail.com
Target Milestone: ---
SUMMARY
Krita version is 5.1.0 nightly (git 43f0ae3)
The vector handles behave in a weird manner as soon as you release mouse or pen
click(noticeable with stroke rendering on(they stay glued to the mouse movement
after you release your click, and stick for about 1-3 seconds.
STEPS TO REPRODUCE
1. create a new vector layer
2. insert a vector rectangle with white background fill
3. on the vector layer, activate the following layer style options(like json,
but not really json) :
{ "stroke" : {
"Structure" : {
"size" : 12,
"size_unit" : "px",
"Position" : "Outside",
"Blend_Mode" : "Normal",
"opacity" : 100,
"opacity_unit" : "%"
},
"Fill" : {
"Type" : {
"color" : {"hex" : "#000"},
"label" : black
}
}
}
}
4. using the "Select Shapes Tool", modify the shape of the rectangle a few
times by dragging the sides or vertices.
5. also using the "Select shapes tool", try moving the rectangle shape a bit,
then release click while continuing to hover the cursor rapidly.
OBSERVED RESULT
1. dragging the middle handle or vertices casually causes a glitchy gap between
cursor and rectangle once you release mouse or pen click.
2. soon after you release pen click, the rectangle or rectangle handles stick
to the cursor movement for about 2-5 seconds depending on the
circumstances(moving constantly right after click is released)
3. Krita shows "waiting for image operation to complete" if you move constantly
your cursor.
EXPECTED RESULT
1. no glitchy gap from cursor right after you release mouse or pen click after
dragging the corner of the shapes or after moving the shapes with the shapes
tool.
2. Right after you release your click drag, the rectangle should not pursue
your cursor movement and instead stop at the position you released it
SOFTWARE/OS VERSIONS
Windows 10 21H1
--
You are receiving this mail because:
You are watching all bug changes.
[kdenlive] [Bug 456955] Proxied Videos Heavily Pixelated
https://bugs.kde.org/show_bug.cgi?id=456955 Stephen Esseenyne changed: What|Removed |Added Resolution|--- |FIXED Status|REPORTED|RESOLVED --- Comment #1 from Stephen Esseenyne --- Have just tested the issue (in v22.11.70;rev. Cfb0f12cb; #1212) and it has been RESOLVED. Thanks. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 456953] Unable to Drag Audio Media from Clip Monitor to TImeline
https://bugs.kde.org/show_bug.cgi?id=456953 Stephen Esseenyne changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |FIXED --- Comment #1 from Stephen Esseenyne --- Just tested the issue (in v22.11.70;rev. Cfb0f12cb; #1212) and it is now RESOLVED. Thank you. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 452495] Target Audio Track Non-Lock
https://bugs.kde.org/show_bug.cgi?id=452495 Stephen Esseenyne changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Stephen Esseenyne --- I should have changed Status to RESOLVED in my last comment. I have done so now. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 449875] Switch Full Screen
https://bugs.kde.org/show_bug.cgi?id=449875 Stephen Esseenyne changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Stephen Esseenyne --- This has been RESOLVED ages ago. I shall change Status to RESOLVED. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 440577] Clip Monitor - Extract Frame & Extract Frame To Project - Not At Playhead
https://bugs.kde.org/show_bug.cgi?id=440577 Stephen Esseenyne changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #2 from Stephen Esseenyne --- (In reply to emohr from comment #1) > I can confirm part of this behavior. It seems a refresh after enable/disable > proxy is missing. If you hit the arrow key only 1 time after enable/disable > proxy the frame you choose is visible. Thank you for your reply. Apologies for not replying sooner and for not following your instructions simply because I have just re-tested the issue and it is resolved (in nightly build 22.11.70;rev. Cfb0f12cb; #1212). I have changed Status to RESOLVED if that is ok? Thank you again. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 455570] Krita plus 5.1.0 prealpha : complex brush outline causes performance lag
https://bugs.kde.org/show_bug.cgi?id=455570 --- Comment #33 from stephen --- Created attachment 151140 --> https://bugs.kde.org/attachment.cgi?id=151140=edit Tablet_log (In reply to Dmitry Kazakov from comment #32) > Hi, Stephen! > > Could you please reply to my questions above? I want to understand whether > this bug can be closed or not, since none of us can reproduce this issue. > > PS: > > About the hardware cursors: > > 1) Hardware cursors are usually limited to 32 pixels in size > 2) They are not dynamic (and our outlines dynamically change their shape > depending on the state of the sensors) > > If you want to use hardware cursor, just activate "small circle" cursor in > Krita settings. It will be hardware-optimized and fast. Hello Dmitry. You're definitely right. No matter what is done, it's impossible to perfectly match the system cursor speed. >From your return, I decided to make one last test and use CSP to see if it would display the brush cursor shape given that it also possesses the feature in its latest release. Turns out that even without GPU, the software is able to show it. And I noticed that there's like a two to 8 pixels distance between the brush cursor and the system cursor in Clip Studio when I hover with very high speed. In conclusion, their code is either very well optimized or they use a lower level approach to make the cursor very very fast. Still with both my integrated and dedicated GPUs disabled, with a big enough brush size, CSP starts to drop a lot of frames while painting. So it's all up to software solution then. Debate can be closed now. Thank you again for being informative. Now to answer your above questions : 1. Before the tablet log, no the "basic-5-size" brush works fine, be it with stylus or mouse. 2. With the tablet log on : I couldn't even do anything. Hovering freezes the software with the use of the stylus. Painting with stylus also freezes the software. Software won't stop getting frozen until I stop using stylus or stop putting stylus in detection range. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 455570] Krita plus 5.1.0 prealpha : complex brush outline causes performance lag
https://bugs.kde.org/show_bug.cgi?id=455570 --- Comment #31 from stephen --- (In reply to Dmitry Kazakov from comment #27) > Hi, Stephen! > > > [...] the brush outline cursor would be best if : > > A. it was as fast as the system cursor > > It is technically impossible to make the brush outline to be as fast as the > system cursor. The outline of the brush will always be slower than the > cursor. The reason is easy: the cursor is painted with a special fast-path > routine by hardware. And the brush outline is painted by software alongside > the canvas painting. We can make it "faster" to some extent, but it will > always be several frames slower than the hardware cursor. > > > its color was only shifting between black/white, and stays correctly > > visible no matter the color on the canvas. > > That's a different issue, let's not drift from the main topic :) Hello Dmitry and Krita devs. Hope you're well. It's not the main topic, but I want to encourage you by saying that it's not technically impossible to make the outline cursor as fast as the system cursor. I believe one solution is to target the function that renders the system cursor, and modify it from Krita by inserting the code logic which draws the brush outline shape in it. This code logic would work in a way that, the outline shape is rendered when the cursor hovers in Krita's viewport area, obviously yes, you probably know this one already. Well... if you can use a custom brush cursor icon, then I believe there's a way. The research required for it would probably consist of finding out, how you can use the hardware fast path routine and hack it in a certain way though. Now, I don't know what exactly are the limits of this method given the available tools in your hands. So there might be another technical constraint I'm not aware of. Just saying. Thank you for your hard work. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 457125] New: Krita 5.1.0 beta 2 git e91e5d4 : crash right after undoing a text insertion
https://bugs.kde.org/show_bug.cgi?id=457125 Bug ID: 457125 Summary: Krita 5.1.0 beta 2 git e91e5d4 : crash right after undoing a text insertion Product: krita Version: nightly build (please specify the git hash!) Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: crash Priority: NOR Component: Tool/Text Assignee: krita-bugs-n...@kde.org Reporter: tgdev...@gmail.com Target Milestone: --- SUMMARY Krita crashes right after undoing a text insertion STEPS TO REPRODUCE 1. in a newly opened document, insert a new text 2. undo your text insertion OBSERVED RESULT Krita crashes right after undoing the text insertion EXPECTED RESULT *No crash *The text should disappear from the canvas once undone SOFTWARE/OS VERSIONS Windows 10 21H1 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 457123] New: Krita 5.1.0 beta2 : crash after reading a recently opened PSD file
https://bugs.kde.org/show_bug.cgi?id=457123 Bug ID: 457123 Summary: Krita 5.1.0 beta2 : crash after reading a recently opened PSD file Product: krita Version: nightly build (please specify the git hash!) Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: crash Priority: NOR Component: General Assignee: krita-bugs-n...@kde.org Reporter: tgdev...@gmail.com Target Milestone: --- ADDITIONAL INFORMATION Krita version : 5.1.0 beta 2 git e91e5d4) SUMMARY For some reason Krita crashes a few seconds after it tries to read a psd file to show its thumbnail. I say psd because, I tried to remove the path of the psd file in kritarc file and the issue ceased. For investigation here's a link to the psd file Krita was trying to read. https://www.mediafire.com/file/8u4ghi4ecst70ze/adfasdf2-1.zip/file STEPS TO REPRODUCE 1. Open the psd file with Krita for the 1st time 2. Close the psd file and close Krita completely. 3. Start Krita again OBSERVED RESULT Krita shows the main GUI then crashes a few seconds after EXPECTED RESULT No crash at all after reading the content of a psd file SOFTWARE/OS VERSIONS Windows 10 21H1 -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 456955] New: Proxied Videos Heavily Pixelated
https://bugs.kde.org/show_bug.cgi?id=456955 Bug ID: 456955 Summary: Proxied Videos Heavily Pixelated Product: kdenlive Version: git-master Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: normal Priority: NOR Component: Video Display & Export Assignee: j...@kdenlive.org Reporter: stephens...@gmail.com Target Milestone: --- SUMMARY Once the .mp4 files have imported and proxied, the resolution of an .mp4 clip in both Clip and Project Monitors is heavily pixelated in Proxy Clip mode. SOFTWARE/OS VERSIONS Windows: Windows 10 Version 2009 (x86_64) KDE Frameworks Version: 5.96.0 Qt Version: 5.15.5 (built against 5.15.5) ADDITIONAL INFORMATION Kdenlive: 22.11.70 (rev. d7ff14574) -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 456953] New: Unable to Drag Audio Media from Clip Monitor to TImeline
https://bugs.kde.org/show_bug.cgi?id=456953 Bug ID: 456953 Summary: Unable to Drag Audio Media from Clip Monitor to TImeline Product: kdenlive Version: git-master Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: normal Priority: NOR Component: User Interface Assignee: j...@kdenlive.org Reporter: stephens...@gmail.com Target Milestone: --- SUMMARY Once an .mp3 file was imported, dragging it on to the timeline from Clip Monitor is impossible. Get around: drag the media FROM Project Bin. SOFTWARE/OS VERSIONS Kdenlive: 22.11.70 (rev. d7ff14574; #1190) Windows: Windows 10 Version 2009 (x86_64) KDE Frameworks Version: 5.96.0 Qt Version: 5.15.5 (built against 5.15.5) -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 456813] New: "Colour corrections "is spelt color correction in the British English version of Fedora KDE
https://bugs.kde.org/show_bug.cgi?id=456813 Bug ID: 456813 Summary: "Colour corrections "is spelt color correction in the British English version of Fedora KDE Product: systemsettings Version: 5.25.3 Platform: Fedora RPMs OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: stephen.james.he...@gmail.com Target Milestone: --- SUMMARY *** NOTE: If you are reporting a crash, please try to attach a backtrace with debug symbols. See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** STEPS TO REPRODUCE 1. install KDE Fedora with British English selected 2. Click Quick Settings 3. "Colour Corrections" is displayed as "Color Corrections" Other uses of Colour within the distro are the correct British Spelling. OBSERVED RESULT "Colour Corrections" is spelt Color Corrections in the British English version of FedoraKDE EXPECTED RESULT "Color Corrections" should be changed to "Colour Corrections" SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 456619] New: Greyed-Out Edit Clip on Duplicated TItle Clip
https://bugs.kde.org/show_bug.cgi?id=456619 Bug ID: 456619 Summary: Greyed-Out Edit Clip on Duplicated TItle Clip Product: kdenlive Version: 22.04.3 Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: minor Priority: NOR Component: User Interface Assignee: j...@kdenlive.org Reporter: stephens...@gmail.com Target Milestone: --- SUMMARY Greyed-out Edit on Duplicated Title Clip. STEPS TO REPRODUCE 1. Right click on a title clip 2. Duplicate Clip 3. Right clip on duplicated clip OBSERVED RESULT Greyed-out Edit Clip EXPECTED RESULT Edit Clip enabled. SOFTWARE/OS VERSIONS Windows 10 Version 2009 (x86_64) KDE Frameworks Version: 5.95.0 Qt Version: 5.15.5 (build against5.15.5) ADDITIONAL INFORMATION MLT 7.9.0 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 455570] Krita plus 5.1.0 prealpha : complex brush outline causes intolerable performance lag
https://bugs.kde.org/show_bug.cgi?id=455570 stephen changed: What|Removed |Added Resolution|WAITINGFORINFO |--- Status|NEEDSINFO |REPORTED --- Comment #29 from stephen --- (In reply to Dmitry Kazakov from comment #27) > Hi, Stephen! > > > [...] the brush outline cursor would be best if : > > A. it was as fast as the system cursor > > It is technically impossible to make the brush outline to be as fast as the > system cursor. The outline of the brush will always be slower than the > cursor. The reason is easy: the cursor is painted with a special fast-path > routine by hardware. And the brush outline is painted by software alongside > the canvas painting. We can make it "faster" to some extent, but it will > always be several frames slower than the hardware cursor. > > > its color was only shifting between black/white, and stays correctly > > visible no matter the color on the canvas. > > That's a different issue, let's not drift from the main topic :) > > For Stephen and Protoniv: > > I'm afraid I cannot reproduce the regression you report. I tried the two > brushes described by Protoniv and both of them work fine with with mouse, > stylus+winink, stylus+wintab on Windows. > > The video on the forum looks as if Krita has the "Thread limit" set to '1' > in the performance preferences. Could you try resetting Krita settings and > recheck? > > https://docs.krita.org/en/KritaFAQ.html#resetting-krita-configuration Hello Dmitry. So, I've reset my settings as suggested, but using the stylus, it's the same. On my side, the cursor gets stuck while painting with stylus+Wintab and stylus+WinInk. -- You are receiving this mail because: You are watching all bug changes.
[kmymoney] [Bug 456520] OFX import broken upstream
https://bugs.kde.org/show_bug.cgi?id=456520 Stephen Leibowitz changed: What|Removed |Added CC||librestep...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 456484] New: Krita 5.1.0 beta 2 : crash right after selecting some brushes
https://bugs.kde.org/show_bug.cgi?id=456484 Bug ID: 456484 Summary: Krita 5.1.0 beta 2 : crash right after selecting some brushes Product: krita Version: nightly build (please specify the git hash!) Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: crash Priority: NOR Component: Brush engines Assignee: krita-bugs-n...@kde.org Reporter: tgdev...@gmail.com Target Milestone: --- SUMMARY Krita git version is c111c9f. STEPS TO REPRODUCE 1. Try to select some custom brushes via your brush tags or brush palette. OBSERVED RESULT Krita crashes rapidly ! EXPECTED RESULT No crash at all. SOFTWARE/OS VERSIONS Windows 10 21H1 Additional information : Information for the crash : Error occurred on Friday, July 8, 2022 at 02:40:26. krita.exe caused an Access Violation at location 7FFC4FB1513C in module libkritalibpaintop.dll Reading from location . AddrPC Params 7FFC4FB1513C 02555D8C2510 libkritalibpaintop.dll!KisBrushBasedPaintOpSettings::paintOpSize+0x1c 7FFC509D9661 00D0039FB098 02555D8C25F0 177E libkritaui.dll!KisSizeResourceConverter::fromSource+0x51 7FFC57D8C3CB 02550416DA80 00D0039FB2D8 025556D4FE48 libkritaflake.dll!KoDerivedResourceConverter::readFromSource+0x1b 7FFC57D887E5 02550416DA80 00D0039FB158 025557C08D30 libkritaflake.dll!KoResourceManager::notifyDerivedResourcesChangeAttempted+0xc5 7FFC57D8819E 025560969E00 025506A3DA00 025506A3DCA0 libkritaflake.dll!KoResourceManager::setResource+0x2e 7FFC509D3735 02556E5F8E40 7FFC5F2AD896 00D0039FB350 libkritaui.dll!KisCanvasResourceProvider::setPaintOpPreset+0x45 7FFC50A99EC7 00D0039FB498 7FFC65C5E1C1 02556E711300 libkritaui.dll!KisPaintopBox::setCurrentPaintop+0x537 7FFC50A9B071 021E libkritaui.dll!KisPaintopBox::resourceSelected+0x4c1 7FFC50AD5B8C 02556CE62A40 02555D8BA230 7FFC506C9968 libkritaui.dll!KisFavoriteResourceManager::slotChangeActivePaintop+0xbc 7FFC4FF80868 0002039FB6A8 02550416D1D8 02550416D9E0 Qt5Core.dll!QMetaObject::activate+0x828 7FFC5089B550 00D0039FBC60 7FFC4FFA2F08 02556C516DB0 libkritaui.dll!KisPopupPalette::sigChangeActivePaintop+0x30 7FFC50AB0BE7 0001 02556C516DB0 0002 libkritaui.dll!KisPopupPalette::mouseReleaseEvent+0x77 7FFC503742D2 00A5006A 0003 00D0039FB8F0 Qt5Widgets.dll!QWidget::event+0x5f2 7FFC5033C716 04DF 4058 4058 Qt5Widgets.dll!QApplicationPrivate::notify_helper+0x106 7FFC5033F3ED Qt5Widgets.dll!QApplication::notify+0x1cad 7FFC50D59018 011001C1 3FF0 libkritaui.dll!KisApplication::notify+0xa8 7FFC4FF53323 3FF0 Qt5Core.dll!QCoreApplication::notifyInternal2+0x93 7FFC5033D001 00D0039FBF50 7FFC55363E55 012701C1 Qt5Widgets.dll!QApplicationPrivate::sendMouseEvent+0x381 7FFC5039239E 02550416D290 7FFC4FF5A0A9 40727000 Qt5Widgets.dll!QWidgetWindow::handleMouseEvent+0x88e 7FFC50390EF8 00D0039FC158 02554F39C410 0003 Qt5Widgets.dll!QWidgetWindow::event+0xc8 7FFC5033C716 012701C1 Qt5Widgets.dll!QApplicationPrivate::notify_helper+0x106 7FFC5033D92E 3FF0 00D0039FC158 Qt5Widgets.dll!QApplication::notify+0x1ee 7FFC50D59018 0255567EF2A0 7FFC4D80C333 libkritaui.dll!KisApplication::notify+0xa8 7FFC4FF53323 02E4043C 7FFC89669877 Qt5Core.dll!QCoreApplication::notifyInternal2+0x93 7FFC4D7CFDF1 0255568BB6B0 0401 Qt5Gui.dll!QGuiApplicationPrivate::processMouseEvent+0xbc1 7FFC4D7B8E5B 0029258E 0003 Qt5Gui.dll!QWindowSystemInterface::sendWindowSystemEvents+0xdb 7FFC4FFA5093 0001 0001 Qt5Core.dll!qt_internal_proc+0x253 7FFC8932E858 3DFF 7FFC4FFA4E40 0029258E USER32.dll!UserCallWinProcCheckWow+0x2f8 7FFC8932E299 7FFC4FFA4E40 0001 USER32.dll!DispatchMessageWorker+0x249 7FFC4FFA659B 02554F39C410 025560FB0F60 00D0039FF8B8 Qt5Core.dll!QEventDispatcherWin32::processEvents+0x7cb 7FFC553C3795 00D0039FF8B8 00D0039FF960 qwindows.dll!QWindowsGuiEventDispatcher::processEvents+0x15 7FFC4FF50175 02550002 02550002 02554FD34620 Qt5Core.dll!QEventLoop::exec+0x1e5 7FFC4FF5399D
[krita] [Bug 455570] Krita plus 5.1.0 prealpha : complex brush outline causes intolerable performance lag
https://bugs.kde.org/show_bug.cgi?id=455570
stephen changed:
What|Removed |Added
Resolution|WAITINGFORINFO |---
Status|NEEDSINFO |REPORTED
Ever confirmed|1 |0
--- Comment #24 from stephen ---
(In reply to Dmitry Kazakov from comment #19)
> Hi, @stephen!
>
> Could you please clarify, what brush do you mean by "fuzzy brush"? "moo
> bubble" or something else?
Yes Dmitry. It was the "moo bubble" brush.
(In reply to Dmitry Kazakov from comment #21)
> And one more question: does the framedrop happens **only** when **all**
> these conditions are met?
>
> 1) Some brush sensor (e.g. rotation) is set to "Fuzzy Dab", and
> 2) The framedrop happens only when the brush stroke is started and the
> ceases when the stylus is lifted from the tablet surface and starts hovering
No, there are other conditions where the framedrop happens.
One of these conditions is choosing the "moo bubble" brush and just hovering
the cursor without doing anything else.
1) When there's absolutely no sensor active, the framedrop happens(hovering
gives framedrops during the test)
2) The framedrop happens at all time as you hover the cursor.{
2.a : the framedrop is huge while painting with mouse;
2.b : the whole gui freezes when you start a stroke using your pen on Windows;
2.c : The GUI freezing won't stop if you don't lift your pen from the tablet's
surface;
2.d : The freezing goes away about 3s after you lift your pen from the tablet's
surface. }
Since there are more conditions, the answer is no.
Matter of fact, compare the following :
I. hovering the cursor of a basic round brush.
II. hovering the cursor of the "moo bubble" brush.
You'll notice that hovering in condition "I" is faster than hovering in
condition "II".
Which means, that already with just hovering, there's a framedrop on the canvas
if you pick the "moo bubble" brush.
Years ago, I reported to "halla" that the brush outline cursor would be best if
:
A. it was as fast as the system cursor, but he was apparently "too busy".
B. its color was only shifting between black/white, and stays correctly visible
no matter the color on the canvas.
But he/she had no clue about the best way to take care of the issue.
--
You are receiving this mail because:
You are watching all bug changes.
[krita] [Bug 455570] Krita plus 5.1.0 prealpha : complex brush outline causes intolerable performance lag
https://bugs.kde.org/show_bug.cgi?id=455570 --- Comment #18 from stephen --- (In reply to Dmitry Kazakov from comment #15) > Hi, Stephen! > > I have fixed the problem that was triggered by the "moo bubble" brush. That > stutter should go now. Though I haven't even checked the part of the bug > that is related to 1700px brushes, because Krita officially doesn't support > brushes bigger that 1000px. Usage of such brushes is "at your own risk" :) To make sure my test was well performed, I double checked again. And this is my experience on Windows : 1) Hovering doesn't stutter anymore however selecting this fuzzy brush leads to considerable frame drops even just with hovering. 2) When I use my mouse to paint, the cursor doesn't freeze on the canvas, but the frame drop is even more noticeable as it increases while painting; 3) When I use my pen to paint, the cursor will freeze, the stroke will not render in real time even if it's slow, and I must wait about 3 s after I release my pen before I can see the cursor moving again and the stroke rendered on the canvas. 4) I confirm that using shift+drag is smooth, but the framerate drop of the GUI seems abnormal. So yeah. The gui's frame rate drops severly as if what is happening on the canvas is somewhat linked to GUI. Sound like a rendering issue overall. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 455570] Krita plus 5.1.0 prealpha : complex brush outline causes intolerable performance lag
https://bugs.kde.org/show_bug.cgi?id=455570 --- Comment #17 from stephen --- (In reply to Dmitry Kazakov from comment #15) > Hi, Stephen! > > I have fixed the problem that was triggered by the "moo bubble" brush. That > stutter should go now. Though I haven't even checked the part of the bug > that is related to 1700px brushes, because Krita officially doesn't support > brushes bigger that 1000px. Usage of such brushes is "at your own risk" :) Alright. Greetings everyone. So after a new test, using krita 5.1.0 beta2 git ef3b190, I can't say that there's a big difference. The stutters remains, even just with hovering. When I paint, and continuously paint for 10s, the cursor freezes on the canvas for those 10s and the rendering will update many seconds later after I lift my pen. It this an expected behavior ? For the gauze brush, the performance improvement is noticeable. But with this fuzzy brush, it's not there yet... -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 455570] Krita plus 5.1.0 prealpha : complex brush outline causes intolerable performance lag
https://bugs.kde.org/show_bug.cgi?id=455570 --- Comment #16 from stephen --- (In reply to Dmitry Kazakov from comment #15) > Hi, Stephen! > > I have fixed the problem that was triggered by the "moo bubble" brush. That > stutter should go now. Though I haven't even checked the part of the bug > that is related to 1700px brushes, because Krita officially doesn't support > brushes bigger that 1000px. Usage of such brushes is "at your own risk" :) Thank you a lot Dmitry ! God blesses you! Also good to know that Krita officially doesn't support brushes bigger than 1000 px. I wasn't aware of that. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 455570] Krita plus 5.1.0 prealpha : complex brush outline causes intolerable performance lag
https://bugs.kde.org/show_bug.cgi?id=455570 --- Comment #12 from stephen --- Created attachment 150306 --> https://bugs.kde.org/attachment.cgi?id=150306=edit stutter with the moo bubble (In reply to wolthera from comment #11) > *** Bug 456172 has been marked as a duplicate of this bug. *** I should've appended this file here along with the 1st brush causing the stutters. I imagined that the 1st fix would solve everything, but after some testing, the issue remains again on my side with this new brush. If you don't mind and would like to make Krita's brush engine more performant, here it is. (see moo-animated-brush.bundle for more investigation) -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 456172] Krita 5.1.0 beta 2 : complex outline causes lots of stutters on the canvas, but not the scratchpad
https://bugs.kde.org/show_bug.cgi?id=456172 --- Comment #2 from stephen --- It is not a duplicate of the resolved bug, but another one. Shouldn't be marked as "duplicate". On Thu, Jun 30, 2022 at 6:46 PM wolthera wrote: > https://bugs.kde.org/show_bug.cgi?id=456172 > > wolthera changed: > >What|Removed |Added > > > CC||griffinval...@gmail.com > Resolution|--- |DUPLICATE > Status|REPORTED|RESOLVED > > --- Comment #1 from wolthera --- > > > *** This bug has been marked as a duplicate of bug 455570 *** > > -- > You are receiving this mail because: > You reported the bug. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 456172] New: Krita 5.1.0 beta 2 : complex outline causes lots of stutters on the canvas, but not the scratchpad
https://bugs.kde.org/show_bug.cgi?id=456172 Bug ID: 456172 Summary: Krita 5.1.0 beta 2 : complex outline causes lots of stutters on the canvas, but not the scratchpad Product: krita Version: nightly build (please specify the git hash!) Platform: Other OS: Other Status: REPORTED Severity: normal Priority: NOR Component: Brush Engine/Shape Assignee: krita-bugs-n...@kde.org Reporter: tgdev...@gmail.com Target Milestone: --- Created attachment 150293 --> https://bugs.kde.org/attachment.cgi?id=150293=edit stutter brush tip SUMMARY This brush is also complex but for some reason, even at 80-100 px, it causes stutters. Please investigate. STEPS TO REPRODUCE 1. Import the brush from the bundle 2. Paint and see if you get stutters on the canvas 3. Compare with painting in the scratchpad to see the difference OBSERVED RESULT Lots of stutters when preview outline is active EXPECTED RESULT No stutter at all with the cursor shape. Performance should be the same as on the scratchpad. SOFTWARE/OS VERSIONS Windows: 10 21H1 krita git version : 5.1.0 beta 2 3ecf7c7 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 455570] Krita plus 5.1.0 prealpha : complex brush outline causes intolerable performance lag
https://bugs.kde.org/show_bug.cgi?id=455570 --- Comment #10 from stephen --- (In reply to Halla Rempt from comment #9) > If you're using very big and very complex brushes, well, your computer is > going to have to do a lot of work, and it needs time to do that work: go big > and complex enough and rendering a brush outline will always become > noticeable. You probably should use one of the other cursor options if you're > using brushes like that. > > Also, it's not up to the bug reporter to re-open reports developers closed. > Please do not do that again. Sorry. I wasn't sure whether I should submit it as "reported" or leave it as it was. Though I don't think the cursor alone should cause any lag at all no matter the complexity of the brush. It's rather the dab/stroke that should be slow if the brush is too complex. The lag I observed with the "gauze brush" tip is exactly the same with the "moo bubble" tip. Even with 100 pixels, it stutters a lot. I'll be making another bug report with the brush causing the stutter. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 455570] Krita plus 5.1.0 prealpha : complex brush outline causes intolerable performance lag
https://bugs.kde.org/show_bug.cgi?id=455570 --- Comment #8 from stephen --- If possible, the cursor shouldn't stutter at all. The rendering on the canvas can be slow, but not the cursor. I tried to paint in the scratchpad and believe that the performance in the scratchpad is the expected behavior. Because of the stutter, performance in the scratchpad is much faster than on the canvas. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 455570] Krita plus 5.1.0 prealpha : complex brush outline causes intolerable performance lag
https://bugs.kde.org/show_bug.cgi?id=455570 stephen changed: What|Removed |Added Status|RESOLVED|REPORTED Resolution|FIXED |--- --- Comment #7 from stephen --- (In reply to Dmitry Kazakov from comment #5) > Git commit bef36adac9ed3934c68431da838045041fa4a31d by Dmitry Kazakov. > Committed on 22/06/2022 at 12:48. > Pushed by dkazakov into branch 'krita/5.1'. > > Fix a slowdown when Shift+gestrure-resize huge and complex brushes > > This patch does two things: > > 1) Now the brush outline is generated **not** from the real brush tip, >generated by generateMaskAndApplyMaskOrCreateDab(), but from the >original brushTipImage(). It should generate the same outline, unless >any of our brush modes support changing opacity of the brush tip >(afaict, none of them support that). > > 2) The outline and pyramid caches are now shared between the source and >cloned brush tips. That is, updating a cache inside a cloned brush will >also update the cache inside the source brush (in the registry). This >decision is a bit scary, but solves really a lot of performance troubles. >The link between the two brush objects will be reset only when one of >the objects calls `cache.reset()`. > > M +19 -20 libs/brush/kis_brush.cpp > M +139 -16 libs/global/KisLazySharedCacheStorage.h > > https://invent.kde.org/graphics/krita/commit/ > bef36adac9ed3934c68431da838045041fa4a31d Greetings. Also I want to say that the issue is not really fixed. Because the problem remains when the brush size is very complex or around 1700 px. But there's this brush from the moo ink bundle, called the "moo bubble". I swear that even right now, only at 150 px, it stutters a freaking lot. Because of this, I'll say that there's been an improvement but it's not really fixed completely yet. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 456080] New: Krita 5.1.0 beta 2 : outline brush shows square instead of brush tip shape.
https://bugs.kde.org/show_bug.cgi?id=456080 Bug ID: 456080 Summary: Krita 5.1.0 beta 2 : outline brush shows square instead of brush tip shape. Product: krita Version: nightly build (please specify the git hash!) Platform: Other OS: Other Status: REPORTED Severity: normal Priority: NOR Component: Brush Engine/Shape Assignee: krita-bugs-n...@kde.org Reporter: tgdev...@gmail.com Target Milestone: --- Created attachment 150226 --> https://bugs.kde.org/attachment.cgi?id=150226=edit outline preview square SUMMARY Krita version is 5.1.0 beta2(git 5f298d4) After the fix of huge performance drop with complex brush tips, the outline preview, started to show either literal squares or rectangle for some custom brush tips. This is an example. And I don't know why this is happening. Given that one of the most complex brush tips I have stills show up correctly, I don't think the brush tip's complexity is the issue. But anyway. Reporting this for eventual investigation. STEPS TO REPRODUCE 1. Select Krita's chalk brush tip to customize one of your pixel engine brushes 2. stay in focus on your canvas and move the cursor around OBSERVED RESULT. The outline of the cursor shows a square rather than the brush shape. EXPECTED RESULT We should observe the shape of the brush tip instead of the square. SOFTWARE/OS VERSIONS Windows: 10 21H1 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 455570] Krita plus 5.1.0 prealpha : complex brush outline causes intolerable performance lag
https://bugs.kde.org/show_bug.cgi?id=455570 --- Comment #6 from stephen --- (In reply to Dmitry Kazakov from comment #5) > Git commit bef36adac9ed3934c68431da838045041fa4a31d by Dmitry Kazakov. > Committed on 22/06/2022 at 12:48. > Pushed by dkazakov into branch 'krita/5.1'. > > Fix a slowdown when Shift+gestrure-resize huge and complex brushes > > This patch does two things: > > 1) Now the brush outline is generated **not** from the real brush tip, >generated by generateMaskAndApplyMaskOrCreateDab(), but from the >original brushTipImage(). It should generate the same outline, unless >any of our brush modes support changing opacity of the brush tip >(afaict, none of them support that). > > 2) The outline and pyramid caches are now shared between the source and >cloned brush tips. That is, updating a cache inside a cloned brush will >also update the cache inside the source brush (in the registry). This >decision is a bit scary, but solves really a lot of performance troubles. >The link between the two brush objects will be reset only when one of >the objects calls `cache.reset()`. > > M +19 -20 libs/brush/kis_brush.cpp > M +139 -16 libs/global/KisLazySharedCacheStorage.h > > https://invent.kde.org/graphics/krita/commit/ > bef36adac9ed3934c68431da838045041fa4a31d Hello Dmitry. Thank you for caring about the issue. There's another problem again now that the issue is fixed. I'll make another bug report for it. The problem is that some brush tips, especially the complex ones, are showing squares or rectangles instead of the actual brush outline shape. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 451386] Black Screen with Movable Cursor after Screens Resume from Sleep
https://bugs.kde.org/show_bug.cgi?id=451386 --- Comment #14 from Stephen Ackerman --- Some success; coming back to the machine, kscreenlocker had crashed > [99933.409250] kscreenlocker_g[154301]: segfault at 20001 ip > 00020001 sp 7ffcaa20cca8 error 14 in > kscreenlocker_greet[5588d5765000+b000] > [99933.409265] Code: Unable to access opcode bytes at RIP 0x1ffd7. But after flipping to a VT, executing loginctl unlock-session, my Plasma session was still there! Seems this issue might be tied to Plasma on Qt 5.15.2 and 5.15.3 or 5.15.4 might be the fix? -- You are receiving this mail because: You are watching all bug changes.
