On Wed, 6 Mar 2013 13:44:33 -0300 Rafael Antognolli <antogno...@gmail.com> said:
> On Wed, Mar 6, 2013 at 11:55 AM, Carsten Haitzler <ras...@rasterman.com> > wrote: > > On Thu, 28 Feb 2013 16:22:34 -0300 Rafael Antognolli <antogno...@gmail.com> > > said: > > > >> tl;dr: > >> > >> To have a sub-ecore_evas inside the wayland ecore_evas. The > >> sub-ecore_evas would handle the client area content, while the > >> ecore_evas (external one) would handle the rendering of the window > >> decorations. > > > > not a fan of this idea. > > OK, any specific points or reasons why you don't like it? 1. makes wayland "special and different" at the evas level. like its a special canvas handle entirely. the current framespace stuff could easily be done in x11 too - client-side decorations can work in x11 just as well. 2. you now draw the child ecore-evas to a buffer, take that and draw into the parent frame ecore-evas. you have just slowed rendering down considerably by adding an extra buffer copy. this alone is a veto reason 3. this sub evas then doesn't give the ability/option to stack/overlap frame above window content if you want as you can't actually now control that stacking with objects/swallows etc. 4. even if you dont use a separate buffer of some sort for the child ecore-evas, you now have to make 1 evas draw direct to the window/content of another and this is going to be highly bad for things like gl. and again... it doesnt support things like choosing stacking of the frame above and./or below the content. 6. who does the swapbuffers then eh? (for gl). and for shm/software.. who sends the buffer to the compositor? u have to interrupt the parent evas rendering before its complete to make this happen and you have to do it for 2 engines... :) > >> How it should work: > >> ================== > >> > >> Once one asks for a wayland ecore evas (ecore_evas_wayland_shm_new, > >> for example), the external ecore evas would be created, with > >> additional space for the window decorations (here called frame). After > >> being created, a new ecore evas, the sub ecore evas, would be created > >> with its drawing contexted being smaller and having an offset relative > >> to the frame. The Evas of this sub ecore evas would now know about the > >> external area of the frame at all. > >> > >> The Ecore_Evas pointer returned by the ecore_evas_wayland_shm_new > >> function would be the one from the sub ecore evas, so any application > >> would use it without any need for special handling. There would be an > >> API available for returning the external/parent ecore evas of this > >> one, since the objects used for rendering the window decorations would > >> be added to this external Evas. > >> > >> Any API for resize, move, etc., of the returned ecore evas would have > >> to actually be applied first to the external ecore evas, and then have > >> the internal one adjusted. > >> > >> The external ecore evas would be always created first, with the > >> required surfaces allocated and so, and then the sub ecore evas would > >> need to have its drawing context pointed to a smaller area of this > >> allocated surface. > >> > >> Benefits: > >> ======== > >> > >> There would be no more need to keep wayland specific code for handling > >> the framespace inside evas render code, evas objects code, etc. > >> Everything would be done inside the Ecore_Evas wayland backend. > >> > >> Most problems related to this framespace code would be fixed, since > >> every evas object would not need to be shifted by the framespace > >> offset anymore, and there would be no clipper objects, etc. > >> > >> Concerns: > >> ======== > >> > >> I'm just worried right now if will there be any problem when handling > >> mouse events or if it's possible to adjust the drawing context as I > >> proposed above, in order to make a given Ecore_Evas to only know about > >> a sub-area of a given surface allocated by its parent Ecore_Evas. > >> > >> > >> So, do you guys have any comments, advices, know of things that > >> probably won't work, etc? > >> > >> Thanks for any feedback, > >> -- > >> Rafael Antognolli > >> http://antognolli.org/ > >> > >> ------------------------------------------------------------------------------ > >> Everyone hates slow websites. So do we. > >> Make your web apps faster with AppDynamics > >> Download AppDynamics Lite for free today: > >> http://p.sf.net/sfu/appdyn_d2d_feb > >> _______________________________________________ > >> enlightenment-devel mailing list > >> enlightenment-devel@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > >> > > > > > > -- > > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > > The Rasterman (Carsten Haitzler) ras...@rasterman.com > > > > > > -- > Rafael Antognolli > http://antognolli.org/ > > ------------------------------------------------------------------------------ > Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester > Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the > endpoint security space. For insight on selecting the right partner to > tackle endpoint security challenges, access the full report. > http://p.sf.net/sfu/symantec-dev2dev > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
