Volker Armin Hemmann posted on Wed, 26 Aug 2009 18:13:51 +0200 as excerpted:
> On Mittwoch 26 August 2009, Duncan wrote: > By 4.2.4 (and I think for 4.2.0, maybe even >> 4.1.something), kde had fixed that. It now tries to detect if OpenGL >> will work before setting it, and normally won't let you set it if it >> thinks it won't work. You can override it, but in ordered to do so you >> have to click thru several warnings, and anybody doing that should be >> prepared to live with the consequences. One bug down, and a very bad >> one at that, so good work, kde. >> >> > no, it tries if composite works with the pre-selected composite type > (either ogl or xrender). > > And to turn off this test you only have to unselect one checkbox - > without warnings. In fact, without that check composite works fine for > me, while with the check my box loves to lock up with some driver > versions. > > xrender on the other hand is just utterly broken beyond help. I wasn't aware of it checking composite (they dramatically improved that in 4.3.0 and I'm still discovering bits of it I didn't know about from my initial setup on 4.2.4), but it also checks OpenGL support, and that's what the warnings are on if you don't have it. It seems you don't have an issue with OpenGL support, however, so you'd never see the warnings. It would appear that just as I wasn't aware of some of the new composite stuff since that works just fine here, you weren't aware of the OpenGL stuff since that works just fine for you. >> The one I had learned around, that still exists, is that while kde now >> detects OpenGL compatibility and won't let you switch to it without >> warnings if it thinks it won't work, on the all-effects tab (of the >> desktop effects settings applet), there's still no indication of what >> effects simply do nothing in xrender/composite-only mode. > > except there is a warning popup when you enable composite telling you > exactly which stuff does not work. Like explosion. That popup appears whenever the mode changes, it would seem. Composite toggle, it appears. OpenGL/Xrender toggle, it appears as well. Of course, on a system with everything working, it wouldn't appear except when switching out of OpenGL mode, if any OpenGL-only effects (like the mouse locater) are enabled. But that doesn't cure the problem I'm talking about, which is that in Xrender/composite-only mode (no OpenGL), it should dim out the effects that require OpenGL. For that matter, if composite doesn't work (or when it's disabled), it should dim out the effects requiring composite, too. I think all the effects require one or the other, in which case with both disabled, the whole tab could be either disabled or removed. >> One thus has >> to trial-and-error enable and test anything that looks interesting one >> by one, and if it does nothing, preferably disable it again. If they >> won't work anyway in xrender/composite-only mode, they should be >> disabled in that mode, so only the effects that actually work are >> available to select and try. > > even better, per default only effects that work on the vast majority of > systems are activated. If you are turning on the rest and they don't > work you get a nice warning message after clicking the 'apply' button. > You then can unselect them - or don't care because they are not used > anymore. Except I don't get that "nice warning". With OpenGL off, Explode, the Cube, Track Mouse, Snow, Cover-switch, and perhaps others, silently allow enabling, no warning, they simply do nothing. They should be dimmed out and not even available to be chosen, as they require OpenGL which isn't on. >> Since most don't work without OpenGL, showing them as available to try >> and then having them do nothing when people do just that, is confusing >> at best. Dim them out and don't let people select them in that case, >> and usability on that tab for Composite-only users would go up several >> hundred percent. > > confusing? > 'Following effects could not be enabled: Explosion' Except that only pops up when the mode is switched, not when specific items are enabled and/or when one hits apply. > right after the test. > You can still enable them, in case the next driver update fixes that, > the one you are installing in five minutes or ignore them, because they > do no harm deactivated. > > What is not nice about it? Non working stuff is just ignored - and told > so. If you choose to ignore the warnings - well, that is YOUR choice. Except as I've said, there are no warnings for effect toggles, only when the composite/opengl/xrender the mode is switched. > KDE is about choice, you know? Indeed. Something we agree on! =:^) > or you are using hardware that is way, way tooo slow. Or you are hit by > the backfill patch fallout. Or you are using hardware that was never > meant for this kind of stuff. This part is purely a settings thing, no more, no less. If people are having trouble with performance, these settings should help, as they did me. I was simply passing them on for others who may find them helpful. No more, no less. >> The simple thing is to simply set that to instant, 0 ms. However, >> typing a specific value in the textbox also works, and I discovered >> that anything up to about 20ms was fine. But of course using the >> spinner, the resolution means 0 or 100ms, unless you type it in. > > and you can type it in. Isn't that userfriendly? ?? I wasn't saying it wasn't userfriendly. All I'm saying is that the spinner increment is too high -- don't use it when setting this, if you're doing it in ordered to increase performance, anyway. Just type it in. So I've no idea where you're comment is coming from. It makes no sense in context. >> What could be the problem now? Turn off transparency just to check, >> sure enough the problem went away. But it couldn't be /just/ that, as >> that's a kwin v4 thing, and I had it running fine on kde3. So the >> problem now had to be the kde4 desktop itself, or rather, how it >> interacted with kwin. > > no. You are wrong here. kwin3 does not have 'real' transparency. Hust > fake one. Fake one is pretty fast even on utterly broken hardware. Real > transparency is used by kwin4. And that needs at least sane drivers and > not hardware from yesrermillenium. You are comparing apples to oranges > here. Yes, kwin3 *DID* have real transparency, working with xorg composite, which provided the functionality. Without composite, it didn't work, so yes, it /was/ real xorg based composite transparency. In that regard, kwin4 uses exactly the same composite functionality that kwin3 used. What I believe you're referring to is the "fake" transparency certain kde3 apps (kicker and konsole, at least) used well before xorg composite even appeared. Not only were they doing it earlier, so it couldn't /possibly/ have used xorg's composite, but unlike the xorg composite based transparency of kwin3 (from 3.5.1, IIRC), it was clearly "fake" from a developer perspective in that all it did was take the desktop pixel values and blend them with the application window pixel values, to form a "fake" transparency that was actually simply duplication and blending at the individual application window level. It was clearly "fake" transparency from a user perspective as well, since it didn't "see" any intervening windows between it and the desktop, like "real" composite based transparency does. That's a mistaken generalization of fact that a lot of people make. konsole3 and kicker never had "real" transparency, no, it was all faked. But kwin itself did, using the same xorg composite extension that kwin4 does for that and other non-OpenGL based effects. Zooming, drop-shadows, the zooming based present-windows task-switcher and desktop-grid effects, all these are composite based, using the /same/ xorg composite technology kwin3 did, post 3.5.1, I believe was the version that introduced it. >> But guess who was one of the big users of the bad code? Right, plasma. >> Turns out that each plasmoid update was triggering a repaint, not for >> that relatively small rectangular area, BUT FOR THE ENTIRE CONTAINER. >> Now that's bad enough if it's a panel, but when that widget is on the >> desktop, ITS THE ENTIRE DESKTOP! Of course, when it's a dynamically >> updating plasmoid such as a temperature or CPU activity gauge, guess >> what, you're now repainting the entire desktop at every update of that >> plasmoid. And if there's several such plasmoids... > > they do nothing with recent enough graphics hardware :P And you know why? It's because the graphics hardware accelerates the repaint, and is smart enough to realize that the entire desktop doesn't need repainted, despite the instructions it was handed. =:^) But qt's still handing the hardware bad instructions. The hardware's just smart enough to recognize and ignore the parts that haven't actually updated and thus don't actually need repainted. But of course not everybody has that level of hardware acceleration yet. >> That's bad enough as it is, but when it's just the bare desktop, still >> tolerable. But now consider what happens when that's being filtered up >> thru multiple layers of semi-transparent windows! No *WONDER* people >> with older or not well accelerated graphics cards are having issues! >> And on a desktop the size of mine, say 1920x2200 after the panels top >> and bottom are removed, still running on a vintage Radeon 9200, that's >> a HUGE performance issue! No WONDER I was having problems with it! > > and now we are getting down to the interessting facts. > > The short version of all your text: > > 'I had tried some graphic demanding stuff, turned into a even bigger > workload by a small programming mistake on hardware that was even > considered slow and underpowered when it was released 6 years ago.' May be, but that doesn't change the need to do the tweaks to fix the problem, which was what the entire post was about. Given the problems others have posted, it's likely to be helpful to them as it was to me, and there's no reason they should have to do all the same work I did to rediscover what I already know, after learning it the hard way. >> But meanwhile, its the stack of bugs such as this, that really >> shouldn't be appearing in an X.0 release let alone X.3, that's >> distressing. And it's even /more/ distressing when support for the >> previous very stable version is being dropped, before the current >> version even gets up to normal X.0 version quality, let alone the X.1 >> that many wait for before they consider it safe to switch. > > you mean bugs that only hit when you use modern graphics on a 6 year > old, slow even then, graphic adapter? Could be, but regardless, there's people out there using such hardware, and the posted information both explains how I discovered the issues, and the workarounds and configuration tweaks necessary to get decent performance anyway, despite the age and speed of the hardware. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
