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 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
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:
Juan Vuletich schrieb:
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
Hi Juan, working on ideas "in the open" as you do is very refreshing!
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.
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 see.
I would like to describe the coordinate system of a morph with these objects:
- 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.
I think my pair CoordinateSystem / Location allows doing this.
- 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.
- 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.
- (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
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
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:
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
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.
:)
I would like to add two comments based on my own experience.
- 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.
Ok. Anyway, I'm not rewriting PluggableMorphs, at least not right now...
- 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
/Klaus
On Tue, 31 Oct 2006 02:54:27 +0100, Juan Vuletich wrote:
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.
:)
I would like to add two comments based on my own experience.
- 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.
Ok. Anyway, I'm not rewriting PluggableMorphs, at least not right now...
- 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
squeak-dev@lists.squeakfoundation.org
-
Hans-Martin Mosner -
Juan Vuletich -
Klaus D. Witzel -
Michael Rueger -
Trygve Reenskaug