Bug 260727

> 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.

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.

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

You probably have to include both the old as well as the new region, because now the icon gets cropped while moving the mouse.

*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

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.

> 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

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...

Patch works, merci.

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

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

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.

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?

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 :)

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)

The patch doesn't help.

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)

Can someone point me to a patch and/or review request that applies on current master?

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?

Yes, still happens with today's master at 90824dd5.

So far not reproducible.
Can you cause it with blurring disabled?

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.

Confirmed, i only fixed the bouncing path (then, tested on it)

*** Bug 309541 has been marked as a duplicate of this bug. ***

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?

(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'?

No, this is an unmodified KDE 4.10.1, without the buffer swap patch. VSync is enabled though.

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 ;-)

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

Changed the poll timer to 20 ms, everything looks good now, merci :)

(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.

> 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.

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.

> > 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