I know I am on my own here, but the protocol for canvas supports scaling, but not the pixmapCanvas for the Mac. I will see what I can do to correct this. If it takes work in the C code I could use a pointer.
Thanks, Michael
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. 2) When multiple users access a system they get their own windows, so drawing can occur once per user for the same damage area. 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.
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.
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.
Michael
On Jun 18, 2004, at 5:24 PM, Michael Latta wrote:
I know I am on my own here, but the protocol for canvas supports scaling, but not the pixmapCanvas for the Mac. I will see what I can do to correct this. If it takes work in the C code I could use a pointer.
Thanks, Michael
Yahoo! Groups Links
On Friday 18 June 2004 22:15, Michael Latta wrote:
Before I run off half cocked I could use comments on the following observations:
- 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.
- 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.
- 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
self-interest@lists.selflanguage.org
-
Jecel Assumpcao Jr -
Michael Latta