On Thu, Mar 7, 2013 at 8:43 PM, Carsten Haitzler <ras...@rasterman.com> wrote:
>> > 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. :) haha, ok, I've never seen that, but I suppose that now you want to implement it just to prove that I was imposing limits on what Evas can do :P >> > 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. OK, but the only assumption that I'm doing right now is that the sub-ecore_evas renders before the parent one. And that's done inside the ecore_evas render function. Additionally, the sub-ecore_evas doesn't swap the buffer or anything like that, it just renders on the buffer and assumes that the parent one will do the swap. It's actually not much different from what is done when we have a sub-ecore_evas image. So I thought it would be safe to use the same approach. And until now I didn't expose anything different, no new interfaces, nothing special. Of course as I told you, I didn't get into the egl one, so things could be quite different. So, if you really prefer to go with the framespace offsets on evas objects, here are the problems that we faced: 1) To have additional objects: the objects stack gets messed by additional objects like the frame ones. For instance, we had problems when sending objects to the lowest possible layer, where these objects get covered by the frame objects. Of course the frame could be done with a "hole" on its content, so that wouldn't happen, but this is still bad imho. And even the idea of clipping objects to a content clipper to avoid having them overlap the frame is really bad for me. 2) We could not find a good way to add the framespace offsets to every objects. I see some scenarios: * if we apply the framespace offsets to *every* object, the objects which are children of smart objects will get moved more than once, since they are already moved relatively to their parent, which had the offset applied to itself; * if we apply the offsets only to objects which are not children of smart objects, then some different smart object could just have a custom smart_move which does not move its children relatively to itself, but move them to an absolute position, and then they would not get the offset applied to their position (but they should). Ok, 2) was our biggest problem and used to cause lots of bugs. But while I was writing the email, I thought about a possible solution (devilhorns, please comment on this too): maybe we could just change the evas_object_smart_move_children_relative() to don't use evas_object_move() and, this way, to not apply the framespace offset to this move. hmm... I must think about other possible problems, but I'm as fan of this idea as you are a fan of mine :P But at least it is mostly all implemented already. -- 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
