On Sunday 20 February 2011 18:18:41 Thomas Lübking wrote: > Am 20.02.2011, 15:45 Uhr, schrieb Martin Gräßlin <mgraess...@kde.org>: > > If we know that R100 does not support it, we could use the GLPlatform to > > w/o kms glxgears ran @200fps - that's not much, but might be enough. the > problem seems that the driver only provides GL 1.2 for the GPU - whether > for HW or SW limitations i didn't figure so far. that get's me to think: what is actually our minimum GL requirement? I would say that we should at least require 1.5 but what is our code's requirement? Anyone knows it or do we need to track down the code? ;-) > > > detect it. Maybe find some sensible requirements? E.g. at least R300 or > > NVIDIA 6xxx for OpenGL compositing? > > nVidia GeForceFX does fine (have used it on a 5200FX - but you should not > attempt to run google earth on top of it ;-) I guess with old nvidia cards you easily hit the black window issue. > > > A plasmoid not in the default is as hidden as the button and I don't > > think it's something for a default panel. > > yes. or the cashew? (dunno) > > > we know if we are a netbook, so we could change that. > > does this mean "through solid" or "because plasma-netbook is running" - > latter is not the same as "is a netbook"... true that should be through solid. > > > This blocking is a nice idea. It would allow to really trigger a suspend > > and not just unredirection and would also handle the hd case very well > > (yes I turn compositing off when watching hd) > > It could however turn out tricky in implementation. > Either we keep properties on clients - killing central user control or we > have a central root property and to rely on "clients don't f*** around > with the counter" (which will probably be necessary so exiting one blocker > will not resume compositing while others are up) I am more for on client and the compositor keeps track of it. No reason to allow clients to f*** around with it (and no I don't trust those apps). > I'd prefer the central solution, since it provides an "easy" and WM > agnostic final control for the user. > > > I would like to have this work mostly automatically and our last attempt > > just failed ;-) > > Since there's a gap between the XRender and OpenGL features, the user > should at least know (the "effect loading failed and kwin doesn't say why" > bugreport) The better solution would be to hide the effects which are not supported by the current profile. > > > Maybe we could do something like trying to use OpenGL - if it works we > > assume that TFP works. > > If GLX_EXT_texture_from_pixmap is promoted and does not work, that's a bug > in the GL driver. The user should face the problem, report a bug and get > the hint to select XRender until the driver is fixed. > If GLX_EXT_texture_from_pixmap is NOT promoted and we strike shm, GL > compositing is not supported and we should suggest to use XRender. there is no shm in master any more :-) If tfp is not supported it has to be XRender as fallback. > I think the biggest problem with the former fallback was that it happened > under the hood and users wondered why things didn't work or sometimes were > fast and sometimes not. > Ie. we need (in case of failure) a guided setup, not heuristic self-fixing. the problem was that we run into a race condition with all drivers except the NVIDIA blob. > > > I will spend some thinking on it as I would like to automaticallybe able > > to select EGL backend if possible (GLX just sucks). > > Since we should know whether EGL is supported at all we can select it > (though i wonder how distros are gonna handle this: kde-workspace-gles ./. > kde-workspace-glx? eeww...) no idea yet and probably off-topic to the thread. What I play around as an idea in my head is to compile all compositing parts twice and load the compositor as a plugin depending on EGL works or not. The test could be done by two out-of-process applications: one compiled against GLX (could be the same as the current direct rendering check app), one against EGL. What I'm afraid of is startup-time.
Cheers Martin
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel