| 2008-08-03 19:00:19 |
Zorael |
bug |
|
|
added bug |
| 2008-08-03 23:30:55 |
Johnny Levai |
kubuntu-kde4-meta: status |
New |
Confirmed |
|
| 2008-10-25 18:55:25 |
kolen |
bug |
|
|
added attachment 'kde4-garbage.jpg' (Firefox window appearing on screen) |
| 2008-11-10 11:46:43 |
Michael Z. Krog |
bug |
|
|
added attachment 'screen.png' (Example of opening af "fresh" opera.) |
| 2008-12-19 11:33:05 |
Zorael |
kubuntu-kde4-meta: bugtargetdisplayname |
kubuntu-kde4-meta (Ubuntu) |
xorg (Ubuntu) |
|
| 2008-12-19 11:33:05 |
Zorael |
kubuntu-kde4-meta: bugtargetname |
kubuntu-kde4-meta (Ubuntu) |
xorg (Ubuntu) |
|
| 2008-12-19 11:33:05 |
Zorael |
kubuntu-kde4-meta: statusexplanation |
The same thing happens on my desktop. It isn't a serious bug, but it's very ugly and sometimes annoying. |
Considering how other distros don't seem to get it, and how people are able to work around it on their Kubuntu systems by installing Debian's X.org package (http://bugs.kde.org/show_bug.cgi?id=170462#c36), it seems to be xserver-xorg specific. |
|
| 2008-12-19 11:33:05 |
Zorael |
kubuntu-kde4-meta: title |
Bug #254468 in kubuntu-kde4-meta (Ubuntu): "[KDE4] momentary video garbage upon drawing new objects" |
Bug #254468 in xorg (Ubuntu): "[KDE4] momentary video garbage upon drawing new objects" |
|
| 2008-12-22 17:33:09 |
Alberto Milone |
bug |
|
|
added attachment 'xorg-server_1.5.99.3-0ubuntu4.debdiff' (debdiff) |
| 2008-12-22 18:10:13 |
Timo Aaltonen |
xorg: bugtargetdisplayname |
xorg (Ubuntu) |
xorg-server (Ubuntu) |
|
| 2008-12-22 18:10:13 |
Timo Aaltonen |
xorg: bugtargetname |
xorg (Ubuntu) |
xorg-server (Ubuntu) |
|
| 2008-12-22 18:10:13 |
Timo Aaltonen |
xorg: statusexplanation |
Considering how other distros don't seem to get it, and how people are able to work around it on their Kubuntu systems by installing Debian's X.org package (http://bugs.kde.org/show_bug.cgi?id=170462#c36), it seems to be xserver-xorg specific. |
|
|
| 2008-12-22 18:10:13 |
Timo Aaltonen |
xorg: title |
Bug #254468 in xorg (Ubuntu): "[KDE4] momentary video garbage upon drawing new objects" |
Bug #254468 in xorg-server (Ubuntu): "[KDE4] momentary video garbage upon drawing new objects" |
|
| 2008-12-23 00:27:49 |
Bryce Harrington |
xorg-server: status |
Confirmed |
Triaged |
|
| 2008-12-23 00:27:49 |
Bryce Harrington |
xorg-server: assignee |
|
tjaalton |
|
| 2008-12-23 00:27:49 |
Bryce Harrington |
xorg-server: importance |
Undecided |
High |
|
| 2008-12-23 00:27:49 |
Bryce Harrington |
xorg-server: statusexplanation |
|
Timo, what are your thoughts on dropping xserver patch 107_fedora_dont_backfill_bg_none.patch ? |
|
| 2008-12-30 23:28:13 |
Timo Aaltonen |
title |
[KDE4] momentary video garbage upon drawing new objects |
momentary video garbage upon drawing new objects |
|
| 2009-01-16 06:27:27 |
Bryce Harrington |
bug |
|
|
assigned to xorg-server |
| 2009-01-16 06:35:19 |
Bryce Harrington |
description |
Binary package hint: kubuntu-kde4-desktop
I'm running KDE 4.1 from the ppa listed at kubuntu.org, but I've had this issue ever since the first 4.0 betas. This is on a Hardy machine.
Whenever a new object is drawn, such as the application menu or any application whatsoever, the space in which it will be drawn is first allocated with video garbage. After a brief delay - perhaps 200ms - the garbage is properly replaced with the real object contents. It looks as if it's displaying "old" video memory, if that makes sense. It is hard/impossible to get a proper screenshot depicting this.
Restoring a minimized Firefox is a surefire way of reproducing it; every other time it will be video garbage, every other time it will just be a black box. And again, application menu, right-click menus, titlebar menus; *anything* KDE4 draws. After having once spawned the object, the next time it will draw "garbagelessly", with some exceptions (such as Firefox, for some reason).
I've tried and gotten this on two machines running Intel integrated graphics (with the xserver-xorg-video-intel driver), and one with the proprietary Nvidia driver; both exhibit the same behavior. I've had some other people confirming it at the Ubuntu forums, too. Please see: http://ubuntuforums.org/showthread.php?t=788023&highlight=drawn+time&p=5009121 and the following few replies.
Enabling or disabling Desktop Effects doesn't seem to make any difference, and I've tried enabling random video options in xorg.conf but I can't say I've had much luck. For instance, on this intel machine:
Option "XAANoOffscreenPixmaps" "true"
Option "InitialPixmapPlacement" "2"
Option "DRI" "true"
Option "AccelMethod" "EXA"
Option "ExaNoComposite" "false"
Option "MigrationHeuristic" "greedy"
Option "BackingStore" "true"
Option "PageFlip" "true"
Option "TripleBuffering" "true"
Again, even with a vanilla xorg.conf with no explicit video options defined, the behavior persists.
Some other info:
$ apt-cache policy kdebase-bin-kde4 kde-window-manager
kdebase-bin-kde4:
Installed: 4:4.1.0-0ubuntu1~hardy1~ppa2
Candidate: 4:4.1.0-0ubuntu1~hardy1~ppa2
Version table:
*** 4:4.1.0-0ubuntu1~hardy1~ppa2 0
500 http://ppa.launchpad.net hardy/main Packages
100 /var/lib/dpkg/status
4:4.0.5-0ubuntu1~hardy1 0
500 http://se.archive.ubuntu.com hardy-backports/main Packages
4:4.0.3-0ubuntu2 0
500 http://se.archive.ubuntu.com hardy/universe Packages
kde-window-manager:
Installed: 4:4.1.0-0ubuntu1~hardy1~ppa2
Candidate: 4:4.1.0-0ubuntu1~hardy1~ppa2
Version table:
*** 4:4.1.0-0ubuntu1~hardy1~ppa2 0
500 http://ppa.launchpad.net hardy/main Packages
100 /var/lib/dpkg/status |
[Symptom]
Whenever a new object is drawn, such as the application menu or any application whatsoever, the space in which it will be drawn is first allocated with video garbage. After a brief delay - perhaps 200ms - the garbage is properly replaced with the real object contents.
[Discussion]
The RedHat patch 107_fedora_dont_backfill_bg_none.patch, which is necessary for obtaining acceptable performance with compositing desktop managers, causes this problem because it bypasses the (sloow) initialization of background pixmaps.
<ajax> the problem is that windows can have their background pixmap set to "None", which means something vaguely like "don't draw a background at all, just reuse the bits underneath wherever the window got mapped"
<rdieter> it seems to have side effects...
<ajax> no kidding!
<ajax> in Composite there's no strong notion of "the bits underneath where you got mapped"
<ajax> since the compositor could map you anywhere
<ajax> trying to do what the protocol says is intensely painfully slow since it's a readback from the card and those aren't fast
<ajax> so what gnome quite sensibly does is tells the compositor not to show the window contents until they're painted, using the same sync protocol that window resizing uses.
<ajax> and then the server just doesn't define initial window contents when the window is both redirected and bg=None
<rdieter> so it wouldn't be wrong to assert there's an issue/buglet here (in kde) still, and the xorg patch is simply helping to expose it?
<ajax> it's sort of ugly no matter what you do, which is why we're still carrying that patch four releases later instead of having it upstream. anything you do here is wrong.
<ajax> you're either breaking protocol semantics that have been good for twenty years, or you're screwing performance.
<ajax> rdieter: i'd say kde should do the sync protocol for mapping here, yes. it'll make it look right on servers with this hack, but it'll also look better on unpatched servers since you won't see the menu in mid-draw
[Original Report]
Binary package hint: kubuntu-kde4-desktop
I'm running KDE 4.1 from the ppa listed at kubuntu.org, but I've had this issue ever since the first 4.0 betas. This is on a Hardy machine.
Whenever a new object is drawn, such as the application menu or any application whatsoever, the space in which it will be drawn is first allocated with video garbage. After a brief delay - perhaps 200ms - the garbage is properly replaced with the real object contents. It looks as if it's displaying "old" video memory, if that makes sense. It is hard/impossible to get a proper screenshot depicting this.
Restoring a minimized Firefox is a surefire way of reproducing it; every other time it will be video garbage, every other time it will just be a black box. And again, application menu, right-click menus, titlebar menus; *anything* KDE4 draws. After having once spawned the object, the next time it will draw "garbagelessly", with some exceptions (such as Firefox, for some reason).
I've tried and gotten this on two machines running Intel integrated graphics (with the xserver-xorg-video-intel driver), and one with the proprietary Nvidia driver; both exhibit the same behavior. I've had some other people confirming it at the Ubuntu forums, too. Please see: http://ubuntuforums.org/showthread.php?t=788023&highlight=drawn+time&p=5009121 and the following few replies.
Enabling or disabling Desktop Effects doesn't seem to make any difference, and I've tried enabling random video options in xorg.conf but I can't say I've had much luck. For instance, on this intel machine:
Option "XAANoOffscreenPixmaps" "true"
Option "InitialPixmapPlacement" "2"
Option "DRI" "true"
Option "AccelMethod" "EXA"
Option "ExaNoComposite" "false"
Option "MigrationHeuristic" "greedy"
Option "BackingStore" "true"
Option "PageFlip" "true"
Option "TripleBuffering" "true"
Again, even with a vanilla xorg.conf with no explicit video options defined, the behavior persists.
Some other info:
$ apt-cache policy kdebase-bin-kde4 kde-window-manager
kdebase-bin-kde4:
Installed: 4:4.1.0-0ubuntu1~hardy1~ppa2
Candidate: 4:4.1.0-0ubuntu1~hardy1~ppa2
Version table:
*** 4:4.1.0-0ubuntu1~hardy1~ppa2 0
500 http://ppa.launchpad.net hardy/main Packages
100 /var/lib/dpkg/status
4:4.0.5-0ubuntu1~hardy1 0
500 http://se.archive.ubuntu.com hardy-backports/main Packages
4:4.0.3-0ubuntu2 0
500 http://se.archive.ubuntu.com hardy/universe Packages
kde-window-manager:
Installed: 4:4.1.0-0ubuntu1~hardy1~ppa2
Candidate: 4:4.1.0-0ubuntu1~hardy1~ppa2
Version table:
*** 4:4.1.0-0ubuntu1~hardy1~ppa2 0
500 http://ppa.launchpad.net hardy/main Packages
100 /var/lib/dpkg/status |
|
| 2009-01-16 06:35:19 |
Bryce Harrington |
title |
momentary video garbage upon drawing new objects |
MASTER: momentary video garbage upon drawing new objects (particularly in KDE) |
|
| 2009-01-16 06:36:46 |
Bryce Harrington |
xorg-server: assignee |
tjaalton |
|
|
| 2009-01-16 06:36:46 |
Bryce Harrington |
xorg-server: statusexplanation |
Timo, what are your thoughts on dropping xserver patch 107_fedora_dont_backfill_bg_none.patch ? |
|
|
| 2009-01-16 18:22:55 |
Bug Watch Updater |
xorg-server: status |
Unknown |
Confirmed |
|
| 2009-01-17 14:45:06 |
Launchpad Janitor |
xorg-server: status |
Triaged |
Fix Released |
|
| 2009-01-19 15:42:43 |
Bug Watch Updater |
xorg-server: status |
Confirmed |
Invalid |
|
| 2009-01-21 13:27:40 |
Michael Chang |
bug |
|
|
assigned to intrepid-backports |
| 2009-01-24 18:18:16 |
Scott Kitterman |
intrepid-backports: status |
New |
Won't Fix |
|
| 2009-01-24 18:18:16 |
Scott Kitterman |
intrepid-backports: statusexplanation |
|
|
|
| 2009-01-25 18:10:34 |
Scott Kitterman |
xorg-server: status |
New |
Confirmed |
|
| 2009-01-25 18:10:34 |
Scott Kitterman |
xorg-server: importance |
Undecided |
High |
|
| 2009-01-25 18:10:34 |
Scott Kitterman |
xorg-server: statusexplanation |
|
|
|
| 2009-01-31 23:48:46 |
LimCore |
bug |
|
|
added attachment 'fail_xorg_random_pixmap_810_kde_intel.ogg' (fail_xorg_random_pixmap_810_kde_intel.ogg) |
| 2009-03-26 00:45:05 |
Jonathan Thomas |
kubuntu-kde4-meta (Ubuntu Intrepid): status |
New |
Invalid |
|
| 2009-03-26 00:45:25 |
Jonathan Thomas |
kubuntu-kde4-meta (Ubuntu Jaunty): status |
New |
Invalid |
|
| 2009-04-01 10:31:22 |
LimCore |
description |
[Symptom]
Whenever a new object is drawn, such as the application menu or any application whatsoever, the space in which it will be drawn is first allocated with video garbage. After a brief delay - perhaps 200ms - the garbage is properly replaced with the real object contents.
[Discussion]
The RedHat patch 107_fedora_dont_backfill_bg_none.patch, which is necessary for obtaining acceptable performance with compositing desktop managers, causes this problem because it bypasses the (sloow) initialization of background pixmaps.
<ajax> the problem is that windows can have their background pixmap set to "None", which means something vaguely like "don't draw a background at all, just reuse the bits underneath wherever the window got mapped"
<rdieter> it seems to have side effects...
<ajax> no kidding!
<ajax> in Composite there's no strong notion of "the bits underneath where you got mapped"
<ajax> since the compositor could map you anywhere
<ajax> trying to do what the protocol says is intensely painfully slow since it's a readback from the card and those aren't fast
<ajax> so what gnome quite sensibly does is tells the compositor not to show the window contents until they're painted, using the same sync protocol that window resizing uses.
<ajax> and then the server just doesn't define initial window contents when the window is both redirected and bg=None
<rdieter> so it wouldn't be wrong to assert there's an issue/buglet here (in kde) still, and the xorg patch is simply helping to expose it?
<ajax> it's sort of ugly no matter what you do, which is why we're still carrying that patch four releases later instead of having it upstream. anything you do here is wrong.
<ajax> you're either breaking protocol semantics that have been good for twenty years, or you're screwing performance.
<ajax> rdieter: i'd say kde should do the sync protocol for mapping here, yes. it'll make it look right on servers with this hack, but it'll also look better on unpatched servers since you won't see the menu in mid-draw
[Original Report]
Binary package hint: kubuntu-kde4-desktop
I'm running KDE 4.1 from the ppa listed at kubuntu.org, but I've had this issue ever since the first 4.0 betas. This is on a Hardy machine.
Whenever a new object is drawn, such as the application menu or any application whatsoever, the space in which it will be drawn is first allocated with video garbage. After a brief delay - perhaps 200ms - the garbage is properly replaced with the real object contents. It looks as if it's displaying "old" video memory, if that makes sense. It is hard/impossible to get a proper screenshot depicting this.
Restoring a minimized Firefox is a surefire way of reproducing it; every other time it will be video garbage, every other time it will just be a black box. And again, application menu, right-click menus, titlebar menus; *anything* KDE4 draws. After having once spawned the object, the next time it will draw "garbagelessly", with some exceptions (such as Firefox, for some reason).
I've tried and gotten this on two machines running Intel integrated graphics (with the xserver-xorg-video-intel driver), and one with the proprietary Nvidia driver; both exhibit the same behavior. I've had some other people confirming it at the Ubuntu forums, too. Please see: http://ubuntuforums.org/showthread.php?t=788023&highlight=drawn+time&p=5009121 and the following few replies.
Enabling or disabling Desktop Effects doesn't seem to make any difference, and I've tried enabling random video options in xorg.conf but I can't say I've had much luck. For instance, on this intel machine:
Option "XAANoOffscreenPixmaps" "true"
Option "InitialPixmapPlacement" "2"
Option "DRI" "true"
Option "AccelMethod" "EXA"
Option "ExaNoComposite" "false"
Option "MigrationHeuristic" "greedy"
Option "BackingStore" "true"
Option "PageFlip" "true"
Option "TripleBuffering" "true"
Again, even with a vanilla xorg.conf with no explicit video options defined, the behavior persists.
Some other info:
$ apt-cache policy kdebase-bin-kde4 kde-window-manager
kdebase-bin-kde4:
Installed: 4:4.1.0-0ubuntu1~hardy1~ppa2
Candidate: 4:4.1.0-0ubuntu1~hardy1~ppa2
Version table:
*** 4:4.1.0-0ubuntu1~hardy1~ppa2 0
500 http://ppa.launchpad.net hardy/main Packages
100 /var/lib/dpkg/status
4:4.0.5-0ubuntu1~hardy1 0
500 http://se.archive.ubuntu.com hardy-backports/main Packages
4:4.0.3-0ubuntu2 0
500 http://se.archive.ubuntu.com hardy/universe Packages
kde-window-manager:
Installed: 4:4.1.0-0ubuntu1~hardy1~ppa2
Candidate: 4:4.1.0-0ubuntu1~hardy1~ppa2
Version table:
*** 4:4.1.0-0ubuntu1~hardy1~ppa2 0
500 http://ppa.launchpad.net hardy/main Packages
100 /var/lib/dpkg/status |
[Important bug]
This bug is an epic fail, because:
* it is a security bug:
* every time you switch windows, open menus, or LOCK THE SCREEN or start SCREEN SAVER, any people near by can see what was on your screen some time ago (random pixmaps).
* this can show up your emails
* this can show up your important documents (think: work and NDAs, and so on)
* this can show p0rn to your children (heh...)
* this can show your passwords (think: copy paste a password received via email, even with OpenPGP)
On top on that, all the things that where suppose to look nice (3d effects), look TERRIBLE, showing ugly random pixmaps instead of nice fadein/out/zoom. This makes entire 3d effects stuff USELESS on affected hardware.
This affects many (most?) intell gfx - so probably most laptops!!!
[Symptom]
Whenever a new object is drawn, such as the application menu or any application whatsoever, the space in which it will be drawn is first allocated with video garbage. After a brief delay - perhaps 200ms - the garbage is properly replaced with the real object contents.
[Discussion]
The RedHat patch 107_fedora_dont_backfill_bg_none.patch, which is necessary for obtaining acceptable performance with compositing desktop managers, causes this problem because it bypasses the (sloow) initialization of background pixmaps.
<ajax> the problem is that windows can have their background pixmap set to "None", which means something vaguely like "don't draw a background at all, just reuse the bits underneath wherever the window got mapped"
<rdieter> it seems to have side effects...
<ajax> no kidding!
<ajax> in Composite there's no strong notion of "the bits underneath where you got mapped"
<ajax> since the compositor could map you anywhere
<ajax> trying to do what the protocol says is intensely painfully slow since it's a readback from the card and those aren't fast
<ajax> so what gnome quite sensibly does is tells the compositor not to show the window contents until they're painted, using the same sync protocol that window resizing uses.
<ajax> and then the server just doesn't define initial window contents when the window is both redirected and bg=None
<rdieter> so it wouldn't be wrong to assert there's an issue/buglet here (in kde) still, and the xorg patch is simply helping to expose it?
<ajax> it's sort of ugly no matter what you do, which is why we're still carrying that patch four releases later instead of having it upstream. anything you do here is wrong.
<ajax> you're either breaking protocol semantics that have been good for twenty years, or you're screwing performance.
<ajax> rdieter: i'd say kde should do the sync protocol for mapping here, yes. it'll make it look right on servers with this hack, but it'll also look better on unpatched servers since you won't see the menu in mid-draw
[Original Report]
Binary package hint: kubuntu-kde4-desktop
I'm running KDE 4.1 from the ppa listed at kubuntu.org, but I've had this issue ever since the first 4.0 betas. This is on a Hardy machine.
Whenever a new object is drawn, such as the application menu or any application whatsoever, the space in which it will be drawn is first allocated with video garbage. After a brief delay - perhaps 200ms - the garbage is properly replaced with the real object contents. It looks as if it's displaying "old" video memory, if that makes sense. It is hard/impossible to get a proper screenshot depicting this.
Restoring a minimized Firefox is a surefire way of reproducing it; every other time it will be video garbage, every other time it will just be a black box. And again, application menu, right-click menus, titlebar menus; *anything* KDE4 draws. After having once spawned the object, the next time it will draw "garbagelessly", with some exceptions (such as Firefox, for some reason).
I've tried and gotten this on two machines running Intel integrated graphics (with the xserver-xorg-video-intel driver), and one with the proprietary Nvidia driver; both exhibit the same behavior. I've had some other people confirming it at the Ubuntu forums, too. Please see: http://ubuntuforums.org/showthread.php?t=788023&highlight=drawn+time&p=5009121 and the following few replies.
Enabling or disabling Desktop Effects doesn't seem to make any difference, and I've tried enabling random video options in xorg.conf but I can't say I've had much luck. For instance, on this intel machine:
Option "XAANoOffscreenPixmaps" "true"
Option "InitialPixmapPlacement" "2"
Option "DRI" "true"
Option "AccelMethod" "EXA"
Option "ExaNoComposite" "false"
Option "MigrationHeuristic" "greedy"
Option "BackingStore" "true"
Option "PageFlip" "true"
Option "TripleBuffering" "true"
Again, even with a vanilla xorg.conf with no explicit video options defined, the behavior persists.
Some other info:
$ apt-cache policy kdebase-bin-kde4 kde-window-manager
kdebase-bin-kde4:
Installed: 4:4.1.0-0ubuntu1~hardy1~ppa2
Candidate: 4:4.1.0-0ubuntu1~hardy1~ppa2
Version table:
*** 4:4.1.0-0ubuntu1~hardy1~ppa2 0
500 http://ppa.launchpad.net hardy/main Packages
100 /var/lib/dpkg/status
4:4.0.5-0ubuntu1~hardy1 0
500 http://se.archive.ubuntu.com hardy-backports/main Packages
4:4.0.3-0ubuntu2 0
500 http://se.archive.ubuntu.com hardy/universe Packages
kde-window-manager:
Installed: 4:4.1.0-0ubuntu1~hardy1~ppa2
Candidate: 4:4.1.0-0ubuntu1~hardy1~ppa2
Version table:
*** 4:4.1.0-0ubuntu1~hardy1~ppa2 0
500 http://ppa.launchpad.net hardy/main Packages
100 /var/lib/dpkg/status |
|
| 2009-05-24 09:35:57 |
Milan Bouchet-Valat |
xorg-server (Ubuntu): status |
Fix Released |
Incomplete |
|
| 2009-08-12 22:39:10 |
Bryce Harrington |
xorg-server (Ubuntu): status |
Incomplete |
Fix Released |
|
| 2009-08-12 22:40:02 |
Bryce Harrington |
tags |
epicfail intell |
intel kubuntu |
|
| 2009-08-13 05:17:34 |
LimCore |
tags |
intel kubuntu |
intel kubuntu nvidia |
|
| 2009-08-13 07:20:57 |
Jonas P |
removed subscriber Jonas P |
|
|
|
| 2009-11-06 21:57:51 |
Michael Ummels |
removed subscriber Michael Ummels |
|
|
|
| 2010-01-09 19:33:34 |
Francisco T. |
removed subscriber Francisco T. |
|
|
|
| 2010-02-12 09:35:48 |
Serhiy Kachaniuk |
removed subscriber Serhiy Kachaniuk |
|
|
|
| 2010-02-22 22:34:53 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/xorg-server |
|
| 2010-04-30 16:58:19 |
Tom Chiverton |
removed subscriber Tom Chiverton |
|
|
|
| 2010-05-07 23:08:43 |
Alex Valavanis |
xorg-server (Ubuntu Intrepid): status |
Confirmed |
Invalid |
|
| 2010-10-18 20:28:00 |
Bug Watch Updater |
xorg-server: status |
Invalid |
Unknown |
|
| 2011-02-04 12:37:42 |
Bug Watch Updater |
xorg-server: importance |
Unknown |
Medium |
|
| 2011-02-04 12:49:39 |
Andrew Davison |
removed subscriber Andrew Davison |
|
|
|
