[self-interest] Scaling in canvases

[Jecel Assumpcao Jr]

On Friday 18 June 2004 22:15, Michael Latta wrote:
> Before I run off half cocked I could use comments on the following
> observations:
>
> 1) It appears that each window has its own back buffer that gets
> damage drawn onto it.

Yes, you shouldn't count on the windowing system to handle this for you 
if you want to be portable.

> 2) When multiple users access a system they get their own windows, so
> drawing can occur once per user for the same damage area.

True. The actual windows will be in different machines, though that 
isn't important here.

> 3) I would have liked to see the canvas abstract out the buffering so
> worldMorph would not need to keep paired lists of canvases to do
> buffering.  That would also make it easier to substitute hardware or
> OS buffering.

The various windows might be showing very different areas of the 
worldMorph. Since that is infinite in extent, you probably don't want a 
single canvas covering it all.

> For my needs I would like to see a drawing subsystem that supports
> scaling (of shapes and text) with the traditional transforms
> available from one morph to the children.  If this was making use of
> hardware transformation it should not cost much, and FSAA in hardware
> only costs about 10%.  But it looks like the entire complex of
> canvas, display, and worldMorph will be impacted heavily to do this.

Earlier this year Steve Dekorte started an interesting discussion about 
redoing the graphics architecture to use OpenGL.

There is some very incomplete support for scaling (see the code in the 
radarViewMorph, for example) but nothing that can be compared to 
Balloon in Squeak Smalltalk. Given how awkwardly that is integrated 
with Morphic in that system, I would say your evaluation of the impact 
is correct.

> Has this been considered?  Was it just not the focus of the research,
> or was there a reason from the shared X11 perspective that this would
> be a bad idea?  The large work area that the Self UI supports would
> be a perfect place to add a zooming interface type control for
> navigation, rather than scrolling in 1/3 screen increments.

While early shared environment research used the multiuser features of 
Self, later work (sorry, I was going to give a reference and the names 
of those involved besides Randy Smith but Sun's site seems to have 
chopped the list of publications to a mere two or three per person) in 
Java was based on object replication. This is also the approach used in 
OpenCroquet (3D shared environment on top of Squeak) and since the Mac 
isn't too X11 friendly I think it would be best to forget this multiple 
window/single virtual machine trick.

I totally agree about the zooming. Not having scrolling is very 
claustrophobic whenever I go from Self to Squeak, but not having 
zooming in Self is almost as frustrating. Other people are working on 
this (and I also experimented with very simple hardware support for 
zooming - http://www.merlintec.com:8080/hardware/18 see October 22 
pictures), but Steve's suggestion of using 3D hardware to get the job 
done seems very reasonable.

On different subject, I would add to Brian's comments in the other 
thread saying that anybody interested in Self should take a look at 
Slate as well. The feel is very similar to the Self 1.0 days and the 
fast machines we now have make up for the simple VM implementation (but 
with great things planned for the near future). One of my favorite Self 
features, the simple and direct graphical representation of objects, is 
not so easy to have in Slate, but it is very possible that some great 
solution is just around the corner.

-- Jecel