https://bugs.kde.org/show_bug.cgi?id=499913
--- Comment #26 from Justin Wayland <justintwayl...@gmail.com> --- (In reply to antonio from comment #25) > (In reply to Hidden Bug from comment #24) > > (In reply to antonio from comment #1) > > > I found, the problem is in: > > > > > > systemsettings -> windows management -> window behavior -> movement > > > > > > when both entries: > > > - screen edge snap zone > > > - windows snap zone > > > > > > are set to 0 > > > > > > if I insert 1px in at least one of these entries it solves. > > > > > > it is necessary to prevent this possibility to not compromise the > > > stability > > > of the desktop (or solve the problem for which kwin_wayland goes to 100% > > > of > > > the cpu, else it blocks everything). > > I set the following to 35px and does not crash kwin: > > - Screen edge snap zone > > - Window snap zone > > - Center snap zone > > > > I've not tested to deeply on other zone sizes, but that size works for me > > for the time being. > > I tried the values indicated and by doing so it does not block, probably > with these values kwin is able to complete the routine. It could also > depend on the height of the window border and therefore on the theme in use > (i use default: breeze). > However, even if this seems to work, I would not rely on luck, considering > that the desktop is a vital element of the system. > Therefore, even when the problem is solved, in my opinion there should > always be an emergency clause that avoids the infinite loop, to cover those > errors that do not come out immediately and that have not yet been > considered. > I hope these analysis will help to fix this bug. I think we should use kwin's logging mechanism to log when the while loop exits via the above proposed exit clause. -- You are receiving this mail because: You are watching all bug changes.
