Bug 260727 - Startup icon at mouse pointer leaves garbage when moving the mouse
Summary: Startup icon at mouse pointer leaves garbage when moving the mouse
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Unclassified
Component: effects-various (show other bugs)
Version: git master
Platform: Compiled Sources Linux
: NOR minor (vote)
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
: 309541 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-12-19 19:41 UTC by Christoph Feck
Modified: 2013-07-25 13:34 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 4.11


Attachments
Clip correctly (934 bytes, patch)
2010-12-22 17:53 UTC, Martin Flöser
Details
repaint rect covered by the move (708 bytes, patch)
2012-06-25 17:54 UTC, Thomas Lübking
Details
Better fix (2.40 KB, patch)
2012-06-26 23:46 UTC, Thomas Lübking
Details
qdbus org.kde.kwin /KWin supportInformation (3.17 KB, text/plain)
2012-10-05 21:44 UTC, Christoph Feck
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Christoph Feck 2010-12-19 19:41:46 UTC
I use the (non-jumping) startup mouse icon. When starting an application, I see remaining parts of that icon when moving the mouse during the application startup. Those parts are deleted later, probably when KWin issues a full redraw when the application window opens. I have compositing enabled.

This is a regression caused by the new startup icon code in KWin.
Comment 1 Martin Flöser 2010-12-19 22:08:07 UTC
> This is a regression caused by the new startup icon code in KWin.
Strange, I tested it a lot. Will switch to the passive icon for testing.
Comment 2 Martin Flöser 2010-12-19 22:16:57 UTC
I think I understand it, when the mouse changes I only trigger an update for 
the new region, but not for the old one and in postPaintScreen I only trigger 
updates for bouncing and blinking cursors.

I'll change the code to cache the geometry and update the screen with the last 
used geometry whenever the mouse changes.
Comment 3 Martin Flöser 2010-12-20 18:11:38 UTC
SVN commit 1208097 by graesslin:

Repaint correct geometry in StartupFeedback

Caches the current geometry of the icon and triggers repaints
only for this geometry instead of an incorrect one.
BUG: 260727

 M  +5 -5      startupfeedback.cpp  
 M  +1 -0      startupfeedback.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1208097
Comment 4 Christoph Feck 2010-12-20 23:37:08 UTC
You probably have to include both the old as well as the new region, because now the icon gets cropped while moving the mouse.
Comment 5 Martin Flöser 2010-12-21 06:52:17 UTC
*sigh* it shouldn't as I include the area in the pre paint pass. I think we are hit again by a paint clipper problem
Comment 6 Thomas Lübking 2010-12-21 16:33:04 UTC
just don't clip.
you need to addRepaint(m_lastGeometry); to clear the screen but other than this
"texture->render(infiniteRegion(), m_currentGeometry ); m_lastGeometry = m_currentGeometry;" should do.
Comment 7 Martin Flöser 2010-12-21 19:43:21 UTC
> you need to addRepaint(m_lastGeometry); to clear the screen but other than
> this "texture->render(infiniteRegion(), m_currentGeometry );
> m_lastGeometry = m_currentGeometry;" should do.
That doesn't work, it's still clipped :-( I think PaintClipper ignores an 
infiniteRegion
Comment 8 Martin Flöser 2010-12-22 17:53:52 UTC
Created attachment 55163 [details]
Clip correctly

Please test if the patch works correctly. I just tried and could not notice any problem (thanks to unresponsive kontact) with bouncing and passive cursor.

And for 4.7 I'll add a don't clip option to VBO...
Comment 9 Christoph Feck 2010-12-23 00:55:38 UTC
Patch works, merci.
Comment 10 Martin Flöser 2010-12-23 17:27:03 UTC
SVN commit 1208899 by graesslin:

Trigger also new geometry for repaint on cursor change
BUG: 260727
FIXED-IN: 4.6.0



 M  +2 -1      startupfeedback.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1208899
Comment 11 Martin Flöser 2010-12-23 17:29:27 UTC
SVN commit 1208901 by graesslin:

Forward port rev 1208899
Trigger also new geometry for repaint on cursor change
CCBUG: 260727

 M  +2 -1      startupfeedback.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1208901
Comment 12 Christoph Feck 2011-10-15 15:02:31 UTC
I am still seeing this. To reproduce:

- make sure your system is loaded, e.g. compile in background (or just enable Nepomuk ;)
- open a window and place it on one half of the screen
- start an application that needs long to load, e.g. run Kontact on a freshly booted system
- while the startup feedback cursor is visible, quickly move the mouse in- and outside the previously opened window.

This bug can only be seen when the Startup Helper effect is enabled. I use "Passive Busy Cursor" as the Launch Feedback type.
Comment 13 Thomas Lübking 2012-03-19 21:56:50 UTC
that patch won't work sufficiently - the mouse polling interval is below the repaint framerate (and esp. not synced)

@Cristoph or anyone who punishes himself with a blinking cursor
can you try
effects->addRepaint(m_currentGeometry.united(feedbackRect()));
instead?
Comment 14 Christoph Feck 2012-06-25 15:40:57 UTC
Thomas, could you point me to where I need to patch this? I am not familar with KWin code base.

> or anyone who punishes himself with a blinking cursor

As I already wrote above, I do not use the blinking or jumping cursor, but since my panel is hidden, I need the visual cursor feedback :)
Comment 15 Thomas Lübking 2012-06-25 17:54:02 UTC
Created attachment 72131 [details]
repaint rect covered by the move

