Am 20.02.2011, 13:38 Uhr, schrieb Martin Gräßlin <mgraess...@kde.org>:
> With Mesa 7.10 it seems that the driver problems (Mesa 7.8) which hit us
> in
> 4.5 are finally gone and our new compositor is performing much, much
> better
> than the one we have in 4.6. This means from a performance perspective I
> am optimistic that we can go such a way.
FYI:
I 've installed linux on an older notebook this WE and OpenGL on an R100
chip with mesa 7.10 and xf86-ati turned out to be a bad joke - and i'm
talking about glxgears @ 0.2 [sic!] fps here....
(good thing is that i've now more insight on this and compassion with it's
users..., but i didn't get GL compositing to run there at all ("black
screen"), even w/o kms (what fixed glxgears) and neither compiz nor kwin -
XRender works "ok")
> This would imply the following changes
> * Remove the enable checkbox in the compositing KCM
> * Remove the suspend/resume compositing button in the same KCM
Whatever we do, i do strongly recommend to unify this - currently there're
seems some state invalidating conditions (i was about to start this today,
so luckily i got your mail first and didn't waste any time)
However, some plasmoid would certainly be the better way to provide
suspend/resume than some hidden button in some kcm.
> * Remove the "functionality checks" - the heuristic is rather useless
> anyway
PRO - i turned it off immediately (since the system can hang for whatever
reason, turning off compositing might not fix it at all and i think it
caused me one of the invalid compositing states)
> * Disable unredirect fullscreen windows by default
con)
Beware HD video playback - every current intel chip based system out there
(i don't know about state of ati acceleration on linux - at least not for
an R100 ;-) will push this + TFP entirely to the CPU :s
To me the only justification to not unredirect FS windows seem special
environments like netbooks, ie. this would be a distro thing.
pro)
However and with resp. to the present issues with screensavers and
memcorruptions after resume from STR, we might actually better push a root
window property spec to "block" compositing (i guess dbus won't become
part of NETWM :-) - allowing clients to anytime hint: "i'm a resource
intense fullscreen/fullstage client - make me go fast!"
Also there's a bug (in kwin?) if you suspend from an unredirected client -
seems the server is and remains grabbed then...
> I am unsure about keeping respect to the Compositing/Enabled config
> option. I would say we do not honor it in development mode, but honorit
> again in the branch. This way users could still disable it if something
> goes bad.
see above as well - if we allow to "block" compositing this way it would
be sufficient to set this property before kwin starts up (and can be
changed anytime later on. at least we should not have the separate
suspended/disabled conditions)
> What do you think about this idea?
In general a big PRO - since the X11 backingstore seems to die (?!) and
every system should be able to do at least XRender compositing (i've
installed openbox+xcompmgr on a Mach64 chip - that's an 8MB "All-In-Wonder
Pro" ;-) there's no point in assisting users to shoot themselves for
assumed power saving etc.
We just should ensure
a) a sane downward staging
GL fails (or is greylisted "slow") -> TELL the user & ASK to try
XRender - yes i know that the fallback was removed for issues, but
consider them gone if it happens explicitly (we don't have to use nerd
terms like GL & XRender ;-)
XRender fails -> say sorry and "suspend" it by default (TELL the user
that and how to "re-try")
b) a scaling (standard defining!) way to define conditions for temp.
suspension (ssaver, STR, games, video playback etc) - we might have a
short talk to smplayer + vlc developers on why the FS video panels should
preferably not be root children and a longer talk to wine developers ;-)
--
Cheers,
Thomas
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
