On Thu, 7 Mar 2013 14:16:00 -0300 Rafael Antognolli <antogno...@gmail.com> said:
> On Wed, Mar 6, 2013 at 8:07 PM, Carsten Haitzler <ras...@rasterman.com> wrote: > > 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. > > hmm... my understanding was that this was only intended for Wayland. I > understand that it could be done in X11, but we are not doing this, > and I didn't know we even planned to do it. there would actually be benefits to allowing this in other display environments - like better synchronization between client and frame and... the ability for the driver to reduce a buffer cop to an exchange when using gl as now the buffer fills the window... :) > Even for wayland, there's the possibility to have server-side > decorations, although this is not done in weston. Anyway, if there's a i spit in the face of server-side decorations! :) > need to make this code more generic, we could make it available to all > the other engines instead of only Wayland, but of course it would > require changes to every engine. OK, got your point here, I just don't > know if it's worth worrying about this now. > > > 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 > > nope, no additional buffer copies here, the sub-evas is rendering > directly onto the buffer from its parent, as you mention on 4. well you had 2 choices. sub buffer or... in #4... > > 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. > > Actually, the sub-evas is the one where the window content is being > drawn, and it's rendered first. So the window decorations are rendered > after it, and if needed, they can overlap the window content. Of > course this is not flexible, there's no way to do the opposite if > implemented this way. so this means that frame cant be UNDER the content either... you're limited (compared to a swallow). :) of course i implied the inverse. if it is on bottom always, then you cant have it on top or event in the middle sandwiched by some frame content on top, some on bottom. :) > > 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. > > This is exactly what I'm worried about. How bad is it for GL? I > started implementing it for shm, since it's easier, but can't we allow > the sub-evas to render directly into a surface allocated by its parent > evas? > > Stacking is already explained above... this will be bad because engines assume having complete control of their rendering pipeline from beginning to end for a window. without such assumptions async rendering and such stuff aren't doable. this will hurt any render re-designs that parallelize rendering - see the pipe rendering for example where we split update regions between N threads. you now have to expose strict limitations and assumptions, interfaces etc. to insert foreign canvas content into another - this means exposing all the draw calls and./or other commandqueue pipelines and so on. imagine every draw is on a queue which is fed to a thread to do in parallel (which is actually the case for the sli threaded renderer)... you MUST either be able to flush and empty the queue and ensure everything is finished before blasting to the same buffer from another engine. with this other engine for things like gl.. you then need another context or to share the context. you possibly have to expose the same queue... and you now explicitly expose that rendering has multiple stages with an immediate-mode and then some kind of swap to get the stuff onto the screen. evas never imposed such restrictions. i designed it to be able to, in theory, behind evas's api, to be able to implement things like "raycasting" in 2d if you wanted, where you can run a "raytracer" across the 2d canvas 1 pixel at a time, walking all objects and computing their pixel in 1 write to the destination. maybe you do a hybrid partial raycast plus compose... my point is engines and evas internals had the freedom to implement this any way that might be possible and beneficial. by moving the direction you are.. you remove this freedom and that will have consequences. not so nice ones. > > 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... :) > > This is what I'm dealing with right now :) > > Thanks a lot for the comment! This is the kind of feedback I was > expecting... hope to get more help from you :) sure! :) so my original summary comment was the short version: "not a fan". :) > >> >> 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 > > > > > > -- > Rafael Antognolli > http://antognolli.org/ > -- ------------- 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
