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