Jorge wrote:
> On Fri, Aug 1, 2008 at 11:21 AM, Jose Gonzalez <[EMAIL PROTECTED]> wrote:
>   
>> Jorge wrote:
>>     
>>> .....
>>>       
>>>>    Let's consider the first part above only, and let me ask you this:
>>>> What
>>>> are the successful/modern gfx *apis* out there used for building guis,
>>>> what
>>>> are
>>>> their models, what are their primitives, how do they deal with
>>>> extensibility
>>>> or custom rendering. Take a look at say Flash, Silverlight, and Qt...,
>>>> and
>>>> let
>>>> me know what you see there.
>>>>    There are others as well, but if you look at just these and give a
>>>> synopsis
>>>> of what's there, we can compare with evas and/or some possible other
>>>> thing
>>>> and
>>>> continue with greater insight and foresight. :)
>>>>
>>>>         
>>> Im not sure if this comparative will be fair, the technologies you
>>> have named are products not libraries, is a full set of objects /
>>> classes / descriptions / whatever given as a whole to match a product,
>>> my mail was more in the sense of how to change things internally in
>>> evas that will allow several features externally.
>>>
>>> You might see evas as a product from several perspectives, from the
>>> object's POV: a library that only gives you a few type of objects:
>>> line, rectangle, polygon, images and gradients, text, etc and has a
>>> single clipping mechanism; but the idea was how to make more objects
>>> easily and still have the possibility to make those objects hw
>>> accelerated, not what others have that we dont.
>>>
>>>       
>>     Well, if you take out things related to gui builders and such, they're
>> really just 'libs', they expose a set of structures and funcs one can call
>> on - it doesn't really matter that they use different programming languages
>> have different runtimes, use classes, and whatnot.
>>     What's common to them all is they build a retained-mode gfx model out
>> of a fairly standard immediate-mode vgfx drawing model. The method used to
>> obtain extensibility may vary somewhat, but at its heart it's derived by
>> letting you create new retained-mode 'types' via the use of the immediate-
>> mode drawing api to define how to draw new types (and some other aspects to
>> allow for specifying how to manipulate them in various ways).
>>
>>     The point here being that evas lacks such an immediate-mode api, whether
>> vgfx or otherwise, which limits the way that new 'type' can be defined in
>> certain ways. One could try and build one such immediate-mode gfx api, say
>> a vgfx one like these, and use that.. or one can try and do it the other way
>> around -- use some set of objs the canvas supports (perhaps all) to 'define'
>> the immediate-mode gfx api indirectly, and feed this back in.
>>     
>
> True, this is exactly what my first mail was about, have an immediate
> rendering api exposed. The question is, make evas expose it?, or
> handle it on a different lib? i've preferred the second choice and
> that's why i built enesim.
>
>   
>>     BTW, hw accelearated really has little to do with this per se, that's
>> just a matter of whether your obj rendering can be easily represented by
>> whatever hw accelerated api you have to work with.
>>     
>
> Yes, but how can you do such a thing if the context of the accelerated
> api can't be retrieved? there's no way to do so right now, a smart
> object for example can't retrieve the gl context to do its own
> rendering when some event happens, so it is a must, or hw accelerated
> objects won't be possible.
>
>   

      If you want such a thing, that explicit, then you need to expose specific
"native surfaces" -- that's the point of those. Otherwise, you don't need to
expose anything directly. You just 'expose' how to crete new, compound 
renderings
from existing ones - if the existing ones are "hw accel" then so will be the
compound one. :)



____________________________________________________________
Click for free info on college degrees.
http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3l8WvE9WjyIpXSRhb6PKODGRN8lKbF8Q3Cn2OMy3CYXX5U6F/

-------------------------------------------------------------------------
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
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to