> On Nov. 29, 2015, 11:25 p.m., David Edmundson wrote: > > >MoseMove is too expensive event to be redirect, it can cause problems on > > >slow CPU's. > > > > I don't see how. > > It's no different to when the mouse is actually over the containment. > > > > The case for when you're in the 4px margin at the edge of the panel seems > > like it must be tiny. > > Anthony Fieroni wrote: > First of all, you don't understaind the problem at all. Every postEvent > is expensive, not for allocating memory, case event is append to queque. Here > problem is simple - QEvent::Leave is append to queque *before* MouseMove, > this behavior can be easy preproduce at slower CPU's like mine. To make > redirect on evey mousemove is not only stupid, it's more expencive than any > other event. > > Anthony Fieroni wrote: > Even more, on lower CPU event queque may increase it size case busy > processor, this can cause slowdowns, flickers, example: widgets in system > tray when has expand view by click on item, task window *must not* seen in > taskmanager, but some time on lower CPU, when it be busy, postEvent is > appended *after* event that window must be ignore for taskmanager, this cause > visual flicker in taskmanager. http://tinypic.com/player.php?v=6ft8gn%3E&s=9 > You can see blue flicker in taskmanager, cause postEvent is expensive when > CPU is busy, this cannot see on better CPU. > > David Edmundson wrote: > This breaks highlighting the correct item when the mouse is at the bottom > of the screen and you slide along next to (but not on) the task manager. > > Anthony Fieroni wrote: > I can add exclusive check for bottom edge. But for me it's better break > this except everything else :)
That was one example, clearly it applies to every edge the panel might be on. And everyone things the bug that annoys them is worse than the bug that affects others. :P What's frustrating is I think we're quite close to solving things properly, you've clearly identified where the real problem is. We should be able to do this without any regressions. The whole problem with the current code in PanelView is the containment is handling it's own mouseEnter, mouseLeave, but the panelview is proxying in some mouse events, and then those two get out of sync. It's not about the speed of the postEvent, it's always going to happen in that order until someone fixes that underlying problem. Disabling mouseMoves doesn't fix that as we still effectively have the same problem with mouse presses and drags, just the symptoms might not be as visible. - David ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126175/#review88931 ----------------------------------------------------------- On Nov. 28, 2015, 3:30 a.m., Anthony Fieroni wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/126175/ > ----------------------------------------------------------- > > (Updated Nov. 28, 2015, 3:30 a.m.) > > > Review request for Plasma, David Edmundson and Marco Martin. > > > Bugs: 354651 > https://bugs.kde.org/show_bug.cgi?id=354651 > > > Repository: plasma-workspace > > > Description > ------- > > You can see videos in bug repot > > > Diffs > ----- > > shell/panelview.cpp 3407501 > > Diff: https://git.reviewboard.kde.org/r/126175/diff/ > > > Testing > ------- > > I test patch and all works as expected. > http://doc.qt.io/qt-5/qevent.html > QEvent::Leave 11 Mouse leaves widget's boundaries. > > > Thanks, > > Anthony Fieroni > >
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
