On 5/15/07, jose_ogp@... <jose_ogp@...> wrote:
> 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.
good! :-) I won't reply every item as I want to wait for raster and
possible others to step in and comment, so I can learn a bit more, but
few things are:
> 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?
> 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 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).
> 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,
> 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.
ok, so far it makes sense.
> 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.
here I need some clarification. How do you see these in use? How do
you see x, y, w, h, alpha already being in the engine help?
> 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.
Gustavo Sverzut Barbieri
Mobile: +55 (81) 9927 0010