** Description changed: + [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
** Tags added: epicfail intell -- MASTER: momentary video garbage upon drawing new objects (particularly in KDE) https://bugs.launchpad.net/bugs/254468 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
