What is the extent of a truncated rectangle? (reply to milan from heading = forwardDir... thread)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

What is the extent of a truncated rectangle? (reply to milan from heading = forwardDir... thread)

Jerome Peace
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 

Reply | Threaded
Open this post in threaded view
|

Re: What is the extent of a truncated rectangle? (reply to milan from heading = forwardDir... thread)

Milan Zimmermann-2
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