On Wed, 28 Mar 2007 20:36:17 -0500 "Nathan Ingersoll" <[EMAIL PROTECTED]> babbled:
> On 3/28/07, Brian Mattern <[EMAIL PROTECTED]> wrote: > > > > I) Absolute canvas coordinates > > _point_add() takes a coordinate in canvas coords, and draws that point > > at that coordinate, completely ignoring the object's position > > This way sucks as it requires the user to track all of the polygons > points and update them on a move. sure - but the other side (relative to object top-left) means that either you need oversized poly object that cover thw whole canvas and only use a sub-set of their space for the poly if you want to be able to place/define a poly in abs co-ords. this is common as you may calculate points based on a higher level layout nd thus have abs coords as the output - otherwise you need to figure out min/max, move the obj then define poly coords - so you make 1 case easier, and the other harder. > > II) Relative object coordinates > > _point_add() takes a coord relative to the object, so if the poly is > > moved to (10,10) the point (5,5) will be drawn at (15,15). > > Somewhat more sane as it at least allows for easily moving a polygon > from the users perspective, but size handling would probably be > non-intuitive clipping of the image. > > > III) Polygon coordinates > > _point add() takes points in an abstract space. This space is located > > such that the origin of the object corresponds to top left of the > > bounding box of the polygon's points. > > I think this one makes the most sense from an API perspective. Moving > the polygon object would obviously update the relative coordinates > like (II), but the size change could be used to scale the polygon. > > > I'm impartial as to whether (II) or (III) is better. (II) is a bit more > > predictable, though. > > I think it depends what you expect from resizing as to which is more > predictable. If you want scaling then (III) is more predictable, but > if you want clipping then (II) is. The problem with (II) is that you > can easily emulate the clipping behavior with a clip rect, but scaling > would require the user to iterate over the points themselves and scale > their locations manually. > > > As for the size clipping the poly's extents, that makes some sense, but > > I think the default expected behavior would be for it to be large enough > > to show all of its points. So, maybe it would be better to ignore the > > size? > > This should probably behave like images for initial sizing. If images > have an initial size equal to their image size, then the polygon > should assume a 1:1 scale and have an initial size large enough to > contain all of their points. > > Sound reasonable? actually image objects dont have initial size of the image size. they have an initial size of 32x32 as to all evas objects that don't specify their own geometry explicitly (poly, line and text objects have their size/position altered by contents. a problem when scaling is cumulative error. u scale down to 1/100th then back up to normal size and you will lose a lot of precision on your points. so this means points need to be stored in the original object size space and scaled on the fly at render to avoid cumulative error. on point add or reset, you basically get a new geometry space that is the size of the obj... 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. > ------------------------------------------------------------------------- > 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 > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) ------------------------------------------------------------------------- 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
