What is the extent of a truncated rectangle? (from
heading = forwardDir... thread) was heading = forwardDirection + rotationDegrees (was Re: How can we deal with Message rot?) Hi Milan, Thanks for your interest in this issue. Look at: http://bugs.impara.de/view.php?id=2453 0002453: [Bugs] What is the extent of a truncated rectangle? and for a specific example http://bugs.impara.de/view.php?id=2709 0002709: Sample instances have their leftmost row of pixels clipped off. The latter has a fix for the polygon curve morph sample instance. Which included extending ceiling and floor to the Point and Rectangle classes. I confess I was lazy and snuck these methods into the morphic package instead of negotiating with Andreas and getting the truncation and roundoff methods adopted into the graphic package. That still needs to be done. The current formalities of modularization are easier to work around that work with. I've been coming across varients of this bug since Oct 2004. (Mantis #0000360) There are numerous reports on mantis that touch on this. also search for reports with "render" or for reports with "drama" (as in dramatic demonstration) for reports with "transf" (as in transform) or reports from "wiz" many of my reports deal with these kind of things. HTH. Yours in service, --Jerome Peace Previous message: > >Milan Zimmermann milan.zimmermann at sympatico.ca >Tue Jan 2 14:33:04 UTC 2007 wrote: > >On 2006 December 29 01:27, Jerome Peace wrote: ><<snip>> >> Many of the deep bugs I run into have the >> TransformationMorph decorator as their root. >> Lots of the gribble leaving problems come from a >> mismatch of assumptions between TfMorph ( which >> believes you can translate the origin into the 3rd >> quadrant) while every body else believes that >> is the same as floor because all points are in the >> 1st quadrant. Clipping boxes get calculated wrong and >> are often of by one just when you need them not to be. > >Jerome, > >Could you point out a few concrete examples (class, method) of this behaviour? >I started work on a (exteremely limited) set of tests for etoys and morphic, >and perhaps it would make sense to document what you found in a test; >although documenting something that is (if I understand) considered broken >may not be as valuable, it should be easy to convert the test code if/once >the code under test is refactored. > >Thanks Milan > >> >> >> Results: screen gribbles abound. >> >> >- inEtoys they are not used directly, but through the >> >> Player, and this is >> >> >why your equation does not hold for each individual >> >> morph. I think >> >> >you would have to eliminate TransformMorph >> >> completely, which might >> >> >complicate other Morphs - until now, that "ugly" >> >> transformation stuff >> >> >was factored out. >> >> As I look at the code I see constant attempts to >> about which morph is actually being talked to renderer >> or renderee. The code practically begs to be >> refactored. Its just a big job at the moment. >> I await enlightenment and inspiration. Meanwhile I am >> trying refactorings that lay the ground work for the >> simplification of the Tf mess. >> >> Yours in service, --Jerome Peace > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
Hi Jerome,
Thanks for the details and Mantis links. I just took a look so far, and hopefuly spend more time on it when I get back the week after next. Milan On 2007 January 2 22:14, Jerome Peace wrote: > What is the extent of a truncated rectangle? (from > heading = forwardDir... thread) > was > heading = forwardDirection + rotationDegrees (was Re: > How can we deal with Message rot?) > > Hi Milan, > > Thanks for your interest in this issue. > > Look at: > http://bugs.impara.de/view.php?id=2453 > 0002453: [Bugs] What is the extent of a truncated > rectangle? > > and for a specific example > > http://bugs.impara.de/view.php?id=2709 > 0002709: Sample instances have their leftmost row of > pixels clipped off. > > The latter has a fix for the polygon curve morph > sample instance. > Which included extending ceiling and floor to the > Point and Rectangle classes. > > I confess I was lazy and snuck these methods into the > morphic package instead of negotiating with Andreas > and getting the truncation and roundoff methods > adopted into the graphic package. That still needs to > be done. > > The current formalities of modularization are easier > to work around that work with. > > I've been coming across varients of this bug since Oct > 2004. (Mantis #0000360) > > There are numerous reports on mantis that touch on > this. > > also search for reports with "render" or > for reports with "drama" (as in dramatic > demonstration) > for reports with "transf" (as in transform) > > or reports from "wiz" many of my reports deal with > these kind of things. > > HTH. > > > Yours in service, --Jerome Peace > > Previous message: > >Milan Zimmermann milan.zimmermann at sympatico.ca > >Tue Jan 2 14:33:04 UTC 2007 wrote: > > > >On 2006 December 29 01:27, Jerome Peace wrote: > ><<snip>> > > > >> Many of the deep bugs I run into have the > >> TransformationMorph decorator as their root. > >> Lots of the gribble leaving problems come from a > >> mismatch of assumptions between TfMorph ( which > >> believes you can translate the origin into the 3rd > >> quadrant) while every body else believes that > > truncate > > >> is the same as floor because all points are in the > >> 1st quadrant. Clipping boxes get calculated wrong > > and > > >> are often of by one just when you need them not to > > be. > > >Jerome, > > > >Could you point out a few concrete examples (class, > > method) of this behaviour? > > >I started work on a (exteremely limited) set of tests > > for etoys and morphic, > > >and perhaps it would make sense to document what you > > found in a test; > > >although documenting something that is (if I > > understand) considered broken > > >may not be as valuable, it should be easy to convert > > the test code if/once > > >the code under test is refactored. > > > >Thanks Milan > > > >> Results: screen gribbles abound. > >> > >> >- inEtoys they are not used directly, but through > > the > > >> Player, and this is > >> > >> >why your equation does not hold for each > > individual > > >> morph. I think > >> > >> >you would have to eliminate TransformMorph > >> > >> completely, which might > >> > >> >complicate other Morphs - until now, that "ugly" > >> > >> transformation stuff > >> > >> >was factored out. > >> > >> As I look at the code I see constant attempts to > > worry > > >> about which morph is actually being talked to > > renderer > > >> or renderee. The code practically begs to be > >> refactored. Its just a big job at the moment. > >> I await enlightenment and inspiration. Meanwhile I > > am > > >> trying refactorings that lay the ground work for > > the > > >> simplification of the Tf mess. > >> > >> Yours in service, --Jerome Peace > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com |
Free forum by Nabble | Edit this page |