> ....
> [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.
        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).

        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.

        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.
        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.]

        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

Reply via email to