Jorge wrote:
> ...........
>> Ummm... That kind of depends on the api exposed.. which is somewhat
>> varied there. You could use this or that part - say the vgfx stuff plus
>> whatever image stuff.. very similar to the frameworks we mentioned.
>> But it's still too 'backend' specific. Better to have an abstract api that
>> never had to deal with what display target, engine-renderer, etc. was
>> being dealt with. That's what these others do, in their own way.
>>
>
> Well, you have two options there:
> 1. Make an api with all direct rendering functions abstracted with an
> engine backend, similar to what evas currently have, large increase of
> engines, code duplication and very difficult to actually match the
> different rendering apis into one. Something similar to this:
>
> objects / canvas api -> direct rendering api -> engine backend
> functions, so in this case we should expose the direct rendering api.
> I dont think this way scales too good, is how evas currently works,
> and we all know the problems on the engines side.
>
> 2. Or the other way around (is what i wrote on the first mail on the
> "gfx api i!" thread), do a mix:
>
> objects/engine drawing -> canvas api -> engine backend. So the engine
> code is specific for the object itself, no need to abstract it, of
> course we need a way to retrieve the engine backend, which is very
> small, only functions to retrieve the context, temporary buffers and
> output buffer; and a way to know the engine's id.
>
> The main problem we have is what we want to extend, objects or
> engines? both are too joined, one depends on another. So i prefer to
> leave the complexity on the object itself, make it draw however it
> wants, with the lib it wants. Instead of making the objects fixed and
> just add engines. Yes, i agree that the model 2 is more complex than
> the 1, but is more powerful too and far more extensible.
>
>
The main problem on the engines side of things right now is basically
that the engine functions expose a very limited immediate-mode gfx api.
Either they should expose a 'powerful' one (which one?) or they expose the
'same' kind of api that the canvas does. They should also allow for loading
objs which define themselves (given some fixed, minimal set of basic stuff).
Which is basically what we're roughly talking about with (2) above.
But, regardless of the api/model they expose, at the canvas level
itself, ie. objects, one would like to be able to define obj types whose
drawing is defined via an "immediate-mode" gfx mechanism -- easily, and
as "directly/abstractly" as possible (why?).
____________________________________________________________
Click for free info on getting an MBA, $200K/ year potential.
http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3l7wXGcFhbslXqHcpEJHXJen8P2UqzdrezxtkbwegY1CX6Wl/
-------------------------------------------------------------------------
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
