eberard@ajpo.sei.cmu.edu (Edward Berard) (08/19/88)
I have a multi-part question concerning the rotation of objects on a Macintosh: a) Given an object-oriented graphic object (e.g., a rectangle or an oval) and a point about which it is to be rotated, what are some of the better algorithms for rotating this object? If there is more than one viable way to accomplish the rotation, what are the trade-offs? b) Given a bit-mapped graphic object (e.g., a picture or icon) and a point about which it is to be rotated, what are some of the better algorithms for rotating this object? If there is more than one viable way to accomplish this rotation, what are the trade-offs? c) Given a text object and a point about which it is to be rotated, what are some of the better algorithms for rotating this object? Do concepts such as font and style impact these algorithms? If there is more than one viable way to accomplish this rotation, what are the trade-offs? d) For each of the above, consider the user interface issues. For example, during rotation, should the user be presented with a schematic representation of the object (e.g., a dashed-line outline of the region occupied by the object)? e) Consider the impact, if any, of accomplishing the above rotations from a remote source. Specifically, suppose you had to direct the Macintosh from another computer, e.g., you are sending commands to the toolbox over an RS-232C line, Ethernet, or AppleTalk. Does this change any of your answers? What are the trade-offs? Obviously, general computer graphics rotation algorithms are available in any number of texts. However, the intent of the above questions is to narrow the focus to the Macintosh environment. I would also be interested in a discussion of directing the output of the above rotations to both Postscript and non-Postscript printers. -- Ed Berard (301) 695-6960
oster@dewey.soe.berkeley.edu (David Phillip Oster) (08/19/88)
In article <360@ajpo.sei.cmu.edu> eberard@ajpo.sei.cmu.edu (Edward Berard) writes: > a) Given an object-oriented graphic object (e.g., a rectangle or an > oval) and a point about which it is to be rotated, what are some > of the better algorithms for rotating this object? For an object that is defined for a fairly small set of control points, such as a rectangle then one rotates by: translating so that the point you want to rotate about is now the origin, rotating each control point, trnaslating back to the original coordinate system (these TRT' transforms can be composed into a single matrix, so you can transform each point with a single matrix multiply. consult any standard graphics text.) Note, that in general a rectangle will not be aligned with the x,y axes, so you'll have to draw it as a polyline, a polygon, or a region (depending on what you are doing.) and you are completely out out luck on ovals, you'll have to write code yourself to draw rotated ovals. See the tech notes on Quickdraw comments for information on the appropriate quickdraw comments to include to let postscript printers know what you have done, and to o it over again in postscript. > b) Given a bit-mapped graphic object (e.g., a picture or icon) and > a point about which it is to be rotated, what are some of the > better algorithms for rotating this object? Render the object into an off-screen bitmap. and for each pixel in the destination, apply the inverse transform to find the set of pixels that contribute to it in the source. Do the appropriate weighted sum of the contributing source pixels to determine the value of the destination pixel. (This from destination to source algorithm works much better than a source to destination one.) You'll probably want to special case out rotations by multiples of 90 degrees. To rotate by 90 degrees, view the bitmap as a 2-dimensional boolean array. Transpose the array. You're done. For details, see a recent Mactutor article on editing sideways text. The comments from section (a) about postscript PicComments apply here also. > c) Given a text object and a point about which it is to be rotated, > what are some of the better algorithms for rotating this object? Render the whole string into an offscreen bitmap and proceed as for bitmaps, above. piComments for postsript printers are especially important here. > d) ...should the user be presented with a > schematic representation of the object...? yes. > e) Consider the impact, if any, of accomplishing the above > rotations from a remote source. Unless the remote source is on a card in an SE or a Mac II, the comunication channel into the Mac will be so slow compared to its local speed that it'll be much faster to do the processing in the Mac than it is to have it sent out. Of course, if you've got the right answer, then it makes sense to send it to the Mac, rather than sending another problem. Let me be concrete: the Mac can rotate an icon faster than it can recieve an icon. If you are only showing one, and it is rotated, you might as well send it rotated. But, if you are showing one icon in many orientations, just send it once and let the multiple orientations be generated locally. --- David Phillip Oster --When you asked me to live in sin with you Arpa: oster@dewey.soe.berkeley.edu --I didn't know you meant sloth. Uucp: {uwvax,decvax,ihnp4}!ucbvax!oster%dewey.soe.berkeley.edu