On 20 Jun 1999, Lawson English wrote:

> Bert Freudenberg <bert at isgnw.CS.Uni-Magdeburg.De> said:
> > And why would we want to have perspective distortion if we do not
> > go three-dimensional?
> 
>       Long, long ago
> In a galaxy far, far away...

That doesn't answer my question ...

> The ability to apply 3D perspective to bitmaps is trivial. WarpBlit does
> this using a quadralateral warp.

It does not do perspective corrected mapping, because the interpolation
always is linear.
 
> HOWEVER, the abilityt to apply it to vectors, especially text, and then
> edit the same AFTER the perspective has been applied, is not trivial.
> Printing the text as device-independent vectors is also not trivial. You
> need the kind of solution that I described above.

For printing, you are absolutely right.

> >[...snip...]
> >IMHO this would be too specific, the texture mapping approach is more
> >general.
> 
> And doesn't work right for text and vectors. How do you hit-test a
> selection of text if there's been a texture-mapping warp applied to it?

Project the mouse coordinates back into de-warped space and do hit
detection as usual. 
 
> The only graphics engine that does this is GX and that is going away on the
> Mac and was never implemented elsewhere.
> 
> There's several pieces missing from the Squeak graphics libraries in order
> to make your 3D morph work right:
> 
> 3D perspective for vectors & text. 3D perspective for views. Hit-testing
> methods for 2D graphics & text that work with 3D perspective.
> Text-selection methods that work with 3D perspective. Etc.

For the UI, I insist that the texture-mapping approach would work.

> In order to print these properly to PS printers, you also need to have a
> translator that can grab the original vector/text info, apply the 3D warp
> to it and translate THAT to PS.

For printing, or vector graphics in general, that is true. Until now,
there wasn't a big need to do proper printing from Squeak. It's much more
a vehicle for interaction.

> All of the above is very complex and it took Apple 7 years and a LOT of
> manhours to get right, and I'm not even suggesting that we should work to
> add these capabilities to Squeak.

I wouldn't say it's THAT hard, and it may well be worth it - who knows
what we could do if this is possible ...

> However, I *am* pointing out that the "Pure SmallTalk" approach to porting
> Squeak has certain limitations and that unless some simpler way is created
> to add and port externals than currently exists, the "pure SmallTalk"
> limitation is going to become more and more evident.

It's "Smalltalk", without a capital T :^)

/bert

-- 
 Bert Freudenberg                                       Department of 
                                                        Simulation and
                                                        Computer Graphics
 http://isgwww.cs.uni-magdeburg.de/isg/bert.html        Univ. of Magdeburg