Re: [RFC] Enforcing Compositing
- Ursprüngliche Mitteilung - > 2011/2/20 Martin Gräßlin > > > 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. > > > My driver "supports" compositing, but the workspace becomes almost > unusably slow when it's enabled (Unichrome integrated GPU), but it runs > mostly fine otherwise. We do not enable opengl compositing on such cards by default. We only support nvidia, ati and intel. > > Check, at least, the FPS rate and disable compositing if it's < 30 FPS > average. Warning! Myth! Warning! More frames is not better. The best possible framerate for kwin is 0 frames per second. We only repaint if a window gets damaged. The fps effect is always showing incorrect results - you have to know how it works to be able to interpret the data correctly. > > > > > 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 > > > > ___ > > Plasma-devel mailing list > > Plasma-devel@kde.org > > https://mail.kde.org/mailman/listinfo/plasma-devel > > > > > > > -- > Luiz Romário Santana Rios ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [RFC] Enforcing Compositing
2011/2/20 Martin Gräßlin > 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. > My driver "supports" compositing, but the workspace becomes almost unusably slow when it's enabled (Unichrome integrated GPU), but it runs mostly fine otherwise. Check, at least, the FPS rate and disable compositing if it's < 30 FPS average. > > 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 > > ___ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel > > -- Luiz Romário Santana Rios ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [RFC] Enforcing Compositing
On Monday 21 February 2011 22:11:23 Aaron J. Seigo wrote: > On Sunday, February 20, 2011, Martin Gräßlin wrote: > > What do you think about this idea? > > first, thumbs up for daring to ask the Big Questions. it's something i > appreciate in you as a developer :) > > so ...personally, i'm ok with re-thinking the options in the kcm GUI, but i > feel that it is a very bad time to try and make it depend on opengl with no > way for the user to turn it off because: yes I think the majority was for not changing ;-) > > what might make for an interesting "could it be done?", and i don't know if > it could be in kwin, is taking all the non-composited code and moving it > out of kwin core as a compile time option. this would at least allow > devices using kwin to avoid whatever code overhead would be incurred. i'd > even go so far as to remove the auto-disable functionality in those cases, > since the harware is 100% known. Part of it is done, part of it can be done, most of it cannot be done. * OpenGL 1 code is ifdefed if compiled against GLES * XRender Code could be disabled and is disabled if XRender is not found * Core is mostly too strongly coupled to disable functionality. At the moment I think only Tabbox could be disabled at compile time. As mentioned some time ago I would like to have core more modularized which would allow to cherry-pick the features wanted at compile 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
On Sunday, February 20, 2011, Martin Gräßlin wrote: > What do you think about this idea? first, thumbs up for daring to ask the Big Questions. it's something i appreciate in you as a developer :) so ...personally, i'm ok with re-thinking the options in the kcm GUI, but i feel that it is a very bad time to try and make it depend on opengl with no way for the user to turn it off because: * some of our larger deployments (edu, corp) rely on being able to turn such things off * it's a unique feature over the others, who are making this move but mostly because they don't already have something that works * our users will scream and it will cost us momre users; without real upside to this, it won't win us any users only lose some * fwiw, depending on the phase of the moon the developers are living under, the intel driver still goes through it's ... moments of despair. if i hadn't been able to turn off effects in kwin, i'd have been in some very, very bad places over the last 2 years if we didn't already have the code there which works, i'd consider this differently perhaps. i assume that's why gnome-shell and unity are as well: they are starting from scratch, how much manpower do they really have? for mac, it's much easier: they control the hardware and the drivers, too. (and don't have the same kinds of deployments to support that we do?) but we have code that works. we have people using, even relying on, those code paths. for me, that makes it a "-1". i think the day will come where we will be able to do this, but we're not there yet. legacy is a bitch, x.org is still a wanker more often than we want it to be (and replacements are not there yet, try as people might to make wayland sound like the messiah arrived in the flesh today), but that's our lot in life right now. i think it would be a strategic and promotional error to make this change right now. even if i utterly hate having to manage multiple code paths in plasma :) what might make for an interesting "could it be done?", and i don't know if it could be in kwin, is taking all the non-composited code and moving it out of kwin core as a compile time option. this would at least allow devices using kwin to avoid whatever code overhead would be incurred. i'd even go so far as to remove the auto-disable functionality in those cases, since the harware is 100% known. p.s. not on the kwin list, though perhaps i ought to be. please cc plasma- devel if you reply :) cheers. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks 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: (Mockup) Re: [RFC] Enforcing Compositing
On Monday 21 February 2011 20:51:40 you wrote: > A Segunda, 21 de Fevereiro de 2011 18:55:25 Martin Gräßlin você escreveu: > > On Monday 21 February 2011 12:55:48 Markus Slopianka wrote: > > > Am Montag 21 Februar 2011, 07:24:33 schrieb Martin Gräßlin: > > > > 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. > > > > > > I took a few minutes of time to squeeze out a mockup: > > > http://kamikazow.files.wordpress.com/2011/02/kwin-mockup.png > > > > Only one comment: disabling all effects does not make sense ;-) > > > > > To my own surprise it reduces clutter to a greater degree than I > > > thought it would while also not losing any features. > > > > > > As a side note: In the "All effects" tab the categories are sorted > > > alphabetically. While in theory that sounds good, seeing "Tools" above > > > "Window Management" makes no sense. "Tools" is probably no used by > > > anyone besides a handful of people who develop KWin and benchmarking > > > geeks. > > > > The all effects tab is IMHO completely useless. With more than 40 effects > > with hardly any grouping. We need a different solution here > > what we need is sane bewtiful and probably exculsive (exclusiv as made by > us) defoults and efects the type of person brave enough to look at a > efects list dosent mind a miriad of options we should remember allyas > that most people don't chage defoults As a global experience impact we > can achive much better results by providing a more unified experience as > defoults go, than by trying to create better configure U's :) > > #note im not sayin we should not improve the UI but... i would be muuch > happier to have a coherent set of efects that are part of the experience, > and not random bits of eye candy. it's orthogonal. We need both. We need a better set of default effects and a better UI. > > > > I'd also merge a few effect entries that are mutually exclusive: There > > > are at least two Minimize effects which could be merged into one entry > > > with "Normal" or "Genie" as radio buttons in the effect's config > > > window. Same for closing windows, magnification lens, etc. > > > > Agreed, this is something the current selection does not allow. If you > > want to work on a concept for a new solution that would be highly > > appreciated. > > > > Cheers > > Martin > > oxygen guy, "I make the pretty pictures" 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: (Mockup) Re: [RFC] Enforcing Compositing
A Segunda, 21 de Fevereiro de 2011 18:55:25 Martin Gräßlin você escreveu: > On Monday 21 February 2011 12:55:48 Markus Slopianka wrote: > > Am Montag 21 Februar 2011, 07:24:33 schrieb Martin Gräßlin: > > > 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. > > > > I took a few minutes of time to squeeze out a mockup: > > http://kamikazow.files.wordpress.com/2011/02/kwin-mockup.png > > Only one comment: disabling all effects does not make sense ;-) > > > To my own surprise it reduces clutter to a greater degree than I thought > > it would while also not losing any features. > > > > As a side note: In the "All effects" tab the categories are sorted > > alphabetically. While in theory that sounds good, seeing "Tools" above > > "Window Management" makes no sense. "Tools" is probably no used by anyone > > besides a handful of people who develop KWin and benchmarking geeks. > > The all effects tab is IMHO completely useless. With more than 40 effects > with hardly any grouping. We need a different solution here what we need is sane bewtiful and probably exculsive (exclusiv as made by us) defoults and efects the type of person brave enough to look at a efects list dosent mind a miriad of options we should remember allyas that most people don't chage defoults As a global experience impact we can achive much better results by providing a more unified experience as defoults go, than by trying to create better configure U's :) #note im not sayin we should not improve the UI but... i would be muuch happier to have a coherent set of efects that are part of the experience, and not random bits of eye candy. > > I'd also merge a few effect entries that are mutually exclusive: There > > are at least two Minimize effects which could be merged into one entry > > with "Normal" or "Genie" as radio buttons in the effect's config window. > > Same for closing windows, magnification lens, etc. > > Agreed, this is something the current selection does not allow. If you want > to work on a concept for a new solution that would be highly appreciated. > > Cheers > Martin oxygen guy, "I make the pretty pictures" ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [RFC] Enforcing Compositing
On Monday 21 February 2011 20:25:23 todd rme wrote: > On Mon, Feb 21, 2011 at 11:35 AM, Martin Gräßlin wrote: > > * improve situation with X devs - in whatever possible way (input > > welcome) > > > > Thanks all > > Martin > > If I am understanding what I am hearing correctly, kwin, gnome 3 > shell, unity, and to a lesser extent firefox are all doing basically > the same thing, and are therefore going to run into the same problems. > If that is the case, what about doing one, or both, of these: actually no, * Compiz is still mostly OpenGL 1.x code, even after the port to GLES, it's mostly wrapping the OpenGL 1.x code into a 2.x API. * GNOME Shell is using Clutter, a scenegraph. That's like if we would try to build kwin on top Qt Components * Firefox is doing WebGL, they expose the complete API of GLES to any application and are very concerned about stability (possible security vulnerabilities). KWin only uses a very small part of the GLES API. The KWin code is closest to Compiz, especially as they at least wanted to reuse our GLES shaders. I have not yet looked at their implementation, but I really hope they are using them or that we can merge them. > > 1. A joint meeting, or at least communication, involving these groups > (and probably compiz as well) btw Unity == Compiz > to try to unify approaches, so everyone > is doing more or less the same things in the same ways. OpenGL is too complex for that. There are (to my knowledge) five different ways to specifiy geometries. KWin uses three of them (OpenGL 1, OpenGL 2 without shaders, OpenGL 2 with shader) and at one place (logout effect) the forth one (which needs to be removed). If I get around to add OpenGL 3 support we will also use the fifth version (Geometry shaders). OpenGL is also a state machine. It's really difficult to track the state correctly - that's why projects like Gallium have been started. Trying to get our code in the same way is just impossible. Setting the states in a different order might change the world. What we can do is reduce the API usage and that's what we did. One of the reasons why I started with GLES is to get the codebase to use only a subset of the API. Now with Compiz also porting to GLES and Firefox requiring GLES and Gallium3D providing a common state tracker there is the hope that GLES gets more pushed and improved. > That would > mean that if there is a problem with xorg, it should effect everyone. > > 2. Get together and communicate with xorg devs as a group, rather than > isolated projects. As I mentioned, problems with firefox seemed to > get instant attention, while problems with KDE seemed to be ignored or > blamed on KDE (even though they were the exact same problems). So > teaming up with developers who have more traction may get better > results. Mozilla is mostly concerned about stability and has raised some rather "strange" requests to mesa. Our implementations are so different that we cannot demand anything together except trying to beat on the devs, which I would not want to do ;-) 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 Mon, Feb 21, 2011 at 11:35 AM, Martin Gräßlin wrote: > * improve situation with X devs - in whatever possible way (input welcome) > > Thanks all > Martin If I am understanding what I am hearing correctly, kwin, gnome 3 shell, unity, and to a lesser extent firefox are all doing basically the same thing, and are therefore going to run into the same problems. If that is the case, what about doing one, or both, of these: 1. A joint meeting, or at least communication, involving these groups (and probably compiz as well) to try to unify approaches, so everyone is doing more or less the same things in the same ways. That would mean that if there is a problem with xorg, it should effect everyone. 2. Get together and communicate with xorg devs as a group, rather than isolated projects. As I mentioned, problems with firefox seemed to get instant attention, while problems with KDE seemed to be ignored or blamed on KDE (even though they were the exact same problems). So teaming up with developers who have more traction may get better results. -Todd ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: (Mockup) Re: [RFC] Enforcing Compositing
On Monday 21 February 2011 12:55:48 Markus Slopianka wrote: > Am Montag 21 Februar 2011, 07:24:33 schrieb Martin Gräßlin: > > 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. > > I took a few minutes of time to squeeze out a mockup: > http://kamikazow.files.wordpress.com/2011/02/kwin-mockup.png Only one comment: disabling all effects does not make sense ;-) > > To my own surprise it reduces clutter to a greater degree than I thought it > would while also not losing any features. > > As a side note: In the "All effects" tab the categories are sorted > alphabetically. While in theory that sounds good, seeing "Tools" above > "Window Management" makes no sense. "Tools" is probably no used by anyone > besides a handful of people who develop KWin and benchmarking geeks. The all effects tab is IMHO completely useless. With more than 40 effects with hardly any grouping. We need a different solution here > > I'd also merge a few effect entries that are mutually exclusive: There are > at least two Minimize effects which could be merged into one entry with > "Normal" or "Genie" as radio buttons in the effect's config window. > Same for closing windows, magnification lens, etc. Agreed, this is something the current selection does not allow. If you want to work on a concept for a new solution that would be highly appreciated. 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 Monday 21 February 2011 12:23:36 Sebastian Kügler wrote:
> Hey all,
>
>
> - let's try it in unreleased master for a bit
> - let's see how Unity and GNOME shell are received
> - let's try to improve communication with Xorg devs
> - let's target it for 4.8
>
Thanks all for the feedback, it helped a lot.
So what we see is that the majority fears future driver regressions which is
completely out of our control. Because of that we cannot enforce compositing.
So I would propose the following action items:
* do not change GUI as a complete rework is required
* target new GUI for 4.8 (don't think it's possible to get it done for 4.7).
Therefore collect also input from Usability team.
* adjust code to enforce compositing in master - disable this before beta
tagging
* improve situation with X devs - in whatever possible way (input welcome)
Thanks all
Martin
>
> On Sunday, February 20, 2011 15:38:22 Martin Gräßlin wrote:
> > 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?
>
> While I sympathize with the "compositing only" idea, I've got a couple of
> concerns:
>
> - What about remote clients? Will the just get a non-composited desktop?
>
> - Some drivers support Compositing just fine, but make the machine feel
> laggy, we've had this problem with NVidia for quite some time, and I still
> sense it on my Intel w/ openSUSE 11.3 sometimes. Switching off compositing
> makes it faster
>
> - Regressions: To users that don't have a good graphics driver and hw
> combo, it'll just look like a regression ("Plasma doesn't work anymore"),
> that's not what we should do to our users.
>
> - Crap graphics drivers
>
> In my humble opinion, it would be wrong to make this change for 4.7. Let's
> first get Unity and GNOME shell in the hands of the users, and try to find
> out if it's really not a problem, if it is, we'll save some users some
> grey hair, and we offer a real alternative to those burned by GNOME shell
> or Unity instead of repeating their mistakes. If it works out, nothing's
> lost when we go this route for 4.8 (other than keeping a UI option in
> there for one more cycle -- a small price to pay).
> Instead of breaking existing users' setups (those with crap graphic
> drivers), let's for *once* not be the guys taking the beating by being
> among the first, let us support those that are not willing to go through
> any level of pain, and who don't care about compositing or not (those are
> quite a few is my experience).
>
> Furthermore, I think the "let's just expose X driver problems, then they'll
> get fixed faster" is a bit too optimistic as long as we keep failing to
> structurally communicate with those (few left) driver developers. In
> reality, it takes too long to get an issue fixed, and that's partly our
> fault. The solution here is not to enforce compositing, but to work on our
> communication with Xorg developers, and make it easy for them to
> straighten out the stack so KWin and Plasma run well. I've talked with
> some Xorg driver developers in the past months, and they're pretty much
> completely unaware of KWin's problems with compositing. They don't have
> the info about that available. We should probably not expect that driver
> developers test KWin. :/
>
> Martin also offered the possibility to remove this feature in our
> development version for a while, and see what happens. I think it would be
> wrong to switch of back on only after branching, but "breaking" it for two
> months should be fine, and offer plenty of feedback.
>
> Cheers,
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
A Segunda, 21 de Fevereiro de 2011 13:26:12 Sebastian Kügler você escreveu: > On Monday, February 21, 2011 14:05:59 Nuno Pinheiro wrote: > > A Segunda, 21 de Fevereiro de 2011 11:23:36 Sebastian Kügler você escreveu: > > > > > > - let's try it in unreleased master for a bit > > > - let's see how Unity and GNOME shell are received > > > - let's try to improve communication with Xorg devs > > > - let's target it for 4.8 > > > > > > > wille I agrea with the sumary, I want to SUPORT what Martin is trying to > > do here.. > > Contrary to what many people belive this is not mostly about eye candy. > > We realy need sooner or later to have a fully composite desktop with no > > strings atached... the number of visual solutions for our clutered > > desktop aplications is amazing if we have a trusted to exyst composite > > desktopFor to long have we been stuck with static (xi, yi) > > windows We need more abstraction betwinf frorm and function, this > > will be vital for the brave new UI world that is forming in the mist. > > > > I repeat this is not about eye candy this is about more natural less > > "explicit information" saturated UI's > > I fully agree with you, however: > > - the stack is not ready for it yet > - enforcing compositing is not going to change that > - it's bad timing, let others try it first > > -> enforcing compositing would be the wrong solution to the problem at this > point. yes yes :) i started by saying yes :) we agrea as usual... just trying to make its clear that Martin work is realy realy realy valued :) some times we tend to get stuck on the reasons how come we don't do somthing, and as a result give up on the problems, persistence like Martin shows is probaly more important than the problems and I just wanted to say that to him :D -- oxygen guy, "I make the pretty pictures" ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: (Mockup) Re: [RFC] Enforcing Compositing
Am Montag 21 Februar 2011, 14:24:42 schrieb Sebastian Kügler: > I agree with Martin that the KWin KCMs could use a major redesign, > shuffling options around is not enough and leads to confusion among users > short-term, without tackling the real problem long term. My side note was not the main point of my mail. If it was, it would've been a mail outside this thread. Martin wanted to remove the GUI option to deactivate compositing completely. I suggested to move it to Advanced and he said he likes the idea. Now I made a mockup to see myself (and show others) how it would look. And I feel wholeheartedly that the result not only meets Martin's requirements, it also increases usability. How often do you get that in a compromise? Maybe I do a mockup of a full-blown redesign soon. I can't promise anything, though. Markus ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [RFC] Enforcing Compositing
On Monday, February 21, 2011 14:05:59 Nuno Pinheiro wrote: > A Segunda, 21 de Fevereiro de 2011 11:23:36 Sebastian Kügler você escreveu: > > > > - let's try it in unreleased master for a bit > > - let's see how Unity and GNOME shell are received > > - let's try to improve communication with Xorg devs > > - let's target it for 4.8 > > > > wille I agrea with the sumary, I want to SUPORT what Martin is trying to do > here.. > Contrary to what many people belive this is not mostly about eye candy. We > realy need sooner or later to have a fully composite desktop with no > strings atached... the number of visual solutions for our clutered desktop > aplications is amazing if we have a trusted to exyst composite > desktopFor to long have we been stuck with static (xi, yi) windows > We need more abstraction betwinf frorm and function, this will be vital > for the brave new UI world that is forming in the mist. > > I repeat this is not about eye candy this is about more natural less > "explicit information" saturated UI's I fully agree with you, however: - the stack is not ready for it yet - enforcing compositing is not going to change that - it's bad timing, let others try it first -> enforcing compositing would be the wrong solution to the problem at this point. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: (Mockup) Re: [RFC] Enforcing Compositing
On Monday, February 21, 2011 12:55:48 Markus Slopianka wrote: > Am Montag 21 Februar 2011, 07:24:33 schrieb Martin Gräßlin: > > 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. > > I took a few minutes of time to squeeze out a mockup: > http://kamikazow.files.wordpress.com/2011/02/kwin-mockup.png > > To my own surprise it reduces clutter to a greater degree than I thought it > would while also not losing any features. > > As a side note: In the "All effects" tab the categories are sorted > alphabetically. While in theory that sounds good, seeing "Tools" above > "Window Management" makes no sense. "Tools" is probably no used by anyone > besides a handful of people who develop KWin and benchmarking geeks. > > I'd also merge a few effect entries that are mutually exclusive: There are > at least two Minimize effects which could be merged into one entry with > "Normal" or "Genie" as radio buttons in the effect's config window. > Same for closing windows, magnification lens, etc. I agree with Martin that the KWin KCMs could use a major redesign, shuffling options around is not enough and leads to confusion among users short-term, without tackling the real problem long term. For one, the pages widget and tab widgets bring a second navigational level (choose right page, then choose the right tab), which is really quite broken. That should be tackled, rather than shuffling options. Furthermore, this is not a UI design issue, don't make it one. (We can work on that later when there's consensus about the way forward.) Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [RFC] Enforcing Compositing
A Segunda, 21 de Fevereiro de 2011 11:23:36 Sebastian Kügler você escreveu: > Hey all, > > > - let's try it in unreleased master for a bit > - let's see how Unity and GNOME shell are received > - let's try to improve communication with Xorg devs > - let's target it for 4.8 > wille I agrea with the sumary, I want to SUPORT what Martin is trying to do here.. Contrary to what many people belive this is not mostly about eye candy. We realy need sooner or later to have a fully composite desktop with no strings atached... the number of visual solutions for our clutered desktop aplications is amazing if we have a trusted to exyst composite desktopFor to long have we been stuck with static (xi, yi) windows We need more abstraction betwinf frorm and function, this will be vital for the brave new UI world that is forming in the mist. I repeat this is not about eye candy this is about more natural less "explicit information" saturated UI's oxygen guy, "I make the pretty pictures" ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
(Mockup) Re: [RFC] Enforcing Compositing
Am Montag 21 Februar 2011, 07:24:33 schrieb Martin Gräßlin: > 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. I took a few minutes of time to squeeze out a mockup: http://kamikazow.files.wordpress.com/2011/02/kwin-mockup.png To my own surprise it reduces clutter to a greater degree than I thought it would while also not losing any features. As a side note: In the "All effects" tab the categories are sorted alphabetically. While in theory that sounds good, seeing "Tools" above "Window Management" makes no sense. "Tools" is probably no used by anyone besides a handful of people who develop KWin and benchmarking geeks. I'd also merge a few effect entries that are mutually exclusive: There are at least two Minimize effects which could be merged into one entry with "Normal" or "Genie" as radio buttons in the effect's config window. Same for closing windows, magnification lens, etc. Bye. Markus ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [GSOC] Home automation
On Monday 21 February 2011, Marsollier Robin wrote: > Le samedi 19 février 2011 19:51:06, Marco Martin a écrit : > > ok, so all the actual backend stuff is almost there from what i gather? > > what you would do is basically a set of ui bits that display > > informations/control devices exposed by such server. > > Yes, exactly, a set of plasmoid to supervision and control tools for home, > with notification if needed, a way to ajust advanced parameters (a window > with plasma kpart for more flexibility?), perhaps with an abstraction > layer for help future implementation of other automation server. > I had not thought about it but integration with PMC will be necessary, I the point is that those control plasmoid can be put everywhere, as desktop widgets, in a kpart of an application, as "mobile apps", as fullscreen control thinghies in the mediacenter. what whould eventually change of that plasmoid in being shown on a desktop or on a mediacenter (or on a tablet, or on a toaster) is the user interface, and that's one of the big points of the qml plasmoids, being able to load different ui qml files depending on the shell they are running on. as the abstraction layer, i think different plugins for the same dataengine/services could be the way to go. Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [RFC] Enforcing Compositing
On Monday 21 February 2011, Sebastian Kügler wrote:
> Hey all,
>
>
> - let's try it in unreleased master for a bit
> - let's see how Unity and GNOME shell are received
> - let's try to improve communication with Xorg devs
> - let's target it for 4.8
>
i kept myself quite away from this but yeah, i agree with the exec summary
> On Sunday, February 20, 2011 15:38:22 Martin Gräßlin wrote:
> > 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?
>
> While I sympathize with the "compositing only" idea, I've got a couple of
> concerns:
>
> - What about remote clients? Will the just get a non-composited desktop?
if they are remote applications running on a local x server, compositing would
depend from what is supported on the local x server (just not sure about argb
windows, do they work over network?)
> - Some drivers support Compositing just fine, but make the machine feel
> laggy, we've had this problem with NVidia for quite some time, and I still
> sense it on my Intel w/ openSUSE 11.3 sometimes. Switching off compositing
> makes it faster
>
> - Regressions: To users that don't have a good graphics driver and hw
> combo, it'll just look like a regression ("Plasma doesn't work anymore"),
> that's not what we should do to our users.
>
> - Crap graphics drivers
yes, this is still an issue, ridiculous in 2011 but it's still there.
however, if -all- mayor desktops start to require this, something could be
pushed enough to change
> In my humble opinion, it would be wrong to make this change for 4.7. Let's
> first get Unity and GNOME shell in the hands of the users, and try to find
> out if it's really not a problem, if it is, we'll save some users some
> grey hair, and we offer a real alternative to those burned by GNOME shell
> or Unity instead of repeating their mistakes. If it works out, nothing's
> lost when we go this route for 4.8 (other than keeping a UI option in
> there for one more cycle -- a small price to pay).
yes, i would let this for 4.8 as well.
> Furthermore, I think the "let's just expose X driver problems, then they'll
> get fixed faster" is a bit too optimistic as long as we keep failing to
> structurally communicate with those (few left) driver developers. In
again, too soon now, but in a year from now there could be no way to avoid of
x problems getting exposed (if one doesn't want to use xvwm for ever ;)
> reality, it takes too long to get an issue fixed, and that's partly our
> fault. The solution here is not to enforce compositing, but to work on our
> communication with Xorg developers, and make it easy for them to
> straighten out the stack so KWin and Plasma run well. I've talked with
> some Xorg driver developers in the past months, and they're pretty much
> completely unaware of KWin's problems with compositing. They don't have
> the info about that available. We should probably not expect that driver
> developers test KWin. :/
we for sure have to communicate more with them, it's true as well that testing
their changes at least with major window managers (and no, doesn't matter if
they don't normally use, or hate them) should be part of their job,really
(really, it's easier for them getting our software than for us get peces of
all the graphics hardware existing on earth)
i don't know how a better communication channel can be put up, i guess as
usual it's a matter of resources, and with the complexity stuff reached
lately, it's really starting to show and badly, but this is another whole new
rant ;)
Cheers,
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [GSOC] Home automation
Le samedi 19 février 2011 19:51:06, Marco Martin a écrit : > ok, so all the actual backend stuff is almost there from what i gather? > what you would do is basically a set of ui bits that display > informations/control devices exposed by such server. Yes, exactly, a set of plasmoid to supervision and control tools for home, with notification if needed, a way to ajust advanced parameters (a window with plasma kpart for more flexibility?), perhaps with an abstraction layer for help future implementation of other automation server. I had not thought about it but integration with PMC will be necessary, I don't know how because there are some point to consider (more than you all have exposed in the little debate about it ;) ) and I think I don't have sufficient knowledge for the moment to even know all points. This will need some discuss. > I think Plasa would be quite perfect for an user interface of such a > project (just quickly thinking about it, dataengines, remote widgets, qml > plasmoids seem exactly the perfect match) > I think so, I only have a users point of view for the moment, but plasma seems so perfect and flexible to do it :) > looking forward to it :) I'll join you tomorrow afternoon or evening. > on the parts that are most in the backend stuff, and for testing with > actual hardware i fear you would be a bit on your own (but you seem to be > already expert of it ;)) for all the ui work, how to do a plasma shell > around it, we will be very happy to help Yes, I am aware about it, in my original idea, I wanted to work on domogik but because I can't test anything in real condition with hardware, I could only work on the web interface (which is very advanced actually). So I decided to attempt to work on another point that I consider as a lack currently, integration in desktop. So I hope Domogik can be hack to trigger some event and other stuff, but I think so. I'm happy that my idea have been welcomed. I'll add it quickly on the page of ideas for GSOC. -- Cordialement Robin Marsollier M1 Électronique et Télécommunication - Université de Rennes 1 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [RFC] Enforcing Compositing
On Sunday 20 of February 2011, Martin Gräßlin wrote: > Let's turn the question around: why should the user be able to enable or > disable compositing? Since, as experience shows, compositing is nowhere near a perfect world? > What would be a valid reason to do so? - Intel releases a new driver that "technically" works fine but causes visual glitches. - User is running on batteries and really likes those 10 bonus minutes more than compositing. Let's turn the question around once more: Why shouldn't the user be able to disable compositing? As you said in your first mail, compositing should be enforced only if supported, so non-composited mode needs to be supported too anyway. The benefit of removing a checkbox seems far too small compared to all the potential trouble. > 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). Well, that could be a nice selling point of KWin for all those disappointed GNOME Shell users, wouldn't it? -- Lubos Lunak l.lu...@suse.cz ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [RFC] Enforcing Compositing
Hey all,
- let's try it in unreleased master for a bit
- let's see how Unity and GNOME shell are received
- let's try to improve communication with Xorg devs
- let's target it for 4.8
On Sunday, February 20, 2011 15:38:22 Martin Gräßlin wrote:
> 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?
While I sympathize with the "compositing only" idea, I've got a couple of
concerns:
- What about remote clients? Will the just get a non-composited desktop?
- Some drivers support Compositing just fine, but make the machine feel laggy,
we've had this problem with NVidia for quite some time, and I still sense it
on my Intel w/ openSUSE 11.3 sometimes. Switching off compositing makes it
faster
- Regressions: To users that don't have a good graphics driver and hw combo,
it'll just look like a regression ("Plasma doesn't work anymore"), that's not
what we should do to our users.
- Crap graphics drivers
In my humble opinion, it would be wrong to make this change for 4.7. Let's
first get Unity and GNOME shell in the hands of the users, and try to find out
if it's really not a problem, if it is, we'll save some users some grey hair,
and we offer a real alternative to those burned by GNOME shell or Unity
instead of repeating their mistakes. If it works out, nothing's lost when we
go this route for 4.8 (other than keeping a UI option in there for one more
cycle -- a small price to pay).
Instead of breaking existing users' setups (those with crap graphic drivers),
let's for *once* not be the guys taking the beating by being among the first,
let us support those that are not willing to go through any level of pain, and
who don't care about compositing or not (those are quite a few is my
experience).
Furthermore, I think the "let's just expose X driver problems, then they'll
get fixed faster" is a bit too optimistic as long as we keep failing to
structurally communicate with those (few left) driver developers. In reality,
it takes too long to get an issue fixed, and that's partly our fault. The
solution here is not to enforce compositing, but to work on our communication
with Xorg developers, and make it easy for them to straighten out the stack so
KWin and Plasma run well. I've talked with some Xorg driver developers in the
past months, and they're pretty much completely unaware of KWin's problems
with compositing. They don't have the info about that available. We should
probably not expect that driver developers test KWin. :/
Martin also offered the possibility to remove this feature in our development
version for a while, and see what happens. I think it would be wrong to switch
of back on only after branching, but "breaking" it for two months should be
fine, and offer plenty of feedback.
Cheers,
--
sebas
http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
