Cedric BAIL wrote:
> On Sat, Aug 16, 2008 at 3:15 AM, Jose Gonzalez <[EMAIL PROTECTED]> wrote:
>
>> Just to make it clear what I think about this: This kind of thing is
>> something that really needs to be done, one way or another. :)
>>
>> Some time back, I thought about having the edje recalc function called
>> by smart class render-pre/post funcs, and these funcs I wanted to be called
>> by the obj's internal render-pre/post ones as this would be useful for
>> creating
>> semi-custom, stateful, objs that rendered to image buffers (possibly native
>> surfaces). But I saw that there were problems with that due to the very kinds
>> of things you mention, the events system and possibly other things, as I
>> mentioned to Cedric once here.
>> You could have an additional smart class func, say a "calculate" one and
>> then do as you suggest.. but the main issue here is whether this kind of
>> smart
>> class specific approach is the "best" way to deal with this kind of general
>> issue.
>> I've mentioned two other possible ways to deal with this in a more
>> generic
>> manner - for example an ecore_evas based one akin to what's done with
>> sub-canvases
>> (which is useful for those), or a more 'evas only' one akin to what you have
>> here
>> but using user supplied callbacks. There are other possibilities.. evas could
>> expose an EVAS_RENDER_EVENT and have callbacks one can add for such, called
>> prior
>> to the internal evas-render loop... and other possibilities.
>>
>
>
>> I don't know what might be best.. just that this is something needed but
>> that needs more thought, some experimenting, etc. Maybe raster, nathan,
>> hisham,
>> and others can give more feedback on this - maybe your proposal *is* the best
>> way to deal with this general issue, but it won't hurt to consider other
>> possible
>> ways if they have potentially wider applicability. :)
>>
>
> Ok, here is a patch that improve the speed for evas part of Gustavo
> work. I did rename the callback to calculate. Regarding if it's the
> best way, that I don't know, but it's easy to implement on both side
> and fast.
>
> Between the edje patch is currently not correct as many getter expect
> the underlying object to be calculated. If you apply the attached
> patch (not really a smart patch) you will see that many user of edje
> expect it to be calculated at some point.
>
>
I still think this approach -- though a simple and seemingly
straightforward
solution to the issues you want to address with edje -- might be somewhat
premature.
In fact, I have the feeling that this kind of thing doesn't really belong
in evas at all. It's not really about 'rendering' per se, but rather about
synchronizing user-level calculations of various sorts with evas render calls..
and that's something that should really belong as exposed functionality of the
ecore event loop with evas rendering. I also think it's way too smart-class
specific for an issue that's really fairly generic in nature..
But, since I don't have a concrete alternative to provide instead right
now,
I'll let my arguments rest and leave it up to you guys to decide. :)
____________________________________________________________
Need cash? Click to get a cash advance.
http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3mKes2WWGebBJuRv0ciRPVQtuQujaYRbFK1lHAnQ1IAYgDyX/
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
enlightenment-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
