Gustavo wrote:
> I want to know how difficult would be to implement support for clip
> using gradient objects.
> ...
> ...
>
> We are willing to implement it if you give us some hints :-)
Just thought I'd go back to this a bit here, and see if
I can give you an idea of what's 'really' needed for this.
The way Carsten setup clip-object semantics in evas is that
any object can clip any other, and this can be arbitrarily iterated
(since a clip object can have a clip object as well). Also, an object
can clip any number of objects.
It's a very nice idea, though with that kind of generality
it's going to be tough to do anything involved very efficiently.
However, the real problem in evas right now is just trying to get
this implemented *at all*.
The way the internals are set up, it's just not feasible..
and neither is doing *anything* much beyond what raster initially
set things up for (eg. rotations or any kind of transforms on image
objs.. just can't really be 'done' right now, no matter how 'easy'
it might be to accomplish that with any of the gfx backends).
I've pointed this out several times in the past, but let me
explain in a bit more detail exactly why this situation exists and
what's needed to correct it.
The canvas level has a structure that holds the state for
an evas object (eg. size, clip-obj, etc). This structure also has
a pointer to any type specific state (ie. things for rects, images,
etc).
It also has a pointer to a 'render' function that is called
whenever a given object needs to be drawn - this function is given
for each specific type of object, and has a generic form, eg. draw
something to some dst at some point... and such things.
The way these object render functions are obtained is in turn
via certain other 'engine functions' which are implemented by the
various engines, ie. by the various rendering backends.
The problem is that this set of 'engine functions' then
defines an immediate mode rendering api which is ALL that the
canvas can work with. It ties the canvas lib's capabilities to the
specific rendering model/api that this set of interfaces defines.
Unfortunately, the current such interfaces, ie. the rendering
model.. is extremely limited. That's the source of all the problems
that evas faces right now as far as extending its capabilities to
allow for such things as obj transforms, clipping, texturing, and
any number of other gfx aspects.
Now, one can say "Well, let's use eg. a vgfx rendering model,
that's a powerful one...", or maybe say "No, let's use a compositing
rendering model, it's more flexible yet smaller...", or any number
of other things.. and how is one to choose? (and the choice must
make it easy for it to be realized with various other gfx libs. eg.
xrender, gl, cairo, ...)
Very easily: Let the canvas api be the rendering model,
rather than impose some other. After all, what one wants is to
modify 'obj' state, setup things, and draw the 'obj' as need be.
What that means is that one needs to push all relevant
canvas level 'object' state down to the engines level, and let
things be implemented there as each 'engine' sees fit.
Do this, and all the things everyone wants for evas to be
able to do, and things that no one has maybe even thought of...
will at least be feasible to *attempt* to implement. It simply
isn't feasible or reasonable right now to even try otherwise.
jose.
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
