> > 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.
>
> right now clip is all about rectangle operations to limit the visible
> are... or is anything else supported?
Nothing else is 'supported' except plain rectangles, but it
was intended as decribed.. and the canvas level does try. :)
> > 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 don't get what you mean with rotations/transitions.
> If clip object is rotated, then you'd consider it rotated and
> you're done, just like you get its current size.
> In order to minimize work, we could do regular bounding box clip
> and when to process scanlines, segment it into intervals, these to
> be segmented by the next clip object and so on...
> In the end you get the continuous segments you would
> blit/blend/transform (in the gradient case).
That's one way, software-wise. But it's just not the issue
here.
> > 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.
>
> Well... moving everything to engine will leave us with just a common
> API and very different implementations, that will be really
> extensible, trade off is consistency, complexity and possible more.
>
> If we extend clip to be any polygon or curve (if we allow ellipses,
> circles, ... in future) and also enable cumulative transformations
> we can do many things without all that pain. The former is not
> difficult, since well known algorithms exists, the later is more
> related to implementation details, while I know it's possible to
> do JIT and remove overhead of functions, just getting the operations
> on i686+software_x11, I'm not sure if it fits other sytems (GL?)...
> if we trade off memory in favor of performance we can always render
> to an auxiliary buffer and then do some operation (sub, add, or,
> and, mul, ...) while rendering clipped objs.
>
> That's my understandings so far, I don't know any engine or even
> the API that well, if I'm wrong just let me know.
Well, you see.. the issue here isn't really about being able
to implement things with software algorithms, or with some other
gfx backend (gl or xrender or cairo or whatever). All that can be
done.
The problem is that evas just won't let you even try, not
without extensively rewriting a large amount of things.
Again, the way the internals are setup, every evas object
calls a generic 'render' function to draw itself.. and this is
an abstract kind of function since the rendering target and the
rendering mechanisms can vary (different engines).
But, this render function doesn't get directly implemented
by the rendering backends. Instead, it uses a set of abstract
'engine functions' which are themselves what get implemented by
each rendering backend. Those functions are what the canvas can
use to draw an evas object.. and ONLY those functions.
Let's take your example of an 'evas_object_transform_set'
api function that you want.
Ok, when you come to actually implement this, you will add
some 'transform' to the evas object structure so that all objects
keep the transform state. Then, when the canvas calls the object's
render function it needs to draw the transformed object.. so in each
object's render function you need to 'implement' the drawing of
such a trnasformed object.
But, you can only call 'engine functions' for this.. that's
ALL you can work with.
Suppose you then want to be able to set a 'filter' object
on an evas object, eg. to blur, bumpmap, ... an object. Again, you
will add such state to the evas object structure and in each object's
render function you need to 'implement' the drawing of such an object
with such a filter, and with the transform you wanted for the object
before, and maybe the filter itself admits transforms, and maybe
you have the object clipped by an image object and this image object
has borders, and is itself transformed in some way, and possibly
another filter is being applied to it, and the image object has
another clip object which is a path which is.... and the object you're
drawing is a rounded recangle, which is to be stroked with some color
and filled with some gradient texture, and the gradient is a radial one,
and is trasnformed in some way, and...................
And all this you have to 'implement' via the set of "engine
functions" beacuse that's ALL that the canvas can access to do
anything. That set of engine functions is the canvas' gfx api, not
the actual engine gfx backend apis.
See the problem?
Fortunately, there is a way to do this. :)
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
