The Weekly Juan #3: Coordinate Systems in Morphic 3.0

Hi Folks,

The Weekly Juan #3 is out at www.jvuletich.org . Today I talk about
Coordinate Systems in Morphic 3.0.

Hope you like it. Any comment is welcome, especially discussion about
the ideas and the design.

Cheers,
Juan Vuletich

Juan Vuletich schrieb: Hi Juan,
working on ideas "in the open" as you do is very refreshing!
I've got some comments on the coordinate system ideas:
I think that you're right in giving each morph its own coordinate system
For most GUI work (widgets etc.) however, I would prefer if these
coordinate systems were merely translated relative to the global
coordinate system. I fear that contemporary-style widgets don't look
well if their graphics are scaled by more or less arbitrary factors.
For document rendering, it is very good to have the arbitrary-scaling
thing built in anyway, but traditional widgets should use simple
translations by integer offsets.
This also means that I would rather keep the resizing operation, in
addition to a zooming operation. Getting consistent looks for example
for borders gets awfully complicated otherwise. If you look at the way
MVC does its transformation stuff you will see what I mean. The whole
business of computing global from local transforms, taking border widths
into account, it ridiculously complicated and error-prone. Believe me,
I've tried to fix that stuff without changing the concept too much more
than 15 years ago and failed miserably because that code is so
convoluted... When VisualsWorks introduced the current graphics
architecture everything was suddenly so much easier to get right. But
the good folks at ParcPlace did not include arbitrary transformations
(most likely due to technical constraints in the rendering systems of
the supported platforms), and this needlessly complicates some
applications such as zooming of documents.

I would like to describe the coordinate system of a morph with these
objects:
1. A 2D transformation which transforms points in the morph's own
coordinate system into points in its parent's coordinate system. The
point 0@0 within its own coordinate system would be its position within
the parent. I deliberately do not use the terms "center" since for
different morphs it might have a different meaning. For example, for
lines of text, the X axis of the local coordinate system would be the
baseline. Typical X-Y diagrams would use the intersection of X and Y
axis, while most traditional GUI widgets would probably use their upper
left corner.
2. A rectangle in local coordinates describing the "bounds" of the
morph. Most morphs would not draw outside of this box. Typical
exceptions are character glyphs, morphs with graphical indicators for
focus or defaultness (as in Motif), and of course morphs with components
which are outside of their bounds.
3. For rendering optimization and hit testing, a "total bounds"
rectangle which encompasses all areas in which a morph and its submorphs
could possibly render.
4. (Optional, maybe only needed by some morphs) a clipping area which is
used to restrict rendering of the morph itself and especially its
submorphs. BalloonCanvas probably does not support this well, though.

For working with coordinates, generalized 2D transformations are much
more powerful than combinations of translations, scaling factors, and
rotation angles. They can easily be composed to compute global
transformations from local ones. One thing that must be done with
special care is the correct transformation of line widths, patterns, etc.
A first implementation using Balloon can probably be done, but some fine
details might only be doable right with a framework such as Cairo where
others have already put a lot of work into getting things right. Don't
get me wrong - I'd prefer to have everything done within Squeak to be
independent of external libraries as far as possible, but even though
the Squeak community has a lot of really bright folks, our resources are
ultimately limited, so doing everything ourselves is not always feasible.

Cheers,
Hans-Martin

Hi Hans-Martin,

Hans-Martin Mosner wrote: Thanks. It's nice to see your interest!
> I've got some comments on the coordinate system ideas:
> I think that you're right in giving each morph its own coordinate system
>  
Cool.
> For most GUI work (widgets etc.) however, I would prefer if these
> coordinate systems were merely translated relative to the global
> coordinate system. I fear that contemporary-style widgets don't look
> well if their graphics are scaled by more or less arbitrary factors.
> For document rendering, it is very good to have the arbitrary-scaling
> thing built in anyway, but traditional widgets should use simple
> translations by integer offsets.
>  
Well, with Windows Vista, and such I guess this will change pretty soon.
Everybody will be crazy about vector-graphics widgets.
Anyway, I was thinking on including the behavior you describe as an
option. Perhaps I should include NonZoomingMorph class or such to be the
root of the hierarchy of these.
> This also means that I would rather keep the resizing operation, in
> addition to a zooming operation. Getting consistent looks for example
> for borders gets awfully complicated otherwise.
Yes. But I think having  both operations could be confused. The
NonZoomingMorph hierarchy should have resize but not zoom.
And perhaps a subhierarchy is not needed. It should be enough with using
a new kind of Location and a new kind of CoordinateSystem. These morphs
perhaps should not be rotated too. I see. I think my pair CoordinateSystem / Location allows doing this.
> 2. A rectangle in local coordinates describing the "bounds" of the
> morph. Most morphs would not draw outside of this box. Typical
> exceptions are character glyphs, morphs with graphical indicators for
> focus or defaultness (as in Motif), and of course morphs with components
> which are outside of their bounds.
>  
This are the height/width ivars in Location.
> 3. For rendering optimization and hit testing, a "total bounds"
> rectangle which encompasses all areas in which a morph and its submorphs
> could possibly render.
>  
My Morph class, as in standard Morphic, has an extra ivar for this named
fullBounds. However, I'd be happier if I could remove it.
> 4. (Optional, maybe only needed by some morphs) a clipping area which is
> used to restrict rendering of the morph itself and especially its
> submorphs. BalloonCanvas probably does not support this well, though.
>
>  
This is a good idea.
> For working with coordinates, generalized 2D transformations are much
> more powerful than combinations of translations, scaling factors, and
> rotation angles. They can easily be composed to compute global
> transformations from local ones. One thing that must be done with
> special care is the correct transformation of line widths, patterns, etc.
>  
Note that the default behavior is to scale line widths as well.
> A first implementation using Balloon can probably be done, but some fine
> details might only be doable right with a framework such as Cairo where
> others have already put a lot of work into getting things right. Don't
> get me wrong - I'd prefer to have everything done within Squeak to be
> independent of external libraries as far as possible, but even though
> the Squeak community has a lot of really bright folks, our resources are
> ultimately limited, so doing everything ourselves is not always feasible.
>
>  
Currently I'm using Balloon. The new framework is very young yet.
However, if at some time, I clearly see the advantage of using Cairo, it
should be simple to switch. However note that neither Balloon nor Cairo
fully support arbitrary transform. If the transform is non linear, I'll
have to do the drawing by hand.
> Cheers,
> Hans-Martin
>  
Cheers,
Juan Vuletich

