Re: Systemcolors in SVGs
On Sunday 20 February 2011, Manuel Mommertz wrote: Hello, since 4.6 plasma allows prepered svgs to use system colors. For this to work the svg needs to have a css-style with the id 'current-color-scheme' which gets replaced by a style containing classes with the actual system colors on load. For someone with knowlage of xml/svg code it should be trivial to apply this after the graphic itself was finished. But I think most people creating graphics don't want to dive in the source code. For this purpose I am working on a little tool to help them. a thing that would be realy needed for this, is documentation /howto on a wiki page, as a subcategory, or sub page of http://techbase.kde.org/Development/Tutorials/Plasma/Theme Take a look at http://kame2.de/KDE/svgmod/ To get a colorscheme aware svg there are four steps needed: * Define which system colors you want to use. * Create the svg like you are used to but use one defined color at places where on system color should take effect. * Add the corresponding classes to your svg with svgmod -a * Transform elements using a defined color to the corresponding system color with svgmod -c very useful tool indeed! the existence of this too lshould be docuented as well, and i think it should be distributed by KDE somewhere, what about together a) kde-sdk, or b) plasmate? Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
[RFC] Enforcing Compositing
Hi all, sending this to both Plasma and KWin as the idea affects the complete workspace. Since 4.2 we have enabled OpenGL based compositing by default and I was wondering if in 4.7 we should go the next step: disabling the possibility to turn compositing off if supported. 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. This would imply the following changes * Remove the enable checkbox in the compositing KCM * Remove the suspend/resume compositing button in the same KCM * Remove the functionality checks - the heuristic is rather useless anyway * Disable unredirect fullscreen windows by default I would keep * the shortcut to suspend compositing * the dbus call to toggle compositing (might be useful for games and so on) I am unsure about keeping respect to the Compositing/Enabled config option. I would say we do not honor it in development mode, but honor it again in the branch. This way users could still disable it if something goes bad. For development it's better to have the option not honored to get bugs reported ;-) If compositing is not supported, it will not try to enable it, so no problem for our old, old, old users. (Though I doubt Plasma is of any use in a system not supporting OpenGL). What do you think about this idea? 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
Re: Systemcolors in SVGs
On Sunday 20 February 2011 12:03:15 Marco Martin wrote: On Sunday 20 February 2011, Manuel Mommertz wrote: Hello, since 4.6 plasma allows prepered svgs to use system colors. For this to work the svg needs to have a css-style with the id 'current-color-scheme' which gets replaced by a style containing classes with the actual system colors on load. For someone with knowlage of xml/svg code it should be trivial to apply this after the graphic itself was finished. But I think most people creating graphics don't want to dive in the source code. For this purpose I am working on a little tool to help them. a thing that would be realy needed for this, is documentation /howto on a wiki page, as a subcategory, or sub page of http://techbase.kde.org/Development/Tutorials/Plasma/Theme Yes but for the usual audience this has to be based on svgmod rather then modifying the code. For the more technical audience there is documentation at http://techbase.kde.org/Projects/Plasma/Theme#Using_system_colors Take a look at http://kame2.de/KDE/svgmod/ To get a colorscheme aware svg there are four steps needed: * Define which system colors you want to use. * Create the svg like you are used to but use one defined color at places where on system color should take effect. * Add the corresponding classes to your svg with svgmod -a * Transform elements using a defined color to the corresponding system color with svgmod -c very useful tool indeed! the existence of this too lshould be docuented as well, and i think it should be distributed by KDE somewhere, what about together a) kde-sdk, or b) plasmate? I am fine with this but have to say that I am low on time. I can only investigate few hours a week in this. And I would need some guidance on adding this to git. (more the administrational stuff then the technical) Cheers Manuel Mommertz ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [RFC] Enforcing Compositing
Since 4.2 we have enabled OpenGL based compositing by default and I was wondering if in 4.7 we should go the next step: disabling the possibility to turn compositing off if supported. With Mesa 7.10 it seems that the driver problems (Mesa 7.8) which hit us in 4.5 are finally gone (...) What do you think about this idea? Well, it's hard to predict the future. Drivers could get regressions again. I think the problem is less the ability to turn off compositing, it's the wording. IMO the Enable desktop effects checkbox should only apply to the actual effects but not the compositing support. I've seen people in forums who are not interested in shadows, transparent windows etc. They dislike eye candy. What they don't get in some cases is that enabled compositing and all effects turned off should be better in most situations (unless the driver is broken). For disabling compositing, people could use the Advanced tab with the new option None added to the Compositing type drop down menu. I would keep * the shortcut to suspend compositing * the dbus call to toggle compositing (might be useful for games and so on) Could the shortcut call dbus? What I experienced when occasionally turning off composite support manually is that the shortcut does not flip the composite switch plasmoid and the shortcut always overrules the plasmoid which means that I can't turn it on again using the plasmoid. Markus ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [RFC] Enforcing Compositing
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
Re: [RFC] Enforcing Compositing
On Sunday 20 February 2011 14:47:17 Markus Slopianka wrote: Since 4.2 we have enabled OpenGL based compositing by default and I was wondering if in 4.7 we should go the next step: disabling the possibility to turn compositing off if supported. With Mesa 7.10 it seems that the driver problems (Mesa 7.8) which hit us in 4.5 are finally gone (...) What do you think about this idea? Well, it's hard to predict the future. Drivers could get regressions again. True, but I hope that the drivers developers and distributions are more aware of the situation now. And if compositing is enforced it will be detected more early as the affected KDE devs will come into #kwin and yell at us :-) In general I think that the driver devs must be aware they their drivers may never regress again if they want that the DEs transit from X11 to Wayland - and we all want that. I think the problem is less the ability to turn off compositing, it's the wording. IMO the Enable desktop effects checkbox should only apply to the actual effects but not the compositing support. I've seen people in forums who are not interested in shadows, transparent windows etc. They dislike eye candy. What they don't get in some cases is that enabled compositing and all effects turned off should be better in most situations (unless the driver is broken). The problem is that the users are miss informed. Compositing is not about eye- candy but about providing a better user interface. Why should it be possible to disable Present Windows or Desktop Grid? I don't see a reason why we should make it possible to disable such effects. And concerning transparent windows and shadows: that's not done in effects. It's part of the base compositor. For disabling compositing, people could use the Advanced tab with the new option None added to the Compositing type drop down menu. That might be a good idea I would keep * the shortcut to suspend compositing * the dbus call to toggle compositing (might be useful for games and so on) Could the shortcut call dbus? What I experienced when occasionally turning off composite support manually is that the shortcut does not flip the composite switch plasmoid and the shortcut always overrules the plasmoid which means that I can't turn it on again using the plasmoid. The plasmoid is completely outdated and useless and not adjusted to KWin's current API. It should not be used and best deleted from the SVN. 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
Re: [RFC] Enforcing Compositing
On Sunday 20 February 2011 15:12:58 Rohan Prabhu wrote: Hi, Having compositing enabled by default is good. Not allowing the user to switch it off is bad. Here are a few reasons why I think so: 1. Support does not mean performance: even though on some systems there would be enough support to have OpenGL compositing, the system may not perform that well. The performance may be choppy, and might cause a systemic lag. And it's not always possible to have an algorithmically valid assessment of this performance. We have two categories of problems 1. Hardware not supporting OpenGL properly (e.g. Ati R100 in Thomas' example) 2. Performance problems caused by bad implementation For the first one, there is only one solution: Don't use Plasma. It does not meet our hardware requirement. Windows 7 wouldn't run on it, Mac OS X would not run on it, GNOME Shell would not run on it, Unity would not run on it, why should Plasma still support legacy hardware? The second issue should be gone with modern drivers (= 7.10) and modern compositor (master). If you currently have performance issues, install mesa 7.10 and current master and try again ;-) I do understand that if compositing is enabled without any effects, it shouldn't consume a lot more resources, Effects do not cause more resources - those are idle most of the time. If you don't use present windows, it won't cause resources to be occupied. but for newer users or non-experienced users, it might be a little troubling. 2. Some applications have a problem with compositing. A very specific example would be Warcraft III using Wine. Whenever I alt+tab without compositing on, it works. With compositing on, when I alt-tab back, all I get is a black screen. So for quite a few games I have to switch off compositing and play. Another good example would be Quake where the performance is affected severely with compositing on. see Thomas' mail to the performance with e.g. games and possible solutions 3. Some just dont like it: I dont like the transperencies of the plasma dashboard and the tooltip boxes. I just put up with it because i really think alt+tabbing is cool and i am too lazy to track down which effect causes the transperency. Don't like is no valid argument ;-) And no effect is responsible for transparency, that's built-in My point is, dont enforce anything on the user. If need be, make it default but allow the user to change it if he/she wishes. Regards, rohan On 2/20/11, Martin Gräßlin mgraess...@kde.org wrote: Hi all, sending this to both Plasma and KWin as the idea affects the complete workspace. Since 4.2 we have enabled OpenGL based compositing by default and I was wondering if in 4.7 we should go the next step: disabling the possibility to turn compositing off if supported. 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. This would imply the following changes * Remove the enable checkbox in the compositing KCM * Remove the suspend/resume compositing button in the same KCM * Remove the functionality checks - the heuristic is rather useless anyway * Disable unredirect fullscreen windows by default I would keep * the shortcut to suspend compositing * the dbus call to toggle compositing (might be useful for games and so on) I am unsure about keeping respect to the Compositing/Enabled config option. I would say we do not honor it in development mode, but honor it again in the branch. This way users could still disable it if something goes bad. For development it's better to have the option not honored to get bugs reported ;-) If compositing is not supported, it will not try to enable it, so no problem for our old, old, old users. (Though I doubt Plasma is of any use in a system not supporting OpenGL). What do you think about this idea? Cheers Martin ___ kwin mailing list k...@kde.org https://mail.kde.org/mailman/listinfo/kwin 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
Re: [RFC] Enforcing Compositing
On Sunday 20 February 2011 14:52:16 Thomas Lübking wrote: 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) If we know that R100 does not support it, we could use the GLPlatform to detect it. Maybe find some sensible requirements? E.g. at least R300 or NVIDIA 6xxx for OpenGL compositing? 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. A plasmoid not in the default is as hidden as the button and I don't think it's something for a default panel. * 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. we know if we are a netbook, so we could change that. 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... 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) 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) I would like to have this work mostly automatically and our last attempt just failed ;-) Maybe we could do something like trying to use OpenGL - if it works we assume that TFP works. I will spend some thinking on it as I would like to automatically be able to select EGL backend if possible (GLX just sucks). 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 ;-) hehe :-) signature.asc Description: This is a digitally signed message part. ___
Re: [RFC] Enforcing Compositing
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. 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 ;-) 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... 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'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) 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. 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. 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...) Cheers, Thomas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [RFC] Enforcing Compositing
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
Re: [RFC] Enforcing Compositing
Hi, On 02/20/11 13:38, Martin Gräßlin wrote: Hi all, sending this to both Plasma and KWin as the idea affects the complete workspace. Since 4.2 we have enabled OpenGL based compositing by default and I was wondering if in 4.7 we should go the next step: disabling the possibility to turn compositing off if supported. 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. This would imply the following changes * Remove the enable checkbox in the compositing KCM * Remove the suspend/resume compositing button in the same KCM * Remove the functionality checks - the heuristic is rather useless anyway * Disable unredirect fullscreen windows by default I can't see your pros about removing it. Is it your goal to improve effects KCM usability? Bye, Davide Bettio. signature.asc Description: OpenPGP digital signature ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [RFC] Enforcing Compositing
On Sunday 20 February 2011 20:51:53 Davide Bettio wrote: Hi, On 02/20/11 13:38, Martin Gräßlin wrote: Hi all, sending this to both Plasma and KWin as the idea affects the complete workspace. Since 4.2 we have enabled OpenGL based compositing by default and I was wondering if in 4.7 we should go the next step: disabling the possibility to turn compositing off if supported. 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. This would imply the following changes * Remove the enable checkbox in the compositing KCM * Remove the suspend/resume compositing button in the same KCM * Remove the functionality checks - the heuristic is rather useless anyway * Disable unredirect fullscreen windows by default I can't see your pros about removing it. Is it your goal to improve effects KCM usability? No, while the KCM sucks it will still suck after those three options have been removed. It needs a proper redesign, but that is out of the scope of this thread ;-) 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
Re: [RFC] Enforcing Compositing
On Sunday 20 February 2011 22:18:16 Davide Bettio wrote: Hi, On 02/20/11 22:06, Martin Gräßlin wrote: I can't understand the point about removing enable/disable options. if we don't want to give the user the possibility to disable, we don't need an option to enable/disable. I don't see anything bad about having enable/disable options on the KCM. The only con that I'm aware of is that we have more checkboxes. Consider the button would not be there: would you see pro arguments to add one? Let's turn the question around: why should the user be able to enable or disable compositing? What would be a valid reason to do so? And keep in mind: with Wayland it will be impossible to turn off compositing, same in GNOME Shell, Unity and Mac OS X (don't know about Windows). The main reason is that buggy software is still around. And how do we get the buggy software fixed if we allow workarounds? 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
Re: [RFC] Enforcing Compositing
Hi, On 02/20/11 22:06, Martin Gräßlin wrote: I can't understand the point about removing enable/disable options. if we don't want to give the user the possibility to disable, we don't need an option to enable/disable. I don't see anything bad about having enable/disable options on the KCM. The only con that I'm aware of is that we have more checkboxes. Let's turn the question around: why should the user be able to enable or disable compositing? What would be a valid reason to do so? And keep in mind: with Wayland it will be impossible to turn off compositing, same in GNOME Shell, Unity and Mac OS X (don't know about Windows). The main reason is that buggy software is still around. Bye, Davide Bettio. signature.asc Description: OpenPGP digital signature ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [RFC] Enforcing Compositing
On Sunday 20 February 2011 22:11:35 Beat Wolf wrote: On this computer, using the binary nvidia drivers, i could enable compositing. But due to some nvidia driver bugs, my computer becomes slugish very fast, which means compositing is not an option. i don't think that the x.org environment is stable enough to be able to remove a option that lets you work around bugs. bugs need to be fixed and not worked around. That is exactly one of the reasons why I want to have it disabled. It's just not an option that something like 4.5 happens ever again! We need to know problems during development and if devs tend to just turning of compositing it will happen again. Beat Wolf Am Sonntag, 20. Februar 2011, um 22:06:24 schrieb Martin Gräßlin: On Sunday 20 February 2011 22:00:58 Davide Bettio wrote: Hi, On 02/20/11 21:57, Martin Gräßlin wrote: No, while the KCM sucks it will still suck after those three options have been removed. It needs a proper redesign, but that is out of the scope of this thread ;-) I can't understand the point about removing enable/disable options. if we don't want to give the user the possibility to disable, we don't need an option to enable/disable. Let's turn the question around: why should the user be able to enable or disable compositing? What would be a valid reason to do so? And keep in mind: with Wayland it will be impossible to turn off compositing, same in GNOME Shell, Unity and Mac OS X (don't know about Windows). ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel 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
Re: [RFC] Enforcing Compositing
On this computer, using the binary nvidia drivers, i could enable compositing. But due to some nvidia driver bugs, my computer becomes slugish very fast, which means compositing is not an option. i don't think that the x.org environment is stable enough to be able to remove a option that lets you work around bugs. Beat Wolf Am Sonntag, 20. Februar 2011, um 22:06:24 schrieb Martin Gräßlin: On Sunday 20 February 2011 22:00:58 Davide Bettio wrote: Hi, On 02/20/11 21:57, Martin Gräßlin wrote: No, while the KCM sucks it will still suck after those three options have been removed. It needs a proper redesign, but that is out of the scope of this thread ;-) I can't understand the point about removing enable/disable options. if we don't want to give the user the possibility to disable, we don't need an option to enable/disable. Let's turn the question around: why should the user be able to enable or disable compositing? What would be a valid reason to do so? And keep in mind: with Wayland it will be impossible to turn off compositing, same in GNOME Shell, Unity and Mac OS X (don't know about Windows). ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [RFC] Enforcing Compositing
Hi, On 02/20/11 21:57, Martin Gräßlin wrote: No, while the KCM sucks it will still suck after those three options have been removed. It needs a proper redesign, but that is out of the scope of this thread ;-) I can't understand the point about removing enable/disable options. Bye, Davide Bettio. signature.asc Description: OpenPGP digital signature ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [RFC] Enforcing Compositing
Then leave it out during dev, but in when releasing. I just don't agree that for example nvidia will fix their drivers just because kde does not work with some, probably older cards. But i know that i can't win that debate. But i just know that such a decision will cause problems. Am Sonntag, 20. Februar 2011, um 22:19:53 schrieb Martin Gräßlin: On Sunday 20 February 2011 22:11:35 Beat Wolf wrote: On this computer, using the binary nvidia drivers, i could enable compositing. But due to some nvidia driver bugs, my computer becomes slugish very fast, which means compositing is not an option. i don't think that the x.org environment is stable enough to be able to remove a option that lets you work around bugs. bugs need to be fixed and not worked around. That is exactly one of the reasons why I want to have it disabled. It's just not an option that something like 4.5 happens ever again! We need to know problems during development and if devs tend to just turning of compositing it will happen again. Beat Wolf Am Sonntag, 20. Februar 2011, um 22:06:24 schrieb Martin Gräßlin: On Sunday 20 February 2011 22:00:58 Davide Bettio wrote: Hi, On 02/20/11 21:57, Martin Gräßlin wrote: No, while the KCM sucks it will still suck after those three options have been removed. It needs a proper redesign, but that is out of the scope of this thread ;-) I can't understand the point about removing enable/disable options. if we don't want to give the user the possibility to disable, we don't need an option to enable/disable. Let's turn the question around: why should the user be able to enable or disable compositing? What would be a valid reason to do so? And keep in mind: with Wayland it will be impossible to turn off compositing, same in GNOME Shell, Unity and Mac OS X (don't know about Windows). ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [RFC] Enforcing Compositing
Hi, On 02/20/11 22:25, Martin Gräßlin wrote: On Sunday 20 February 2011 22:18:16 Davide Bettio wrote: Hi, On 02/20/11 22:06, Martin Gräßlin wrote: I can't understand the point about removing enable/disable options. if we don't want to give the user the possibility to disable, we don't need an option to enable/disable. I don't see anything bad about having enable/disable options on the KCM. The only con that I'm aware of is that we have more checkboxes. Consider the button would not be there: would you see pro arguments to add one? Yes, currently at the computer lab in my university for an unknown reason I can't work with compositing enabled, so I had to disable it. The main reason is that buggy software is still around. And how do we get the buggy software fixed if we allow workarounds? We can't ask users to wait while the software gets fixed, they need to work so they may have to disable it while in the meantime someone is fixing the bug. Bye, Davide Bettio. signature.asc Description: OpenPGP digital signature ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [RFC] Enforcing Compositing
On Sunday 20 February 2011 22:00:58 Davide Bettio wrote: Hi, On 02/20/11 21:57, Martin Gräßlin wrote: No, while the KCM sucks it will still suck after those three options have been removed. It needs a proper redesign, but that is out of the scope of this thread ;-) I can't understand the point about removing enable/disable options. if we don't want to give the user the possibility to disable, we don't need an option to enable/disable. Let's turn the question around: why should the user be able to enable or disable compositing? What would be a valid reason to do so? And keep in mind: with Wayland it will be impossible to turn off compositing, same in GNOME Shell, Unity and Mac OS X (don't know about Windows). 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
Re: [RFC] Enforcing Compositing
On Sunday 20 February 2011 22:30:01 Beat Wolf wrote: Then leave it out during dev, but in when releasing. I wrote that in my initial mail about the config option. I just don't agree that for example nvidia will fix their drivers just because kde does not work with some, probably older cards. They actually fixed quite some bugs after the 4.1 release. Concerning older cards: KWin will continue to work if the driver does not support compositing. It's only about enforcing if the driver supports it. But i know that i can't win that debate. But i just know that such a decision will cause problems. We are lucky: we will see the results of GNOME Shell and Unity in April - enough time for us to adjust. Am Sonntag, 20. Februar 2011, um 22:19:53 schrieb Martin Gräßlin: On Sunday 20 February 2011 22:11:35 Beat Wolf wrote: On this computer, using the binary nvidia drivers, i could enable compositing. But due to some nvidia driver bugs, my computer becomes slugish very fast, which means compositing is not an option. i don't think that the x.org environment is stable enough to be able to remove a option that lets you work around bugs. bugs need to be fixed and not worked around. That is exactly one of the reasons why I want to have it disabled. It's just not an option that something like 4.5 happens ever again! We need to know problems during development and if devs tend to just turning of compositing it will happen again. Beat Wolf Am Sonntag, 20. Februar 2011, um 22:06:24 schrieb Martin Gräßlin: On Sunday 20 February 2011 22:00:58 Davide Bettio wrote: Hi, On 02/20/11 21:57, Martin Gräßlin wrote: No, while the KCM sucks it will still suck after those three options have been removed. It needs a proper redesign, but that is out of the scope of this thread ;-) I can't understand the point about removing enable/disable options. if we don't want to give the user the possibility to disable, we don't need an option to enable/disable. Let's turn the question around: why should the user be able to enable or disable compositing? What would be a valid reason to do so? And keep in mind: with Wayland it will be impossible to turn off compositing, same in GNOME Shell, Unity and Mac OS X (don't know about Windows). ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel 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
Re: [RFC] Enforcing Compositing
On Sunday 20 February 2011 22:50:01 Dario Freddi wrote: On Sunday 20 February 2011 13:38:40 Martin Gräßlin wrote: Hi all, sending this to both Plasma and KWin as the idea affects the complete workspace. Since 4.2 we have enabled OpenGL based compositing by default and I was wondering if in 4.7 we should go the next step: disabling the possibility to turn compositing off if supported. I think I agree with this, provided that KWin is smart enough to detect when compositing won't be supported. BTW, I think this implies I should trash the disable compositing action in powerdevil for 4.7, isn't it? (I would be glad to do that) I thought it was already trashed in 4.6 or was it just disabled by default? The correct answer to the question whether turning off compositing saves battery or not is probably: it depends. Personally I think that switching off compositing and all the stuff implied with it (Plasma rescaling SVGs, Oxygen adjusting...) is worse than keeping it on. 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. This would imply the following changes * Remove the enable checkbox in the compositing KCM * Remove the suspend/resume compositing button in the same KCM * Remove the functionality checks - the heuristic is rather useless anyway * Disable unredirect fullscreen windows by default I would keep * the shortcut to suspend compositing * the dbus call to toggle compositing (might be useful for games and so on) I am unsure about keeping respect to the Compositing/Enabled config option. I would say we do not honor it in development mode, but honor it again in the branch. This way users could still disable it if something goes bad. For development it's better to have the option not honored to get bugs reported ;-) If compositing is not supported, it will not try to enable it, so no problem for our old, old, old users. (Though I doubt Plasma is of any use in a system not supporting OpenGL). What do you think about this idea? 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
Re: [RFC] Enforcing Compositing
On Sun, Feb 20, 2011 at 4:40 PM, Martin Gräßlin mgraess...@kde.org wrote: On Sunday 20 February 2011 22:32:47 Davide Bettio wrote: Hi, On 02/20/11 22:25, Martin Gräßlin wrote: On Sunday 20 February 2011 22:18:16 Davide Bettio wrote: Hi, On 02/20/11 22:06, Martin Gräßlin wrote: I can't understand the point about removing enable/disable options. if we don't want to give the user the possibility to disable, we don't need an option to enable/disable. I don't see anything bad about having enable/disable options on the KCM. The only con that I'm aware of is that we have more checkboxes. Consider the button would not be there: would you see pro arguments to add one? Yes, currently at the computer lab in my university for an unknown reason I can't work with compositing enabled, so I had to disable it. does it have current drivers or is it completely outdated? I am talking about at least Mesa 7.10 which is current at the moment and till 4.7 there will be Mesa 7.11. The main reason is that buggy software is still around. And how do we get the buggy software fixed if we allow workarounds? We can't ask users to wait while the software gets fixed, they need to work so they may have to disable it while in the meantime someone is fixing the bug. As long as we don't expose the bugs they won't get fixed. What do you think would be the state of the drivers if there would not have been the 4.5 desaster? It seems every time someone brings up fixing things in xorg, people complain about how xorg isn't very responsive to complaints at least from KDE devs (they seemed to react very quickly when firefox had a problem). If xorg developers are not responsive to complaints from KDE devs, then I don't see how this is going to change anything. To put it another way, you seem to be portraying as a choice between people using a working xorg OR relying on a workaround. But is xorg really working reliably? All indications seem to be to the contrary. And if KDE forces users to use a broken system by removing workarounds, people are going to blame KDE. I can sort of understand not implementing new workarounds (although if KDE won't fix it and xorg won't fix it then all that does is hurt users). However, removing existing workarounds does not seem like a good idea given the history so far. -Todd ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [RFC] Enforcing Compositing
Am 20.02.2011, 22:06 Uhr, schrieb Martin Gräßlin mgraess...@kde.org: On Sunday 20 February 2011 22:00:58 Davide Bettio wrote: I can't understand the point about removing enable/disable options. if we don't want to give the user the possibility to disable, we don't need an option to enable/disable. we'll provide _some_ way to get rid of it - that doesn't have to be a regular setting, though. -- with Wayland it will be impossible to turn off compositing, same in GNOME Shell, Unity and Mac OS X (don't know about Windows). winblows: install the starter edition ;-p about wayland/osx/direct2d - one has to be fair and mention that those render stacks have been designed with compositing in mind, while we're currently taking an original CAD API + some conversion to provide compositing from a client side. that's not quite comparable :-) Anyway, there's few reason to not use compositing if your HW can do it - at least XRender is pretty lightweight (if you don't add fancy stuff like translucency etc.) It would oc be MCH better if we had direct access to (pot) client internal offscreen buffers =) Cheers, Thomas ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [RFC] Enforcing Compositing
- Ursprüngliche Mitteilung - On Sun, Feb 20, 2011 at 4:40 PM, Martin Gräßlin mgraess...@kde.org wrote: On Sunday 20 February 2011 22:32:47 Davide Bettio wrote: Hi, On 02/20/11 22:25, Martin Gräßlin wrote: On Sunday 20 February 2011 22:18:16 Davide Bettio wrote: Hi, On 02/20/11 22:06, Martin Gräßlin wrote: I can't understand the point about removing enable/disable options. if we don't want to give the user the possibility to disable, we don't need an option to enable/disable. I don't see anything bad about having enable/disable options on the KCM. The only con that I'm aware of is that we have more checkboxes. Consider the button would not be there: would you see pro arguments to add one? Yes, currently at the computer lab in my university for an unknown reason I can't work with compositing enabled, so I had to disable it. does it have current drivers or is it completely outdated? I am talking about at least Mesa 7.10 which is current at the moment and till 4.7 there will be Mesa 7.11. The main reason is that buggy software is still around. And how do we get the buggy software fixed if we allow workarounds? We can't ask users to wait while the software gets fixed, they need to work so they may have to disable it while in the meantime someone is fixing the bug. As long as we don't expose the bugs they won't get fixed. What do you think would be the state of the drivers if there would not have been the 4.5 desaster? It seems every time someone brings up fixing things in xorg, people complain about how xorg isn't very responsive to complaints at least from KDE devs (they seemed to react very quickly when firefox had a problem). If xorg developers are not responsive to complaints from KDE devs, then I don't see how this is going to change anything. But the whole ecosystem changed. With gnome shell and unity everybody requires compositing. To put it another way, you seem to be portraying as a choice between people using a working xorg OR relying on a workaround. But is xorg really working reliably? All indications seem to be to the contrary. And if KDE forces users to use a broken system by removing workarounds, people are going to blame KDE. I can sort of understand not implementing new workarounds (although if KDE won't fix it and xorg won't fix it then all that does is hurt users). However, removing existing workarounds does not seem like a good idea given the history so far. I don't want to remove the workaround, I only do not longer want to expose it in the UI. That's a big difference. And I really like Markus' idea with the None compositing backend. -Todd ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
