| Summary: | bad font rendering after 'switch behind' effect | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Fabian B. <apfelmausmail> |
| Component: | general | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | mzanetti |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: |
image to visualize the bug ^^
Patch that adds a repaint after unmanaging windows. |
||
|
Description
Fabian B.
2009-07-05 09:19:13 UTC
Created attachment 35056 [details]
image to visualize the bug ^^
hmm such effects are completely unrelated to the way applications render the text. Can you reproduce the behaviour without the effect? (In reply to comment #2) It looks like there is a very slight (Less than a single pixel) offset on the window after the animation has occurred. Could be a rounding error somewhere and the animation never completes. @Michael: could comment #3 be possible? without this effect the text is allways sharp (In reply to comment #4) As the font renders correctly after moving the mouse over it I don't think that the animation never completes. I've also re-checked the code. It is aware of those rounding errors and should handle that correctly. I'd rather guess the last paint cycle is missing in some cases. Does this happen every time the effect is triggered or just in some cases? (In reply to comment #6) > (In reply to comment #4) > > As the font renders correctly after moving the mouse over it I don't think that > the animation never completes. I've also re-checked the code. It is aware of > those rounding errors and should handle that correctly. > > I'd rather guess the last paint cycle is missing in some cases. > > Does this happen every time the effect is triggered or just in some cases? everytime here Created attachment 35530 [details]
Patch that adds a repaint after unmanaging windows.
Could someone affected by this bug please try this patch against kdebase/workspace/kwin/effects/slideback/ and tell me if it fixes the problem?
Thanks.
(In reply to comment #8) I dont know how to compile only the effect, can you post a little howto for me? > I dont know how to compile only the effect, can you post a little howto for me?
The quick and dirty way for re-building kwin effects:
- Checkout whole kdebase-workspace
- apply the patch
- create a build dir
- cmake whole kdebase-workspace
- cd kwin/effects/ (in build-dir)
- make
- copy build/lib/kwin4_effects_builtins.so to `kde4-config --prefix`/lib/kde4/
After copying kwin may crash and should reload itself with the new effects library. If not, just restart kwin.
OK Tested an works 100% :D but now i noticed an the same Problem in other effects If i resize or move a Window with wobly window enable :( should i open another bugreport? OK... I'll commit and backport this patch. Thanks for reporting and testing! All effects showing this behaviour should get their own bugreport, yes. Patch has not been committed to trunk yet therefore not FIXED. SVN commit 1001777 by mzanetti: Add a full repaint after the animation BUG: 198986 M +1 -0 slideback.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1001777 |