On Tue, 15 May 2007 10:29:49 GMT "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> babbled:
> > 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. a very good summary/analysis :) > 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. the only problem is - this makes engines a lot bigger and more complex. > 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. we do need to push more of it down - but i am not sure we should push it all down. the engine api imho is still best being an immediate-mode api. we just need to expand it more or re-factor it to deal with new operations. > 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
