> > all in all this isnt a simple solution. the only way i see to
> > handle both methods is to have 2 calls. 1 to add a point relative
> > to origin and one to specify it absolutely.
>
> Two calls makes sense, but I think internally the point list
> should be relative to the object origin, and then convert to
> absolute coords at render time. This would allow us to do some
> sore of scaling based on object size (although some error would
> be introduced if the points were specified in abs coords).
In order to eliminate cummulative errors, the vertex coords
must be stored as input (possibly modulo integer translations).
In order to minimize confusion from multiple coord systems
(and every time you have any kind of transformation, you basically
create a new coord system), or things like eg. mixing calls to add
points with calls to move/resize/rotate the obj (something which
I think ought to be avoided in usage), the inputs must have an
'absolute' interpretation - either absolute rel to the canvas,
or absolute rel to an (untransformed) 'obj coord system'.
I'd have to say that I think it would be best if the inputs
were taken rel to the (untransformed) obj, and nothing else. The
object size would grow with points added, or with resizing (scaling
the poly), and the bounding rect would change with rotations, etc..
But the input vertex coords would have an absolute interpretation
as being rel to the (untransformed) obj.
The obj's coord system would always be at (0,0), regardless
of the obj's canvas position, whereas the latter can change not only
from moving, but also from adding vertices (whose coords are then
always rel to (0,0)), since one wants the obj's cur pos to be a
function of the min coords of the vertices.
This may seem a bit complex if you think about it, but
it would actually be fairly straightforward to use in pratice --
*IF* one avoids adding points after a move/resize/rotate, whenever
points had already been added before.
BTW: I should add that the same should be done with line objs.
Using coords rel to an obj's (untransformed) position is not
without precedent in evas - image and gradient objects have a fill
position which is interpreted exactly this way.
Note that we'll need to add internal 'obj funcs' that deal
with move/resize/rotate/... which the generic canvas versions would
call before actually resetting the state - just as we have now for
smart objs. There's really no way around that.
Also, let the engines do any transformation of inputs..
not the canvas. The poly would be passed as is, along with the
scaling/rotation data and the obj's cur pos to render at.
Lastly, note that edje (bleeding or not), has a general
means for specifying an object's pos/size which should probably
be used for these vector-based objs. But to avoid any possible
'issues' with things, I'd say that any semantic decision should
be heavily influenced by an attempt to actully try adding these
to edje - if only as a first try.
It's thru edje/edc or similar such (eg. Freevo's kaa.evas
xml description, or tilman's "redact") that most interfacing
with evas is done, and while I don't think evas should be bound
to such, it should make it feasible to use from such (pseudo-)
scalable descriptive formats.
jose.
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
enlightenment-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
