[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [E-devel] Evas needs... ?
On Sat, 7 Oct 2006 05:10:10 GMT "email@example.com" <firstname.lastname@example.org> babbled:
> > Ok, so what are the set of basic engine funcs, and obj
> > funcs, that will need to be provided?
> > To be continued.... :)
> Well, let's take a look at 'objs' first. Internally, the
> basic evas_obj structure keeps some things that we're interested
> in here:
> Its 'type' name and 'magic' number, some state relating
> to the general graphics context (color, clip obj, ...), a pointer
> to the 'data' that is associated with the instance of that type
> of obj, and a pointer 'func' to the set of obj_funcs that all evas
> objs need to provide at the canvas level.
> These obj_funcs include things like the render, render-pre/
> post funcs, a destroy func, and a few others.. Not all are tied to
> engine funcs, and not all need be used at the canvas level in order
> to implement an evas obj.
> The 'data' pointer holds things specific to each obj type,
> such as canvas level graphics state that is particular to that type
> plus usually some data pointer that exixts at the engines level,
> plus whatever other stuff the canvas level implementation of the
> obj might need.
> What we want to do is to replace the above set of things
> with a pointer to a structure that holds all this but extends the
> set of obj_funcs suitably.. and have that set of funcs be provided
> by a module as its funcs. That'll be our object_type -- basically
> all that exists in each canvas file "evas_object_[blah].c" will be
> suitably transformed into an 'object_type'.
> We don't need to get too sophisticated here to start with,
> just re-use the current module structure and such.
> I will give you more deatils on the particulars of the
> data structures later, but this gives the general idea.
> This is something that raster had actually wanted to do
> sometime back.. but later became less supportive of it since he
> got the idea that I was bent on destroying smart-objs :)
> It's true that they have some issues, but they are also
> extremely useful, so NO I no longer feel that they must die.
> One can do a bit more with them internally and such, but they
> don't need to go.
> Now we come to the crucial point - How do we connect the
> obj_type funcs, and in particular the render and graphics state
> related funcs, with an engine that one may know nothing about?
> Clearly, for a 'generic' implementation, we need a
> 'standard' base from which all others can be converted to/fro -
> and that is an argb32/a8 based implementation.
> Consider what people do when they want to draw something
> or other that suits their particular needs: They create an evas
> image object, generate argb32 data with the pixels they want,
> and set the data to the image obj -- evas takes care of the rest.
> This has two major limitations - it can be inefficient
> in that one doesn't know when to draw or not per state changes,
> and there's no way to provide a more engine specific version
> even if one could do so.
> The first one can be greatly helped by allowing one to
> provide render-pre/post functions (for image objs in this case),
> and possibly also by providing a 'render' callback (which would
> pass a region that needs updating). The render-callback approach
> can actually be a bit slower than the pre/post one since an object
> may be rendered several times, over different regions, in a single
> evas-render call, and is really best only for very dynamically
> varying objs (ie. state is changing on every evas render call).
> So, we need to at least put these pre/post calls into
> evas objs.. in particular image and smart objs.
> But it's only half a solution.. we really need to push
> objs out of the engines as described above -- let the engines
> provide basic functionality of several kinds, and let the objs
> give their own implementations, a generic one, plus any engine
> specific ones as their writers see fit.
> To be continued... :)
i agree in principle with most of the above - though i think it can be
simplified. for now i think the most pressing need is a way to hook an evas
object to native "formats" and rendering. this can be done many ways - and as
you say above. we will need pre-render, render, and post-render calls (pre
means setup (if needed), render == do it (if needed) and post-render ==
cleanup). extensiosn to x like xcomposite would provide a pixmap id - xdamage
would provide events when regions of that pixmap are drawn to. all we need to
do is be able to pass that pixmap to an object and have it use it. updates
would just be a list of update rects - image objects already use this. we just
need a way to pipe that native object down into the object, store it in a
generic way and then pass it onto the rendering engine to actually use. we need
to build that path. :) the same would hold for textures from gl, or dfb
surfaces from dfb or just about anything i can think of. this of course maps to
image objects where you are drawing what is already held in some sort of
"surface". there are others where you draw it as you go - polygons for example
are a simple case. evas already has these, but lets assume you have something
that can be drawn faster and more efficiently than it can be stored in a
surface. then you need the render callback scheme where some app-space calls
implement the drawing routines for the object. the problem is these would be
native display system space calls - and that makes life hard. this is the
really hard part. :(
> 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) email@example.com
Tokyo, Japan (東京 日本)