On Tue, 15 May 2007 21:33:29 GMT "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> babbled:
> > > > 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. :) yup. canvas level was kept ultra-generic for the future where inside evas and the engines they got the ability to generate clip mask buffers and intermediate render buffers and use them. > > > 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. the problem here is - this begins to break down for things like textblock - you do NOT want to implement that in the engine. the object render func is probably the best design. for simple objects (rect, even objects) it might be ok to put n the engine. > 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. yup - we need to fix the engine api. this is actually one reason i'd like to keep # of engines to a minimum right now. also we need to make it better so engines can more easily fall back to software rendering for some ops to make it easier to produce a new engine - ie.e - render gradient in sw to a buffer - then just composite, but LATER be able to natively do the gradient object directly in the engine when it gets more complete/complex. > 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 > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) ------------------------------------------------------------------------- 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
