On 10/27/2016 10:28 PM, Carsten Haitzler wrote: > so some thoughts: > > 1. wayland is client-side decoration land. let's not argue csd vs ssd (server > side decorations ala traditional x11). one way or another csd is where things > are going and there are good reasons for it being better in many ways. in the > spirit of csd we likely will do what gnome does and use csd on x11 too. it can > be done and thus makes wl themes/display and window layout and features the > same as x11. ultimately this can apply to windows and osx too. >
As this is the direction that things are going anyway, I think it's a good idea. Server side decorations conflict with wayland principles of client-side decorations, and ultimately (imo) only serve to complicate matters. While the theory of Server side decorations in Wayland was an interesting one, it does not have any real traction in the other toolkit camps (afaik) and I don't believe that any other compositor is implementing them either, so this I agree with. > 2. given this direction we could be even more crazy and display like wayland > by > keeping a set of pixmaps we render to and "sending" the pixmaps to the > compositor rather than doing the std x11 composite way. only for efl apps but > this should also fix bugs like junk content when you resize a window until > client catches up. this borrows wl's solution for this into x11. the sw engine > could switch easily. gl would need a little work, BUT with gl now we don't > need > buffer age for partial rendering. hooray! this would also help us unify api's, > display paths and code paths between x11 and wayland too at this lower level. > yes - it needs compositor support which means we still need the alternate path > anyway... but this path could be more optimal... :) > > 3. xcb was a valiant effort, but it is not even 1:1 feature for feature up to > date with xlib. it's off by default because of this and we need xlib for gl > anyway. we cant dump xlib. it's just a lot of code in our tree that we likely > could remove to clear out some "cruft". not to say work on xcb has been bad. > it's been good. :) it's a very very large amount of useful code but it just has > never proven to be any real big gains and lack of full featured implementation > (it's 98% there) means it kind of isn't useful. so how about we drop it to > simplify? > Given that work on xcb itself seems to have stalled (meaning I've not seen any efforts for it to get feature parity with xlib), I would say removing it would be the way to go. While I am partial to the xcb code (being the one who implemented it), having it in the codebase and not being used is just pointless, and as you've stated we still need xlib to handle gl in there anyway so may as well just stick with xlib. Cheers, dh > thoughts? (#1 likely will happen anyway, #3 is easy and we lose nothing, #2 is > still in the process of being through out). > ------------------------------------------------------------------------------ The Command Line: Reinvented for Modern Developers Did the resurgence of CLI tooling catch you by surprise? Reconnect with the command line and become more productive. Learn the new .NET and ASP.NET CLI. Get your free copy! http://sdm.link/telerik _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
