[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [E-devel] Evas needs... ?

	Ok, I took a bit of time to download and look thru Jorge's
"evas_core" work...
	It's interesting that what he's done here is pretty much
what we've been going over, though it may not have seemed that way
to him :)


	It doesn't matter what an 'engine' does with whatever it
receives - all that matters is that the objects have functions for
dealing with their state somehow, and that they can 'transfer' such
state, somehow, to a dst of some sort.

	They could deal with their states themselves and/or could
have it kept by something else.. just depends on the implementation.
What an 'engine' ultimately really has to do is to take an obj's
state and encoded it somehow to whatever a 'dst-surface' means.
	It could mean an argb buffer, or pixels on a screen, or text
in a file, or binary data of some sort being sent thru a socket,
or whatever.
	If the object has particular knowledge of the engine, then
it can have the engine encode its state in certain ways prior to
putting it out to the 'dst-surface', or any number of other things.

	Think about it -- If you can make an object 'render' to an
argb32, and you can take an argb32 and send that data to something
that encodes it as gummy-bears.. then you just wrote a gummy-bear
engine that can represent objs as colored, flavored gummy-bears.
	If your object knows a bit about this gummy-bear engine,
then maybe it can get this achieved a lot more efficiently.. maybe
it can send only its color for the color of the gummy-bear, and
somehow encode other parts of its state as a corresponding flavor
name, and just send that.. rather than send argb32 data for the
gummy-bear engine to decode and construct a gummy-bear from.