See attached patch.
The reason is that the mouse can cover an arbitrary amount of px between the two polls and therefore the bouncannoyance an as well arbitrary region inside the bounding rect of the two compared positions. Actually it would even be possible to move the pointer from (0,0) to (100,100) and back to (0,0) within the poll interval - and you'd get a dirty trace on that (but that's only coverable by fullRepaint's - and unlikely worth it)
Comment 16 Christoph Feck 2012-06-26 22:58:05 UTC
The patch doesn't help.
Comment 17 Thomas Lübking 2012-06-26 23:46:08 UTC
Created attachment 72157 [details]
Better fix

Right idea, insufficient approach.
I activated that thing (someone owes me a beer) and could easily reproduce the bug. I was no longer able to reproduce it with the attached new patch. Happy testing.

Side node: i tested the other naggers and the blinking one seems broken at least here - the icon seems to loose it's alpha channel and swaps between a black and white rect (with the icon inside), could be related to the native graphicssystem (since the effectframe also seems to have a bitmask in this case)
Comment 18 Christoph Feck 2012-10-05 17:01:07 UTC
Can someone point me to a patch and/or review request that applies on current master?
Comment 19 Thomas Lübking 2012-10-05 20:06:01 UTC
This *should* have been fixed by
https://git.reviewboard.kde.org/r/105376/
and
https://git.reviewboard.kde.org/r/105786/

Do you still get it?
Comment 20 Christoph Feck 2012-10-05 20:45:30 UTC
Yes, still happens with today's master at 90824dd5.
Comment 21 Thomas Lübking 2012-10-05 21:16:00 UTC
So far not reproducible.
Can you cause it with blurring disabled?
Comment 22 Christoph Feck 2012-10-05 21:44:36 UTC
Created attachment 74365 [details]
qdbus org.kde.kwin /KWin supportInformation

No blur used here.

Note (again), that the bug shows only with mode set to "Passive", using either "Blinking" or "Jumping" does not show the issue.
Comment 23 Thomas Lübking 2012-10-05 22:49:06 UTC
Confirmed, i only fixed the bouncing path (then, tested on it)
Comment 24 Thomas Lübking 2012-11-04 17:41:04 UTC
*** Bug 309541 has been marked as a duplicate of this bug. ***
Comment 25 Ralf Jung 2013-03-10 19:30:48 UTC
I can't see any artefacts with the passive notification cursor (neither blinking nor bouncing) in KDE 4.10.1. Is this expected or did I not try hard enough?
Comment 26 Thomas Lübking 2013-03-10 19:46:28 UTC
(In reply to comment #25)
> I can't see any artefacts with the passive notification cursor (neither
> blinking nor bouncing) in KDE 4.10.1. Is this expected or did I not try hard
> enough?

set 'p'?
Comment 27 Ralf Jung 2013-03-10 20:00:58 UTC
No, this is an unmodified KDE 4.10.1, without the buffer swap patch. VSync is enabled though.
Comment 28 Thomas Lübking 2013-07-21 20:34:01 UTC
Christoph, would you mind applying https://git.reviewboard.kde.org/r/111634/ and see whether you can still reproduce it?
I would prefer to not keep it active everyday ;-)
Comment 29 Thomas Lübking 2013-07-24 19:25:15 UTC
Git commit b5543b28e1d820cd239fdd15a65dd65417318fb8 by Thomas Lübking.
Committed on 23/07/2013 at 20:35.
Pushed by luebking into branch 'KDE/4.11'.

fix passive startup feedback
FIXED-IN: 4.11
REVIEW: 111634

M  +4    -17   kwin/effects/startupfeedback/startupfeedback.cpp

http://commits.kde.org/kde-workspace/b5543b28e1d820cd239fdd15a65dd65417318fb8
Comment 30 Christoph Feck 2013-07-25 10:27:54 UTC
Changed the poll timer to 20 ms, everything looks good now, merci :)
Comment 31 Thomas Lübking 2013-07-25 10:49:58 UTC
(In reply to comment #30)
> Changed the poll timer to 20 ms, everything looks good now, merci :)

That's quite fast (some effects poll all the time)

@Martin
given we atm mostly use the polling to detect mouse presses and modifier changes, should we just remove polling from the startupfeedback and force continuous updates for the passive cursor just as for the bounce and flicker ones?

In return we could maybe even lower the polling interval to 150-200ms.
Comment 32 Martin Flöser 2013-07-25 12:55:47 UTC
> given we atm mostly use the polling to detect mouse presses and modifier
> changes, should we just remove polling from the startupfeedback and force
> continuous updates for the passive cursor just as for the bounce and flicker
> ones?
sounds ok to me
> 
> In return we could maybe even lower the polling interval to 150-200ms.
well there's also mouse mark effect which uses polling without a fullscreen 
window. I guess 150 msec would be too slow to draw a circle.
Comment 33 Christoph Feck 2013-07-25 13:03:12 UTC
I also noticed that the mouse polling interval timer was used for the Zoom effect. My initial impression was that my old system was too slow for a faster zoom, but now that I changed the poll timer, I see _butter smooth_ zoom scrolling, even on my dated i945 system.

> That's quite fast (some effects poll all the time)

If I understand the slot function correctly, it does not do anything, unless the mouse actually moved.
Comment 34 Martin Flöser 2013-07-25 13:34:20 UTC
> > That's quite fast (some effects poll all the time)
> 
> If I understand the slot function correctly, it does not do anything, unless
> the mouse actually moved.
unfortunately on X11 it's an active polling causing wake-ups. On Wayland it 
doesn't matter, the polling is just disabled