Juan,
Many thanks for your open discussion. Hans-Martin has given well-founded
comments. There is a lot of solid experience in them that I recognize
and that should be useful in your work.

I would like to add two comments based on my own experience.

1) I underestimated the geometric complexity of even a simple window -
until I drew ALL the relevant rectangles in a scrollable text editor. (I
believe I have the report somewhere, but can't find it). There were the
outer view rectangles outside and inside the border. Then the scrollbar
with all its details. The text viewport outside and inside the border,
and the text view itself. The problem was that every rectangle was
handled and even named somewhere in the code. Hap-hazard naming lead to
an abundance of synonyms and homonyms which made it hard to find and fix
the many bugs. Much grief would have been avoided if naming had been
taken seriously from the very start. The complexity of the ST80 code is
partly caused by naming problems but mainly, I believe, by complexity
inherent in the task.

2) An off-by-one error is very visible on the screen and very
irritating. We once used floats for certain coordinates. Accumulating
errors caused problems even after we changed to double precision floats.
On the other hand, I believe Display PostScript  (and PS itself) uses
float coordinates? If so, it could be worth while to look into how users
of DPS protect against cumulating errors.
(See  http://en.wikipedia.org/wiki/Display_PostScript )

Cheers
--Trygve

On 29.10.2006 19:16, Juan Vuletich wrote:

--

Trygve Reenskaug      mailto: [hidden email]
Morgedalsvn. 5A       http://heim.ifi.uio.no/~trygver
N-0378 Oslo           Tel: (+47) 22 49 57 27
Norway

Hi Trygve,

Trygve Reenskaug escribió:
> Juan,
> Many thanks for your open discussion. Hans-Martin has given
> well-founded comments. There is a lot of solid experience in them that
> I recognize and that should be useful in your work.
:) Ok. Anyway, I'm not rewriting PluggableMorphs, at least not right now...
> 2) An off-by-one error is very visible on the screen and very
> irritating. We once used floats for certain coordinates. Accumulating
> errors caused problems even after we changed to double precision
> floats. On the other hand, I believe Display PostScript  (and PS
> itself) uses float coordinates? If so, it could be worth while to look
> into how users of DPS protect against cumulating errors.
> (See  http://en.wikipedia.org/wiki/Display_PostScript )
Well, Floats accumulate a lot less error than integers...
>
> Cheers
> --Trygve
Cheers,
Juan Vuletich

Hi Juan,

when it comes to the obstacles of computability and complexity over  
real-valued data, you might perhaps be interested in

- http://cca-net.de/cca2007/

/Klaus

On Tue, 31 Oct 2006 02:54:27 +0100, Juan Vuletich wrote:

Hans-Martin Mosner wrote:

> A first implementation using Balloon can probably be done, but some fine
> details might only be doable right with a framework such as Cairo where
> others have already put a lot of work into getting things right. Don't
> get me wrong - I'd prefer to have everything done within Squeak to be
> independent of external libraries as far as possible, but even though
> the Squeak community has a lot of really bright folks, our resources are
> ultimately limited, so doing everything ourselves is not always feasible.

When you look at the Rome package we took care to both support a Squeak
native, based on Balloon, and a Cairo backend.
The APIs between the old Canvases and Rome are sufficiently different,
so porting later might not be as easy as you think.

In Sophie we do all our document drawing using Rome. We do actually use
integer coordinates though, based on cTwips (127th of a Twip). As this
provides a very high resolution we yet have to see rounding artifacts
that we wouldn't also see with floats.

Just MTC

Michael