[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [E-devel] Evas needs... ?
On Fri, 6 Oct 2006 22:13:05 GMT "firstname.lastname@example.org" <email@example.com> babbled:
> > > I thought that Jorge (aka. turran) was going to do some
> > > work on the evas fb engine, and also ecore_fb, but don't know if
> > > he's had a chance to get to that or not.
> > yeah i do have plans for it, but with the changes on the way evas
> > engines will behave, i prefer to not touch it before those changes.
> > btw a little offtopic, but now that the premul stuff is in, isnt a
> > good time to continue thinking/start coding the next evas?
> It wouldn't hurt to fix those kinds of things now since
> they are highly specific to the particular engine's internals.
sorry to hold off on this for so long - it needs discussion - sure. i'm doing
some mail catchup... so let's get on with it :)
> But, sure.. let's continue the discussion on re-vamping
> evas' engine/objs internals. :)
> If you take a look at the engines, you'll see that as part
> of the grads rewrite for the move to premul, I also did them so
> that the engine funcs for grads now correspond exactly to the grad
> api funcs plus the canvas level 'obj-funcs'.
> This is the general pattern needed in order to separate
> 'objs' from 'engines'.
> The next step is to do this for all the other current objs:
> lines, rects, polys, text, and images (textblock and smart objs
> are not dealt with at the engines level).
> This is straightforward for all but the image objs since
> image related structures and funcs are used extensively and since
> loaded images are basically shared resources.. But it can be done.
> Once all the objs have been thus redone, one can begin
> to place the 'objs' into modular units (built-in and/or loadable)
> which provide at least one generic implementation wich can hook
> into any engine... plus they can also provide engine-specific
> implementations for more refined/optimized versions for a given
> Ok, so what are the set of basic engine funcs, and obj
> funcs, that will need to be provided?
qwell the current set - maybe. then again one could argue you can break the
current set down into much simpler units:
where a span is a linear horizontal set of pixels from point A to point B:
solid span write/blend
pixel span write/blend
linear gradient span (to/from pixel value) write/blend.
of course the above would allow for an alpha mask as well and src pixel(s) are
argb32 (solid case is a single color for this - a special case of the pixel
span). linear gradient can be used for aa lines and polygon edges. mmost things
can be built on top of this.
BUT - i think what we currently have for engine funcs is not bad.
as for modular engine-specific objects - we need to do something like this -
but i would like it more generic. the big use of this is for importing engine
space specific data - eg pixmaps in x, or textures/fbo's/pbuffers for GL etc.
some other app or part of code provides such a native format drawable and you
want evas to handle it. evas provides the most generic mechanism via image
objects (and ARGB32 pixel data) but this will of course suffer performance-wise
as you always have to end up with argb32 pixels in application-space.
this segways into the recent thread on GL in etk (or evas). you basically want
a "native surface" obects. this would be ARGB32 pixels for buffer and fb
engines, pixmaps for x11 engines and either textures, fbo's or pbuffers for GL.
now what you need is a VERY generic mechanism at the evas api level so you can
interact with all the native formats and pass this information down into evas.
i actually wanted to do this as an extension to image objects as they provide
almost everything we need, except the interface for native engine types.
> To be continued.... :)
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> enlightenment-devel mailing list
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) firstname.lastname@example.org
Tokyo, Japan (東京 日本)