Re: guppi coor system

[Rob Browning <rlb cs utexas edu>]

(John, if you skim the intermediate bits of this response, please make
 sure and read the last bit which may (or may not) agree more with
 what you've been thinking...)

linas@linas.org writes:

> Well, that's way out of line from where we want guippi to go, but
> ...  vortex mappings like that are quite complex; they require each
> pixel to be remapped through some non-linear function.  If
> traditional mip-mapping is used, then you have heavy cpu
> computations to set up filtered mip-maps, which is computationally
> infeasible for live video.  Thus, part of quick-time's secrets is
> how to do high-quality image distortions without the traditional mip
> map filter overhead.

Well, I wasn't as clear as I should have been.  They may or may not be
doing anything very fancy.  What I saw was a window being "sucked
down" to the bottom of the screen where the bottom of the window just
narrows before the top as it goes down.  There wasn't any "twisting,
etc.  I didn't get a good enough look, but that could be a fairly
straightforward skew operation, though it is per-pixel.

Also, I was under the impression that this works for *any* app, it's
applied at the windowing/display level, not inside quicktime, or a
particular app.

> well, I suggest you want 'pushmatrix' and 'pushattributes to be
> separated.  One does the coordinate pushmatrix far more often than
> the color/linestyle save&restore; and the attribute push can become
> expensive ...

Sure, I wasn't trying to be all that specific, but you do need both.

> you compose matrices to get the desired combo.  Then, a point in
> 'modeling coords' is (x,y,z,1) and the point in device coords is
> just M * (x,y,z,1) (well, technically, for true 3d, to get
> perspective effects, you need to divide by z at this point, and you
> had to set up a funny matrix for get the perspective to work, but
> we're not doing 3d right? :-) )

And even if we were, most of it's not that hard, and as you point out,
using homogeneous coordinates (as you've suggested) makes it so that
you can represent any composition of operations as a single composite
matrix which represents a fixed computational cost, per-pixel.

However, all this said, although what you're proposing is interesting,
and is a good way to go if you're planning to work at the per-pixel
level, I'm not sure that's the best way to get what we want quickly.
The quickest approach, and the one that John was probably initially
planning was to build any new drawing operations on top of the
existing gtk/gnome-print primitives.  That means that you'll
essentially never be pushing pixels directly, and so you can't easily
interpose your own translation matrix, and you especially can't
enlarge/shrink text with your artwork, at least not using gtk's
interfaces -- perhaps gnome-print allows this.

Anyway, unless the matrix ops are interposed *below* gtk, and I don't
think gdk is structured to allow that, then you're going to be
somewhat restricted in what you can do with a matrix stack.  Granted,
you can still use it to scale the arguments you pass to gdk_draw_line,
gdk_draw_rectangle, etc, but that's about it.  There are a lot of
things it just won't effect...

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