On Wed, 9 May 2007 00:51:14 GMT "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> babbled:
> > > .... > > [things about transforms and such] > > .... > > Most of this, and clipping (and some other things), are coming > hopefully within this month or so. But there are things you should > be aware of. > > Generally speaking, it's not too difficult to do any of these > things - especially if one is willing to forgo some quality and/or > some speed.. but even then, getting this in evas requires a fairly > large rewrite of the engine level internals. indeed - i have a non-trivial queue of mails from you all on this topic! :) > In evas however we have further things to deal with, especially > when it comes to image objects and 'transforms'. A 'fast' software > implementation for rotations is really not an issue. > > Image objects in evas have these 'border' attributes which > actually make them into a compound, structured object.. not just a > simple image in the sense that most libs deal with. Also, we want > fairly 'high quality' software down-scaling, which again most libs > bypass by using eg. bilinear interpolation (which gives a 'decent' > means for implementing tarnsforms). you missed the fact that a transformed object now is no longer an aligned rectangle - so the event engine needs a big change to handle mouse move, in and out events etc. :) we need to now handle transformed regions for objects - or do we? do we just expand the event rect to be the bounds of the whole object? what about clipping. right now clips also clip the event area. personally, as an intermediate-step i'd like to simply be able to modify the FILL of an image (or text object) so the FILL can be transformed (we need to be able to disable tiling for images). this will then allow for us to provide transformed image data but within a rect - allowing us to worry about events later but get the benefits of the visual elements now. > These two aspects together make for something more complex > than what is found in most other libs that deal with 'images' and > 'transforms'. > One should realize that in order to satisfy these, setting > a transform on an image object is going to mean "apply the trans > to the result of the image obj's fill". Only sometimes will we be > able to compose the transform with the fill scaling and do it all > in a single pass. It doesn't matter what the 'rendering' engine, > ie. wether it's software or xrender or gl or whatever.. this will > always come up with scaling+borders. aye. borders also complicate things a lot. > Applying transforms to objects like rects and gradients is > simpler (I'll refrain from mentioning styled text objs or textblock > objs), but for compound objects like smart-objs one needs to make > some decisions. text and textblock objects likely will need to be pre-rendered to a buffer then have that buffer transformed. :( > One can apply the transform to each member obj of the smart > object.. and things may end up not 'lining-up' as desired. Or one > can apply the trans to the result of rendering the untransformed > smart object.. and then there will be its own set of 'issues'. > [NB: One can't, in general, decompose a transform into a > simple rotation plus scaling plus a simple shearing -- you can > at best get something like a scaling plus a generalized rotation > where you rotate each of the two axis differently.. and this is > just for non-projective transforms.] yup. you can convert a scale + rotate INTO a transform matrix, but not the other way around (easily). > The notion of a "transformable interface" is something > that I think has been too quickly hyped and is going to be rather > tricky to actually achieve -- if one wants good-looking results > and an un-ambiguous semantics.. I don't think the SVG 'spec' alone > will give that. > > > 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
