Hi Juan,
Two thought have just come together and I am excited. >From morphic 3.o I was looking at the ivars for Location and comparing them to problems I've been working thru with making polygons tilt just like rectanges and ellipses. The problem I noticed with Location was that you had angle but no scale. >From my work with polygons I know that angle and scale are natural partners. xextent and yextent are not substitutes. Indeed they cause ambiguity because unless you look at the works you wonder if you turn the morph first then apply the extent scalers or the other way around. What I found was in any given operation you had to choose rotate and scale or stretch and reflect (That's what should happen when one of the extent scalers go negative) The other decision I realized from my work with polygons was to get polygons to truely rotate (with their submorphs doing the same thing) I had to collect the submorphs refernce locations and subject them to the same transformation as the polygon (rotate and scale or stretch and reflect) So the insight as I put your work and mine together came in the form of a question: Do morphs have locations or do locations have morphs? Yours in curiosity and service, --Jerome Peace ____________________________________________________________________________________ Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. http://mobile.yahoo.com/go?refer=1GNXIC _______________________________________________ Morphic mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/morphic |
Hi Jerome!
I'm so glad you're looking at my work! Please note that my current email is the sender of this message, [hidden email]. The addresses @uolsinectis are no longer in use. The rest of the answer is inline with your comments. Jerome Peace escribió: > Hi Juan, > > Two thought have just come together and I am excited. > :) > >From morphic 3.o I was looking at the ivars for > Location > and comparing them to problems I've been working thru > with making polygons tilt just like rectanges and > ellipses. > > The problem I noticed with Location was that you had > angle but no scale. > > >From my work with polygons I know that angle and scale > are natural partners. > i.e. the size when scale is 1. I think that rotating an object is something natural in the real world, but applying a scale factor is not. What would be the meaning for a scale factor in M3 morphs? > xextent and yextent are not substitutes. Indeed they > cause ambiguity because unless you look at the works > you wonder if you turn the morph first then apply the > extent scalers or the other way around. > In my opinion, rotating an object does not change width and height. Let's suppose you have a morph with angle zero. You adjust the width to be w1 and the height to be h1. The width w1 is measured along the X axis of the owner and the height h1 is measured along the Y axis of the owner. Then we rotate the morph, for example, by 30 degrees. If we measure the extent along the X axis of the owner, it is no longer w1, and the extent along the Y axis is no longer h1. However, these are not the width and height of the morph, which are the same as before. In other words: my height is about 5'6". If I lay on a bed, my height is not 1'. It is the same as before. Do you agree? > What I found was in any given operation you had to > choose rotate and scale > or > stretch and reflect (That's what should happen when > one of the extent scalers go negative) > > I don't understand this. Please elaborate. > The other decision I realized from my work with > polygons was to get polygons to truely rotate (with > their submorphs doing the same thing) I had to collect > the submorphs refernce locations and subject them to > the same transformation as the polygon (rotate and > scale or stretch and reflect) > Well, this is not needed in M3, as the location is always relative to the owner. If you change the ivar angle in the location in the owner, all the submorphs rotate correctly. You can try it yourself in my image, with the halo. > So the insight as I put your work and mine together > came in the form of a question: > > Do morphs have locations or do locations have morphs? > > Interesting. I always thought that morphs have locations. What would be the consequences of the other point of view? > Yours in curiosity and service, --Jerome Peace > > Cheers, Juan Vuletich _______________________________________________ Morphic mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/morphic |
Hi Juan,
Cool. Thanks for listening. I've actually followed progress to know how much you advanced things. (Real time performance and the color background fix. Great steady progress.) I am using things on an old 400hz iMac running OS9.1. I'm using one of JMM's old macClassic vms. So I need to find out if you changed anything in th vm you distribute with the system? I can try somethings that blow my mac out to the water complete with the macbomb system crash box. That only happened while using a low memory allocation. I'm having better luck when I give the vm more room. I am about to try your new addr. If this doesn't bounce then were golden. The last try missed probably due to some typing on my part. --- Juan Vuletich <[hidden email]> wrote: > Hi Jerome, > > I got the message, but this address could die > anytime, as I'm no longer > paying for it. My current primary address is > [hidden email] > (personal). I also read [hidden email] > (university) and > [hidden email] (work). > > I have already changed the name of the image, > changes and sources. They > are now simply Morphic3. You are right that I should > add some numeric > suffix or similar each time I update the ftp. Will > do it. Thanks! > > Cheers, > Juan Vuletich > > Jerome Peace escribió: > > Hi Juan > > > > I just downloaded the most recent NewMorphic. > > > > I haven't played with it yet but I do have a > > suggestion. > > > > I keep old images around for historical reseach. > Or > > just my general cluttered style. > > > > It would be helpful if the images were easily > > distinguishable by name or release number. > > > > All the NewMorphic images go by > > Squeak3.7-5989-basic.image > > which means they can get confused with each other > or > > with my historic copys of 3.7. > > > > I usually put them in a directory and call the > > directory something unique (like NewMorphic070619) > > with the digits standing for yymmdd for the date I > > downloaded it. > > > > Whatever you use to distinguish version is less > > important than that they be distinguishable. > > > > That way when someone gives you feedback they can > > quickly refer to the correct image. > > > > Yours in curiosity and service, --Jerome Peace > > > > P.S. I hope this gets to you. This is my old > address > > for you. I tried sending to your new one but that > > bounced. > > > > ____________________________________________________________________________________ Get the free Yahoo! toolbar and rest assured with the added security of spyware protection. http://new.toolbar.yahoo.com/toolbar/features/norton/index.php _______________________________________________ Morphic mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/morphic |
In reply to this post by Juan Vuletich-4
Do morphs have locations or do locations have morphs?
Actually the answer I came up with was that each has the other. Morphs don't have submorphs they have locations (this makes them resemble very much a polygon morph.) Locations in turn have morphs (for which they are a reference point.) This shift in thinking melts a ton of problems that morphic ran into. Including flex morphs. So each location is in a morph (or more precisely its coordinate system. That is the locations reference morph. So each morph is at a location in higher submorph. assertions " each location in a most one morph" "a morph can't be in two places at the same time" "a location is a sublocation of its owner" " each location in a morph belongs to that morph." also: "more that one morph may share a location." "locations must be appropriate to their owners co-ordinate system." Essentially morphs and locations alternate in a heirarchy tree. You could have a morph with bare locations. In which case it might display like a polygon would (one of my fancier ones see: http://209.143.91.36/super/724 PolyFix02-wiz). Now I suspect doubling the depth of the tree will slow the works down but this is too early in the process to be concerned about speed. And if things work right then they can be tweaked to speed things along. The great advantage is the conceptual simplicity. And the rightness of the model from a real world point of view. Yours in curiosity and service, --Jerome Peace ____________________________________________________________________________________ Need Mail bonding? Go to the Yahoo! Mail Q&A for great tips from Yahoo! Answers users. http://answers.yahoo.com/dir/?link=list&sid=396546091 _______________________________________________ Morphic mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/morphic |
In reply to this post by Juan Vuletich-4
--- Juan Vuletich <[hidden email]> wrote: > Hi Jerome! > > I'm so glad you're looking at my work! > > Jerome Peace escribió: > > Hi Juan, > > > > Two thought have just come together and I am > excited. > > > :) > > >From morphic 3.o I was looking at the ivars for > > Location > > and comparing them to problems I've been working > thru > > with making polygons tilt just like rectanges and > > ellipses. > > > > The problem I noticed with Location was that you > had > > angle but no scale. > > > > >From my work with polygons I know that angle and > scale > > are natural partners. > > > Well, having scale means that somewhere you also > have the natural size, > i.e. the size when scale is 1. I think that rotating > an object is > something natural in the real world, but applying a > scale factor is not. Hmm. What I am using for inspiration is the contrast between the yellow growth handle on morphs and the outer handle on a star morph. With a star as you use the outer handle, the invariable is the shape. The parts stay the same relative to each other but the scale and the angle may both change. This is a really useful transformation. It allows you to have all sorts of objects of similar shape but different scale and orientation. It is done by matching the scale and angle to the polar coordinates of the vector from center to outer handle. The yellow growth handle on the other hand affects the aspect ratio of x and y coordinates. If left completely unfettered you would have a morph transform (around its reference point) in response to the x and y magnitude (and sign) of the vector from reference point to yellow handle. The two interpertations of the vector are mutually exclusive though they can overlap. You could constrain the growth handle to just scale (as the orange handle does). With the yellow handle presently there are limits put on the range of growth and shrinkage. The blue handle is similar to the stars outer handle but constrains the rotation of morphs to maintain the same size. A rotated morph can only be scaled (orange handle) it can no longer be stretched. > What would be the meaning for a scale factor in M3 > morphs? angle and scale would belong to the location. xaspect and yaspect would not belong to location but be a parameter of a cartesian coordinate system. In my conception I would have a class of orthogonal coordinates which would have points coded in the range -1 <=coord<=+1 then multiply by and coord aspect. so the aspects could both be 0.5 and you would get your unit square. or they could be some other aspect ratio. In manipulating the morph you could put a yellow handle to adjust (stretch) the aspect ratio of the coord system. Circles become ellipses. Squares become rectangles. The yellow handle growth would not affect the angle and it would always (for cartesian coords) apply to the coord system. Furthmore you could honor negative aspects as directions to reflect one or more axes. > > xextent and yextent are not substitutes. Indeed > they > > cause ambiguity because unless you look at the > works > > you wonder if you turn the morph first then apply > the > > extent scalers or the other way around. > > > In my opinion, rotating an object does not change > width and height. > Let's suppose you have a morph with angle zero. You > adjust the width to > be w1 and the height to be h1. The width w1 is > measured along the X axis > of the owner and the height h1 is measured along the > Y axis of the > owner. Then we rotate the morph, for example, by 30 > degrees. If we > measure the extent along the X axis of the owner, it > is no longer w1, > and the extent along the Y axis is no longer h1. > However, these are not > the width and height of the morph, which are the > same as before. In > other words: my height is about 5'6". If I lay on a > bed, my height is > not 1'. It is the same as before. Do you agree? It would depend on whether you had this-end-up stamped on your forehead or along your left arm. :-) In the reference system you take with you to bed its one way. In the reference system gravity supplies to the world its the other. And looked at from a more distant reference it will change in 6 hours time while you sleep. The bug in morphic is that the words we use can't distinguish. When I rotate a polygon, Its submorphs stay in their upright orientation and translate with respect to the changing #topLeft boundry point. When I rotate an image or a rectangle all the submorphs rotate around their refpoints which in turn rotate around the rectangles reference point. When I set out to fix the difference I came to the understanding that rotate and scale which must maintain the aspect ratio of things, differ from stretch and reflect which can change the aspect ratio of things but must maintain the orientation. The way they are done now (with stretch implemented by extent:) rotation and stretch are not commutative operations. You can see this with polygons most easily. What I've been striving for is elegance and the lack of limitations on transform operations. And that starts to come when I recognise that I can ask for rotate and scale in the same manipulation. Or I can ask for stretch/reflect at the same time. But I cannot mix the two. So seeing the ivars for location the lack of the scale ivar jumped out. As did the presence of the aspect ivars clearly there to facilitate scale. Aspect belongs to the coord system. Even though aspect and scale can overlap achieving generality is eased when they are both present and can be treated separately. > > What I found was in any given operation you had to > > choose rotate and scale > > or > > stretch and reflect (That's what should happen > when > > one of the extent scalers go negative) > > > > > I don't understand this. Please elaborate. > > The other decision I realized from my work with > > polygons was to get polygons to truely rotate > (with > > their submorphs doing the same thing) I had to > collect > > the submorphs refernce locations and subject them > to > > the same transformation as the polygon (rotate and > > scale or stretch and reflect) > > > Well, this is not needed in M3, as the location is > always relative to > the owner. If you change the ivar angle in the > location in the owner, > all the submorphs rotate correctly. You can try it > yourself in my image, > with the halo. I did. That's why I know you are on the right track. I believe there is a very easy way of doing morphic which people didn't see at first. We can see farther because we stand on the shoulders of giants. :-) Yours in curiosity and service, --Jerome Peace ____________________________________________________________________________________ Pinpoint customers who are looking for what you sell. http://searchmarketing.yahoo.com/ _______________________________________________ Morphic mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/morphic |
In reply to this post by Jerome Peace
Hi Jerome,
Jerome Peace escribió: > Hi Juan, > > Cool. > > Thanks for listening. > > I've actually followed progress to know how much you > advanced things. (Real time performance and the color > background fix. Great steady progress.) > > > I am using things on an old 400hz iMac running OS9.1. > I'm using one of JMM's old macClassic vms. So I need > to find out if you changed anything in th vm you > distribute with the system? > > Not at all. I should delete the VM from the zip file. It is misleading. Ok. Done. So, you are doing a serious performance test there! Unfortunately, the Morphic 3 stuff uses Floats for coordinates, and I haven't worked on performance yet, so everything should be slow... > I can try somethings that blow my mac out to the water > complete with the macbomb system crash box. That only > happened while using a low memory allocation. I'm > having better luck when I give the vm more room. > I believe the same should happen with any Squeak image, right? > I am about to try your new addr. If this doesn't > bounce then were golden. > > Yep, here I am. > The last try missed probably due to some typing on my > part. > Now I'm working on scrolling and clipping. I hope to publish something soon. Cheers, Juan Vuletich _______________________________________________ Morphic mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/morphic |
In reply to this post by Jerome Peace
Jerome Peace escribió:
> Do morphs have locations or do locations have morphs? > > Actually the answer I came up with was that each has > the other. > > Morphs don't have submorphs they have locations (this > makes them resemble very much a polygon morph.) > Locations in turn have morphs (for which they are a > reference point.) > > This shift in thinking melts a ton of problems that > morphic ran into. Including flex morphs. > > So each location is in a morph (or more precisely its > coordinate system. That is the locations reference > morph. > > So each morph is at a location in higher submorph. > > > assertions > > " each location in a most one morph" > "a morph can't be in two places at the same time" > "a location is a sublocation of its owner" > " each location in a morph belongs to that morph." > > also: > "more that one morph may share a location." > "locations must be appropriate to their owners > co-ordinate system." > > Essentially morphs and locations alternate in a > heirarchy tree. > > Here is an implementation difference. To me, a location is an ivar in a Morph. > You could have a morph with bare locations. In which > case it might display like a polygon would (one of my > fancier ones see: > http://209.143.91.36/super/724 > PolyFix02-wiz). > > Now I suspect doubling the depth of the tree will slow > the works down but this is too early in the process to > be concerned about speed. And if things work right > then they can be tweaked to speed things along. > > The great advantage is the conceptual simplicity. And > the rightness of the model from a real world point of > view. > > > Yours in curiosity and service, --Jerome Peace > > of doing as I did. I also think that M3 is conceptually "right". What problems do you see in M3? I saw PolyFix02-wiz. I like the WizagonMorph behavior. It is the one I believe correct. I you look at M3, my morphs rotate the same way, but resize slightly differently. With my implementation of coordinate systems, the code is much simpler, there's no need to go down every submorph to fix its location. Please play a while with my TestMorphs. Cheers, Juan Vuletich _______________________________________________ Morphic mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/morphic |
In reply to this post by Jerome Peace
Hi Jerome,
Jerome Peace escribió: > --- Juan Vuletich <[hidden email]> wrote: > > >> Hi Jerome! >> >> I'm so glad you're looking at my work! >> >> Jerome Peace escribió: >> >>> Hi Juan, >>> >>> Two thought have just come together and I am >>> >> excited. >> >>> >>> >> :) >> >>> >From morphic 3.o I was looking at the ivars for >>> Location >>> and comparing them to problems I've been working >>> >> thru >> >>> with making polygons tilt just like rectanges and >>> ellipses. >>> >>> The problem I noticed with Location was that you >>> >> had >> >>> angle but no scale. >>> >>> >From my work with polygons I know that angle and >>> >> scale >> >>> are natural partners. >>> >>> >> Well, having scale means that somewhere you also >> have the natural size, >> i.e. the size when scale is 1. I think that rotating >> an object is >> something natural in the real world, but applying a >> scale factor is not. >> > > Hmm. What I am using for inspiration is the contrast > between the yellow growth handle on morphs and the > outer handle on a star morph. > > With a star as you use the outer handle, the > invariable is the shape. The parts stay the same > relative to each other but the scale and the angle may > both change. > > This is a really useful transformation. It allows you > to have all sorts of objects of similar shape but > different scale and orientation. > > It is done by matching the scale and angle to the > polar coordinates of the vector from center to outer > handle. > > > The yellow growth handle on the other hand affects the > aspect ratio of x and y coordinates. If left > completely unfettered you would have a morph transform > (around its reference point) in response to the x and > y magnitude (and sign) of the vector from reference > point to yellow handle. > > The two interpertations of the vector are mutually > exclusive though they can overlap. You could constrain > the growth handle to just scale (as the orange handle > does). > > "scale". With the star outer handle it is hard to do just rotation or just rescale. But I believe the default should be to keep the aspect ratio. Perhaps a modifier key could allow changing it. > With the yellow handle presently there are limits put > on the range of growth and shrinkage. > > The blue handle is similar to the stars outer handle > but constrains the rotation of morphs to maintain the > same size. A rotated morph can only be scaled (orange > handle) it can no longer be stretched. > > > think this is confusing. I believe the default operation is scaling. That is the the yellow handle does in morphic 3: change the space the morph occupies in its owner, but do not change the morph real (or internal) size, that is, its own coordinate system. Only some special morphs (currently none) will support scrolling and a new operation that zooms the morph's contents, but not its external size, i.e. the extent in the location (to make scrolling necessary). On those morphs, there will be yet another new operation that changes both the external extent and the internal scale factor, to keep constant the apparent size of the contents. For example, for a text editor, where resizing it does not change the size of the text. Forgive me if I'm not clear enough on this. I'll write a TWJ (the weekly juan) on this when it starts working. This is related to http://www.jvuletich.org/issues/Issue0009.htm but my ideas changed quite a bit since then, thanks to feedback from Bert and Tim. >> What would be the meaning for a scale factor in M3 >> morphs? >> > > angle and scale would belong to the location. > > xaspect and yaspect would not belong to location but > be a parameter of a cartesian coordinate system. > In my conception I would have a class of orthogonal > coordinates which would have points coded in the range > -1 <=coord<=+1 then multiply by and coord aspect. > > so the aspects could both be 0.5 and you would get > your unit square. or they could be some other aspect > ratio. > particular to [-1, ..1] x [-1, .. 1]. To be as general as possible on this, I allow nonlinear coordinate systems too. I want to use "real world" coordinates. For example, if I have a morph that represents the map of Argentina, the "x" (longitude) could go from 80 west to 48 west, and the "y" (latitude) could go from 56 south to 20 south or something. This coordinate system (the one that is good for plotting a map of Argentina) is specified by the bounds of the coordinates (the valid coordinate values) and the transformation it does to a cartesian system, i.e. the kind of projection. If you see it this way, it doesn't make sense to modify the coordinate system just to stretch the map. The coordinate system is exactly the same. All that changes is the extent it will use in its owner (the sheet of paper where it is drawn). Thats why I consider the coordinate system something intrinsic of the morph, part of its definition, and I consider the location an "accident" something that happens to be the way it is, but could change without affecting the essence of the morph. > In manipulating the morph you could put a yellow > handle to adjust (stretch) the aspect ratio of the > coord system. Circles become ellipses. Squares become > rectangles. The yellow handle growth would not affect > the angle and it would always (for cartesian coords) > apply to the coord system. Furthmore you could honor > negative aspects as directions to reflect one or more > axes. > > >>> xextent and yextent are not substitutes. Indeed >>> >> they >> >>> cause ambiguity because unless you look at the >>> >> works >> >>> you wonder if you turn the morph first then apply >>> >> the >> >>> extent scalers or the other way around. >>> >>> >> In my opinion, rotating an object does not change >> width and height. >> Let's suppose you have a morph with angle zero. You >> adjust the width to >> be w1 and the height to be h1. The width w1 is >> measured along the X axis >> of the owner and the height h1 is measured along the >> Y axis of the >> owner. Then we rotate the morph, for example, by 30 >> degrees. If we >> measure the extent along the X axis of the owner, it >> is no longer w1, >> and the extent along the Y axis is no longer h1. >> However, these are not >> the width and height of the morph, which are the >> same as before. In >> other words: my height is about 5'6". If I lay on a >> bed, my height is >> not 1'. It is the same as before. Do you agree? >> > > It would depend on whether you had this-end-up stamped > on your forehead or along your left arm. :-) > > In the reference system you take with you to bed its > one way. In the reference system gravity supplies to > the world its the other. And looked at from a more > distant reference it will change in 6 hours time while > you sleep. > > Well, I see it is needed to make a decision here. I believe it is simpler to ignore the reference system and just focus on the morph (or my body in this example). > The bug in morphic is that the words we use can't > distinguish. > > When I rotate a polygon, Its submorphs stay in their > upright orientation and translate with respect to the > changing #topLeft boundry point. > > When I rotate an image or a rectangle all the > submorphs rotate around their refpoints which in turn > rotate around the rectangles reference point. > > When I set out to fix the difference I came to the > understanding that rotate and scale which must > maintain the aspect ratio of things, differ from > stretch and reflect which can change the aspect ratio > of things but must maintain the orientation. > > The way they are done now (with stretch implemented by > extent:) rotation and stretch are not commutative > operations. You can see this with polygons most > easily. > > What I've been striving for is elegance and the lack > of limitations on transform operations. And that > starts to come when I recognise that I can ask for > rotate and scale in the same manipulation. Or I can > ask for stretch/reflect at the same time. But I cannot > mix the two. > > morph (its extent expressed in its own coordinate system) from the accidental (position, angle, "zoom"). I believe you think that rotate and scale don't change the morph (that's why the contens rotates and scales as a whole). But I don't see how you view stretch / reflect. Do they change the morph? Do you think they are operations we can perform on any object in the real world? It would be great if you try to experiment with this in M3. > So seeing the ivars for location the lack of the scale > ivar jumped out. As did the presence of the aspect > ivars clearly there to facilitate scale. Aspect > belongs to the coord system. Even though aspect and > scale can overlap achieving generality is eased when > they are both present and can be treated separately. > > I hope my view on coordinate systems (i.e. the map of Argentina) above is clear enough on this. >>> What I found was in any given operation you had to >>> choose rotate and scale >>> or >>> stretch and reflect (That's what should happen >>> >> when >> >>> one of the extent scalers go negative) >>> >>> >>> >> I don't understand this. Please elaborate. >> >>> The other decision I realized from my work with >>> polygons was to get polygons to truely rotate >>> >> (with >> >>> their submorphs doing the same thing) I had to >>> >> collect >> >>> the submorphs refernce locations and subject them >>> >> to >> >>> the same transformation as the polygon (rotate and >>> scale or stretch and reflect) >>> >>> >> Well, this is not needed in M3, as the location is >> always relative to >> the owner. If you change the ivar angle in the >> location in the owner, >> all the submorphs rotate correctly. You can try it >> yourself in my image, >> with the halo. >> > > I did. That's why I know you are on the right track. > > > I believe there is a very easy way of doing morphic > which people didn't see at first. We can see farther > because we stand on the shoulders of giants. :-) > > Yours in curiosity and service, --Jerome Peace > Indeed. BTW, John Maloney himself said (in the SqueakNews interview) that rotation and flexing were added as aftethoughts, and that a reimplementation where each morph defined its own coordinate system was needed. Cheers, Juan Vuletich _______________________________________________ Morphic mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/morphic |
In reply to this post by Jerome Peace
On Thu, Jun 21, 2007 at 01:36:09PM -0700, Jerome Peace wrote:
> assertions > > " each location in a most one morph" This assertion appears to conflict with > "a location is a sublocation of its owner" and > "more that one morph may share a location." if one is using world-relative locations. Is this not the case? What is a location? Parent morph + relative 2d location? Also, what is in a Parent morph? location + rotation + shear + scale? or is there some more general transform system that could handle funky stuff like jiggly morphs, or allow morphs to be 2.5d? That would be nice. -- Matthew Fulmer -- http://mtfulmer.wordpress.com/ Help improve Squeak Documentation: http://wiki.squeak.org/squeak/808 _______________________________________________ Morphic mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/morphic |
In reply to this post by Jerome Peace
--- Juan Vuletich <[hidden email]> wrote: > Hi Jerome, > > Jerome Peace escribió: > > Hi Juan, > > > > Cool. > > > > Thanks for listening. > > > > I've actually followed progress to know how much > you > > advanced things. (Real time performance and the > color > > background fix. Great steady progress.) > > > > > :) Thanks. > > I am using things on an old 400hz iMac running > OS9.1. > > I'm using one of JMM's old macClassic vms. So I > need > > to find out if you changed anything in th vm you > > distribute with the system? > > > > > Not at all. I should delete the VM from the zip > file. It is misleading. > Ok. Done. > So, you are doing a serious performance test there! > Unfortunately, the > Morphic 3 stuff uses Floats for coordinates, and I > haven't worked on > performance yet, so everything should be slow... Actually the iMac is well designed and the performance is responsive. I can resize the example at about the same speed as I am used to. Of Course there not a lot else going on at the same time. So its not much of a burden. The real problem is I can usually find things that bring everything to a screeching halt within 15 minutes. The copy handle is good for that. The balloon engine is probably the reason for the speed. Two or three version ago I did give up because things were too slow. The system is slow when not just displaying your morphs. Bringing up a browser or an inspector feels like it takes forever (compared to what I'm used to. lol). The balloon engine is also probably responsible for the clipping bugs. It has some very bad rounding errors in it. A lot bugs which I'm good enough to find but not knowledgable enough to fix. > > I can try somethings that blow my mac out to the > water > > complete with the macbomb system crash box. That > only > > happened while using a low memory allocation. I'm > > having better luck when I give the vm more room. > > > I believe the same should happen with any Squeak > image, right? > Now I'm working on scrolling and clipping. I hope to > publish something soon. Cool. I'll keep following your progress. Yours in curiosity and service, --Jerome Peace ____________________________________________________________________________________ Yahoo! oneSearch: Finally, mobile search that gives answers, not web links. http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC _______________________________________________ Morphic mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/morphic |
In reply to this post by Juan Vuletich-4
Juan
did you check the unit used in Sophie. Because told me that their units are quite good. Stef On 22 juin 07, at 03:11, Juan Vuletich wrote: > Hi Jerome, > > Jerome Peace escribió: >> Hi Juan, >> >> Cool. >> >> Thanks for listening. >> I've actually followed progress to know how much you >> advanced things. (Real time performance and the color >> background fix. Great steady progress.) >> >> > :) Thanks. >> I am using things on an old 400hz iMac running OS9.1. >> I'm using one of JMM's old macClassic vms. So I need >> to find out if you changed anything in th vm you >> distribute with the system? >> > Not at all. I should delete the VM from the zip file. It is > misleading. > Ok. Done. > So, you are doing a serious performance test there! Unfortunately, the > Morphic 3 stuff uses Floats for coordinates, and I haven't worked on > performance yet, so everything should be slow... >> I can try somethings that blow my mac out to the water >> complete with the macbomb system crash box. That only >> happened while using a low memory allocation. I'm >> having better luck when I give the vm more room. >> > I believe the same should happen with any Squeak image, right? >> I am about to try your new addr. If this doesn't >> bounce then were golden. >> >> > Yep, here I am. >> The last try missed probably due to some typing on my >> part. >> > Now I'm working on scrolling and clipping. I hope to publish > something soon. > > Cheers, > Juan Vuletich > > _______________________________________________ > Morphic mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/morphic _______________________________________________ Morphic mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/morphic |
In reply to this post by Jerome Peace
Hi Jerome,
Jerome Peace escribió: > >> performance yet, so everything should be slow... >> > > Actually the iMac is well designed and the performance > is responsive. I can resize the example at about the > same speed as I am used to. Of Course there not a lot > else going on at the same time. So its not much of a > burden. The real problem is I can usually find things > that bring everything to a screeching halt within 15 > minutes. The copy handle is good for that. > > The balloon engine is probably the reason for the > speed. Two or three version ago I did give up because > things were too slow. > > The system is slow when not just displaying your > morphs. Bringing up a browser or an inspector feels > like it takes forever (compared to what I'm used to. > lol). > > The balloon engine is also probably responsible for > the clipping bugs. It has some very bad rounding > errors in it. A lot bugs which I'm good enough to find > but not knowledgable enough to fix. > > > for that in M3. WRT Balloon, it is great. It is fast and it is there. I know it has bugs, but now I'm focusing on the morph themselves. It is good to have balloon around to get morphs working. Later, maybe it could be replaced by Cairo as in Sophie. Or perhaps we can enhance Balloon. Or use some other engine. Neither Ballon nor Cairo are the final solution for M3 because they only support affine (i.e. linear) transforms. Cheers, Juan Vuletich _______________________________________________ Morphic mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/morphic |
In reply to this post by Stéphane Ducasse-3
Hi Stef,
You suggested that to me some time ago and I did. Sophie uses smallintegers for coordinates. This is ok for books, to go from printer pixels to books of several kilometers. But I want float coordinates and multiple nonlinear coordinate systems in the same world. I don't want to be restricted to Cartesian with a single scale all over the system. In a morph, the number 3 could mean 3 milimeters, and in another it could mean 3 astronomic unit (mean distance from the earth to the sun), or 3 degrees of latitude north, or 3 db or whatever. Cheers, Juan Vuletich Stéphane Ducasse escribió: > Juan > > did you check the unit used in Sophie. Because told me that their > units are quite good. > > Stef > > > On 22 juin 07, at 03:11, Juan Vuletich wrote: > >> Hi Jerome, >> >> Jerome Peace escribió: >>> Hi Juan, >>> >>> Cool. >>> >>> Thanks for listening. >>> I've actually followed progress to know how much you >>> advanced things. (Real time performance and the color >>> background fix. Great steady progress.) >>> >>> >> :) Thanks. >>> I am using things on an old 400hz iMac running OS9.1. >>> I'm using one of JMM's old macClassic vms. So I need >>> to find out if you changed anything in th vm you >>> distribute with the system? >>> >> Not at all. I should delete the VM from the zip file. It is misleading. >> Ok. Done. >> So, you are doing a serious performance test there! Unfortunately, the >> Morphic 3 stuff uses Floats for coordinates, and I haven't worked on >> performance yet, so everything should be slow... >>> I can try somethings that blow my mac out to the water >>> complete with the macbomb system crash box. That only >>> happened while using a low memory allocation. I'm >>> having better luck when I give the vm more room. >>> >> I believe the same should happen with any Squeak image, right? >>> I am about to try your new addr. If this doesn't >>> bounce then were golden. >>> >>> >> Yep, here I am. >>> The last try missed probably due to some typing on my >>> part. >>> >> Now I'm working on scrolling and clipping. I hope to publish >> something soon. >> >> Cheers, >> Juan Vuletich >> >> _______________________________________________ >> Morphic mailing list >> [hidden email] >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/morphic > > _______________________________________________ Morphic mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/morphic |
On 23 juin 07, at 14:35, Juan Vuletich wrote: > Hi Stef, > > You suggested that to me some time ago and I did. Sophie uses > smallintegers for coordinates. This is ok for books, to go from > printer pixels to books of several kilometers. But I want float > coordinates and multiple nonlinear coordinate systems in the same > world. I don't want to be restricted to Cartesian with a single > scale all over the system. In a morph, the number 3 could mean 3 > milimeters, and in another it could mean 3 astronomic unit (mean > distance from the earth to the sun), or 3 degrees of latitude > north, or 3 db or whatever. I thought that they used something new with a strange name for having better precision.... I cannot find the name anymore. > > Cheers, > Juan Vuletich > > Stéphane Ducasse escribió: >> Juan >> >> did you check the unit used in Sophie. Because told me that their >> units are quite good. >> >> Stef >> >> >> On 22 juin 07, at 03:11, Juan Vuletich wrote: >> >>> Hi Jerome, >>> >>> Jerome Peace escribió: >>>> Hi Juan, >>>> >>>> Cool. >>>> >>>> Thanks for listening. >>>> I've actually followed progress to know how much you >>>> advanced things. (Real time performance and the color >>>> background fix. Great steady progress.) >>>> >>>> >>> :) Thanks. >>>> I am using things on an old 400hz iMac running OS9.1. >>>> I'm using one of JMM's old macClassic vms. So I need >>>> to find out if you changed anything in th vm you >>>> distribute with the system? >>>> >>> Not at all. I should delete the VM from the zip file. It is >>> misleading. >>> Ok. Done. >>> So, you are doing a serious performance test there! >>> Unfortunately, the >>> Morphic 3 stuff uses Floats for coordinates, and I haven't worked on >>> performance yet, so everything should be slow... >>>> I can try somethings that blow my mac out to the water >>>> complete with the macbomb system crash box. That only >>>> happened while using a low memory allocation. I'm >>>> having better luck when I give the vm more room. >>>> >>> I believe the same should happen with any Squeak image, right? >>>> I am about to try your new addr. If this doesn't >>>> bounce then were golden. >>>> >>>> >>> Yep, here I am. >>>> The last try missed probably due to some typing on my >>>> part. >>>> >>> Now I'm working on scrolling and clipping. I hope to publish >>> something soon. >>> >>> Cheers, >>> Juan Vuletich >>> >>> _______________________________________________ >>> Morphic mailing list >>> [hidden email] >>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/morphic >> >> > _______________________________________________ Morphic mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/morphic |
In reply to this post by Juan Vuletich-4
Hello Juan,
JV> pixels to books of several kilometers. But I want float coordinates and JV> multiple nonlinear coordinate systems in the same world. I don't want to JV> be restricted to Cartesian with a single scale all over the system. In a that's good to hear! In road design and survey even 64 Bit Floats aren't enough. A few trigonometric calculations and you loose your 1mm precision. Sorry, first attempt went to your private email. Cheers Herbert mailto:[hidden email] _______________________________________________ Morphic mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/morphic |
Hi Herbert,
You're right. In fact we should be careful enough to support even higher precision numerical representations, if the image has support for them. Cheers, Juan Vuletich Herbert König escribió: > Hello Juan, > > JV> pixels to books of several kilometers. But I want float coordinates and > JV> multiple nonlinear coordinate systems in the same world. I don't want to > JV> be restricted to Cartesian with a single scale all over the system. In a > > that's good to hear! In road design and survey even 64 Bit Floats > aren't enough. A few trigonometric calculations and you loose your 1mm > precision. > > Sorry, first attempt went to your private email. > > Cheers > > Herbert mailto:[hidden email] > > _______________________________________________ > Morphic mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/morphic > > _______________________________________________ Morphic mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/morphic |
Free forum by Nabble | Edit this page |