Re: guppi coor system

[Rob Browning <rlb cs utexas edu>]

linas@linas.org writes:

> Coordinate systems is a concept one uses just to specify the endpoints
> of a line, the radius & center of a circle, etc.  There's nothing in
> here having to do with pixels! 

...unless you're trying to map an image onto a surface.  I suppose
strictly speaking it's not per-pixel, but it's roughly the equivalent.
In any case, I doubt we're likely to go there anytime soon.

In any case, you're right.  I knew better than to say what I said, but
I was in a hurry this morning and didn't think long enough before
typing.  The main point I was trying to make is still valid, though.
Unless you have access to lower levels of the graphics API than we
have with, say, GTK (unless it's been updated since I last looked
carefully), you can't apply all the transformations you're talking
about to some of the graphics primitives.  Fonts and ellipses are
glaring example of this.  In these cases, you just don't have access
to the vertices.  So unless you're going to write your own
circle/ellipse/whatever algorithms (which for everything but fonts
isn't that hard, and some I've done before), you may not have a ready
way to integrate these things into your transformation engine.

And it gets pretty awkward when you blow up your figure by a factor of
3 and nothing happens to the font sizes/shapes.

As an alternate example, to get a transformation matrix rotated
ellipse using gdk, you can't use their gdk_draw_arc call.  You'll have
to write your own ellipse routine in terms of gdk_draw_lines, and for
a truly smooth ellipse, in areas of high curvature, you'll end up
doing something close to per-pixel drawing (i.e. two vertices can't be
very many pixels apart).  That's what I was really thinking about when
I mentioned "per-pixel" before, though that's not what came out of my
mouth.

So the question becomes, "how much of this transformation stuff is
worth worrying about right now?"  If it's easy to implement what we
need using that model without having a lot of gdk-interaction
awkwardness, then I don't have any problem with it.  I agree that it's
the right(TM) model for a complete solution, but I think we should
spend a moment double-checking our needs and how this would work in
practice before diving into what, in the most complete implementation,
would be a pretty big chunk of work.

(and apologies for the previous red-herring.)

-- 
Rob Browning <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930