Re: Found Bug But Not Sure How to Proceed To Fix

I think, you can describe the problem there as an issue and hand in
the fix.
They may also know how to guide you further if the code base is
somewhere else.
If you have problems there (login, no response), I guess, this
mailing list is one place to ask for help.

Best,
Nicco

On 03/01/2018 03:34 AM, Jeremy Landry
wrote:

Hi, while working on a project needing precise
alignment of sketches/bitmaps and rectangles using playfield
'use gridding', it seems that there's a difference of detected
origin.

I'm quite certain this bug is the one that causes bad redrawing, especially when showing a cursor move when 'indicate cursor' is activated in a playfield.

If I correct this bug inside of a project, will it load into an image where it has not been fixed and be fixed?

​When saving your project you can choose to include the current changeset. So if you add your fix to the current changeset (which otherwise should be empty) it will be installed when the project is loaded.

I think, you can describe the problem there as an issue and hand in
the fix.
They may also know how to guide you further if the code base is
somewhere else.
If you have problems there (login, no response), I guess, this
mailing list is one place to ask for help.

Best,
Nicco

On 03/01/2018 03:34 AM, Jeremy Landry
wrote:

Hi, while working on a project needing precise
alignment of sketches/bitmaps and rectangles using playfield
'use gridding', it seems that there's a difference of detected
origin.

Re: Found Bug But Not Sure How to Proceed To Fix

I did a little more digging, just for the record...and it turns out it's scaling error. No matter what, scaling offsets morphs by 1@-1. I'm still looking for where this occurs and why. So far, injecting intentionally bad values into bordered morph and sketch classes hasn't produced any change. It 'feels' like most of that code isn't even used, but then again, I might not have genuinely created a new object with that code and system might have been giving me what was already in system...

I think, you can describe the problem there as an issue and hand in
the fix.
They may also know how to guide you further if the code base is
somewhere else.
If you have problems there (login, no response), I guess, this
mailing list is one place to ask for help.

Best,
Nicco

On 03/01/2018 03:34 AM, Jeremy Landry
wrote:

Hi, while working on a project needing precise
alignment of sketches/bitmaps and rectangles using playfield
'use gridding', it seems that there's a difference of detected
origin.

Re: Found Bug But Not Sure How to Proceed To Fix

I tried to recreate your example and could
not. How did you create the two morphs in your example? Are you
certain the read/gray morph does not have some transparent
pixels along the top and left?

On 3/2/18 12:50 PM, Jeremy Landry
wrote:

I did a little more digging, just for the
record...and it turns out it's scaling error. No matter what,
scaling offsets morphs by 1@-1. I'm still looking for where
this occurs and why. So far, injecting intentionally bad values
into bordered morph and sketch classes hasn't produced any
change. It 'feels' like most of that code isn't even used, but
then again, I might not have genuinely created a new object with
that code and system might have been giving me what was already
in system...

I think, you can describe the problem there as
an issue and hand in the fix.
They may also know how to guide you further if
the code base is somewhere else.
If you have problems there (login, no
response), I guess, this mailing list is one
place to ask for help.

Best,
Nicco

On
03/01/2018 03:34 AM, Jeremy Landry
wrote:

Hi, while working on a
project needing precise alignment of
sketches/bitmaps and rectangles using
playfield 'use gridding', it seems
that there's a difference of detected
origin.

Re: Found Bug But Not Sure How to Proceed To Fix

Hi, it only appears when scaling a morph. Here is example...it is my belief (how does one step through code with debugger if there's no bug happening?);

Whatever code is common that scales morphs is being offset incorrectly. The first image shows the 'garbage' left behind by playfield indicator if that option is set. It seems it was only tested in 'holders' and thus likely not picked up during 'intended' use.

Next, two pictures show scaling as where the misalignment starts. This might be why you could not recreate bug; resizing rectangle changes rectangle morph extent, whereas scaling is a differnet piece of code and therefore different outcome.

I tried to recreate your example and could
not. How did you create the two morphs in your example? Are you
certain the read/gray morph does not have some transparent
pixels along the top and left?

On 3/2/18 12:50 PM, Jeremy Landry
wrote:

I did a little more digging, just for the
record...and it turns out it's scaling error. No matter what,
scaling offsets morphs by 1@-1. I'm still looking for where
this occurs and why. So far, injecting intentionally bad values
into bordered morph and sketch classes hasn't produced any
change. It 'feels' like most of that code isn't even used, but
then again, I might not have genuinely created a new object with
that code and system might have been giving me what was already
in system...

I think, you can describe the problem there as
an issue and hand in the fix.
They may also know how to guide you further if
the code base is somewhere else.
If you have problems there (login, no
response), I guess, this mailing list is one
place to ask for help.

Best,
Nicco

On
03/01/2018 03:34 AM, Jeremy Landry
wrote:

Hi, while working on a
project needing precise alignment of
sketches/bitmaps and rectangles using
playfield 'use gridding', it seems
that there's a difference of detected
origin.

Re: Found Bug But Not Sure How to Proceed To Fix

You will also notice if you rotate any shape, it becomes a bit map. Scale it and you will see that problem re-occur even with built-in objects. Could it be the masking offset, too? that causes this? I'm still investigating, but I'm not sure how to step through 'already working' things specifically related to what I'm trying to look at.

Hi, it only appears when scaling a morph. Here is example...it is my belief (how does one step through code with debugger if there's no bug happening?);

Whatever code is common that scales morphs is being offset incorrectly. The first image shows the 'garbage' left behind by playfield indicator if that option is set. It seems it was only tested in 'holders' and thus likely not picked up during 'intended' use.

Next, two pictures show scaling as where the misalignment starts. This might be why you could not recreate bug; resizing rectangle changes rectangle morph extent, whereas scaling is a differnet piece of code and therefore different outcome.

I tried to recreate your example and could
not. How did you create the two morphs in your example? Are you
certain the read/gray morph does not have some transparent
pixels along the top and left?

On 3/2/18 12:50 PM, Jeremy Landry
wrote:

I did a little more digging, just for the
record...and it turns out it's scaling error. No matter what,
scaling offsets morphs by 1@-1. I'm still looking for where
this occurs and why. So far, injecting intentionally bad values
into bordered morph and sketch classes hasn't produced any
change. It 'feels' like most of that code isn't even used, but
then again, I might not have genuinely created a new object with
that code and system might have been giving me what was already
in system...

I think, you can describe the problem there as
an issue and hand in the fix.
They may also know how to guide you further if
the code base is somewhere else.
If you have problems there (login, no
response), I guess, this mailing list is one
place to ask for help.

Best,
Nicco

On
03/01/2018 03:34 AM, Jeremy Landry
wrote:

Hi, while working on a
project needing precise alignment of
sketches/bitmaps and rectangles using
playfield 'use gridding', it seems
that there's a difference of detected
origin.

Re: Found Bug But Not Sure How to Proceed To Fix

Actually to add a little more insight if possible, you can create bug with the following actions:

make a new playfield

make 2 new rectangles and place them into the playfield.

Rotate one of them 90 degrees.

Turn gridding on in the playfield.

The rotated and unscaled rectangle will not align with the non-rotated one with gridding. Something about making a bitmap copy is offsetting the values, my guess is there's a rounding problem that is popping up on these objects, thus scale and rotation get offset for some reason, and specifically changes the origin by 1@-1 somewhere...it causes graphical glitches leaving 'garbage' with playfield indicators when the object that has the indicator is moved and also shows up with rotated ellipses. What is the common thread through them all? What method are they all accessing?

You will also notice if you rotate any shape, it becomes a bit map. Scale it and you will see that problem re-occur even with built-in objects. Could it be the masking offset, too? that causes this? I'm still investigating, but I'm not sure how to step through 'already working' things specifically related to what I'm trying to look at.

Hi, it only appears when scaling a morph. Here is example...it is my belief (how does one step through code with debugger if there's no bug happening?);

Whatever code is common that scales morphs is being offset incorrectly. The first image shows the 'garbage' left behind by playfield indicator if that option is set. It seems it was only tested in 'holders' and thus likely not picked up during 'intended' use.

Next, two pictures show scaling as where the misalignment starts. This might be why you could not recreate bug; resizing rectangle changes rectangle morph extent, whereas scaling is a differnet piece of code and therefore different outcome.

I tried to recreate your example and could
not. How did you create the two morphs in your example? Are you
certain the read/gray morph does not have some transparent
pixels along the top and left?

On 3/2/18 12:50 PM, Jeremy Landry
wrote:

I did a little more digging, just for the
record...and it turns out it's scaling error. No matter what,
scaling offsets morphs by 1@-1. I'm still looking for where
this occurs and why. So far, injecting intentionally bad values
into bordered morph and sketch classes hasn't produced any
change. It 'feels' like most of that code isn't even used, but
then again, I might not have genuinely created a new object with
that code and system might have been giving me what was already
in system...

I think, you can describe the problem there as
an issue and hand in the fix.
They may also know how to guide you further if
the code base is somewhere else.
If you have problems there (login, no
response), I guess, this mailing list is one
place to ask for help.

Best,
Nicco

On
03/01/2018 03:34 AM, Jeremy Landry
wrote:

Hi, while working on a
project needing precise alignment of
sketches/bitmaps and rectangles using
playfield 'use gridding', it seems
that there's a difference of detected
origin.

Actually to add a little more insight if possible,
you can create bug with the following actions:

make a new playfield

make 2 new rectangles and place them into the playfield.

Rotate one of them 90 degrees.

Turn gridding on in the playfield.

The rotated and unscaled rectangle will not align with the
non-rotated one with gridding. Something about making a
bitmap copy is offsetting the values, my guess is there's a
rounding problem that is popping up on these objects, thus
scale and rotation get offset for some reason, and
specifically changes the origin by 1@-1 somewhere...it causes
graphical glitches leaving 'garbage' with playfield indicators
when the object that has the indicator is moved and also shows
up with rotated ellipses. What is the common thread through
them all? What method are they all accessing?

You will also notice if you rotate any shape,
it becomes a bit map. Scale it and you will see that
problem re-occur even with built-in objects. Could it be
the masking offset, too? that causes this? I'm still
investigating, but I'm not sure how to step through
'already working' things specifically related to what I'm
trying to look at.

Hi, it only appears when scaling a
morph. Here is example...it is my belief (how
does one step through code with debugger if
there's no bug happening?);

Whatever code is common that scales morphs
is being offset incorrectly. The first image
shows the 'garbage' left behind by playfield
indicator if that option is set. It seems it
was only tested in 'holders' and thus likely
not picked up during 'intended' use.

Next, two pictures show scaling as where
the misalignment starts. This might be why
you could not recreate bug; resizing rectangle
changes rectangle morph extent, whereas
scaling is a differnet piece of code and
therefore different outcome.

I tried to
recreate your example and could
not. How did you create the two
morphs in your example? Are you
certain the read/gray morph does
not have some transparent pixels
along the top and left?

On
3/2/18 12:50 PM, Jeremy Landry
wrote:

I did a little
more digging, just for the
record...and it turns out it's
scaling error. No matter
what, scaling offsets morphs
by 1@-1. I'm still looking
for where this occurs and
why. So far, injecting
intentionally bad values into
bordered morph and sketch
classes hasn't produced any
change. It 'feels' like most
of that code isn't even used,
but then again, I might not
have genuinely created a new
object with that code and
system might have been giving
me what was already in
system...

I think, you
can describe
the problem
there as an
issue and hand
in the fix.
They may also
know how to
guide you
further if the
code base is
somewhere
else.
If you have
problems there
(login, no
response), I
guess, this
mailing list
is one place
to ask for
help.

Best,
Nicco

On
03/01/2018
03:34 AM,
Jeremy Landry
wrote:

Hi,
while working
on a project
needing
precise
alignment of
sketches/bitmaps
and rectangles
using
playfield 'use
gridding', it
seems that
there's a
difference of
detected
origin.

Actually to add a little more insight if possible,
you can create bug with the following actions:

make a new playfield

make 2 new rectangles and place them into the playfield.

Rotate one of them 90 degrees.

Turn gridding on in the playfield.

The rotated and unscaled rectangle will not align with the
non-rotated one with gridding. Something about making a
bitmap copy is offsetting the values, my guess is there's a
rounding problem that is popping up on these objects, thus
scale and rotation get offset for some reason, and
specifically changes the origin by 1@-1 somewhere...it causes
graphical glitches leaving 'garbage' with playfield indicators
when the object that has the indicator is moved and also shows
up with rotated ellipses. What is the common thread through
them all? What method are they all accessing?

You will also notice if you rotate any shape,
it becomes a bit map. Scale it and you will see that
problem re-occur even with built-in objects. Could it be
the masking offset, too? that causes this? I'm still
investigating, but I'm not sure how to step through
'already working' things specifically related to what I'm
trying to look at.

Hi, it only appears when scaling a
morph. Here is example...it is my belief (how
does one step through code with debugger if
there's no bug happening?);

Whatever code is common that scales morphs
is being offset incorrectly. The first image
shows the 'garbage' left behind by playfield
indicator if that option is set. It seems it
was only tested in 'holders' and thus likely
not picked up during 'intended' use.

Next, two pictures show scaling as where
the misalignment starts. This might be why
you could not recreate bug; resizing rectangle
changes rectangle morph extent, whereas
scaling is a differnet piece of code and
therefore different outcome.

I tried to
recreate your example and could
not. How did you create the two
morphs in your example? Are you
certain the read/gray morph does
not have some transparent pixels
along the top and left?

On
3/2/18 12:50 PM, Jeremy Landry
wrote:

I did a little
more digging, just for the
record...and it turns out it's
scaling error. No matter
what, scaling offsets morphs
by 1@-1. I'm still looking
for where this occurs and
why. So far, injecting
intentionally bad values into
bordered morph and sketch
classes hasn't produced any
change. It 'feels' like most
of that code isn't even used,
but then again, I might not
have genuinely created a new
object with that code and
system might have been giving
me what was already in
system...

I think, you
can describe
the problem
there as an
issue and hand
in the fix.
They may also
know how to
guide you
further if the
code base is
somewhere
else.
If you have
problems there
(login, no
response), I
guess, this
mailing list
is one place
to ask for
help.

Best,
Nicco

On
03/01/2018
03:34 AM,
Jeremy Landry
wrote:

Hi,
while working
on a project
needing
precise
alignment of
sketches/bitmaps
and rectangles
using
playfield 'use
gridding', it
seems that
there's a
difference of
detected
origin.

Re: Found Bug But Not Sure How to Proceed To Fix

Does anything bad happen if the "expandBy: 1" is removed? I tried removing it
in my Squeak trunk image, and "CompassDialMorph new openInWorld" (which is one
user of TransformationMorph) seems to work nicely.

And if the "expandBy: 1" is removed in an Etoys image, does anything bad happen?
Does it fix the issue that Jeremy is seeing?

This would be an easy thing to fix in Squeak trunk, which hopefully will become
part of future Etoys releases, knock wood.

Re: Found Bug But Not Sure How to Proceed To Fix

So far, with a little testing, everything lines up much better with .1 instead of removing it. removing that offset still sees to make it offset, but .1 lines everything up visually more...still not perfect, but much less flagrant. It still has a clipping glitch (you can see it with a rectangle when rotating: the border gets clipped off) but it does visually appear more 'solid' and expected when aligning rectangular shapes together.

I'm going to keep experimenting to find something that keeps the rotated bitmap in tact while still aligning properly. I feel like I probably glanced at a method that needs an edit over and over but haven't realized which one it is yet. I still need to look into the cursor not being properly redrawn as well. I might be stretching or trying to make a connection that isn't there, but something 'feels' related to this and the cursor, like some common reference point is being shifted so that the cursor's area for drawing doesn't reach the left and bottom edges just like the origin doesn't reach the left and bottom edges correctly for the this rotation issue.

Does anything bad happen if the "expandBy: 1" is removed? I tried removing it
in my Squeak trunk image, and "CompassDialMorph new openInWorld" (which is one
user of TransformationMorph) seems to work nicely.

And if the "expandBy: 1" is removed in an Etoys image, does anything bad happen?
Does it fix the issue that Jeremy is seeing?

This would be an easy thing to fix in Squeak trunk, which hopefully will become
part of future Etoys releases, knock wood.

Dave

On Fri, Mar 02, 2018 at 03:19:54PM -0500, Bob Arning wrote:
> TransformationMorph>>computeBounds
> ?????? self hasSubmorphs ifTrue:
> ?????? ?????? [bounds _ (transform localBoundsToGlobal:
> ?????? ?????? ?????? ?????? ?????? (Rectangle merging:
> ?????? ?????? ?????? ?????? ?????? ?????? (self submorphs collect: [:m | m
> fullBounds]))) truncated
> ?????? ?????? ?????? ?????? expandBy: 1].
> ?????? fullBounds _ bounds.>
> Note the expandBy: 1
>
>
> On 3/2/18 1:59 PM, Jeremy Landry wrote:
> >Actually to add a little more insight if possible, you can create bug
> >with the following actions:
> >
> >make a new playfield
> >make 2 new rectangles and place them into the playfield.
> >Rotate one of them 90 degrees.
> >Turn gridding on in the playfield.
> >
> >The rotated and unscaled rectangle will not align with the non-rotated> >one with gridding.?? Something about making a bitmap copy is offsetting> >the values, my guess is there's a rounding problem that is popping up
> >on these objects, thus scale and rotation get offset for some reason,
> >and specifically changes the origin by 1@-1 somewhere...it causes
> >graphical glitches leaving 'garbage' with playfield indicators when
> >the object that has the indicator is moved and also shows up with> >rotated ellipses.?? What is the common thread through them all??? What> >method are they all accessing?
> >
> >On Fri, Mar 2, 2018 at 10:45 AM, Jeremy Landry <[hidden email]> ><mailto:[hidden email]>> wrote:
> >
> > You will also notice if you rotate any shape, it becomes a bit> > map.?? Scale it and you will see that problem re-occur even with
> > built-in objects.?? Could it be the masking offset, too??? that
> > causes this??? I'm still investigating, but I'm not sure how to> > step through 'already working' things specifically related to what
> > I'm trying to look at.
> >
> > On Fri, Mar 2, 2018 at 10:42 AM, Jeremy Landry <[hidden email]> > <mailto:[hidden email]>> wrote:
> >
> > Hi, it only appears when scaling a morph.?? Here is> > example...it is my belief (how does one step through code with
> > debugger if there's no bug happening?);
> >
> > Whatever code is common that scales morphs is being offset
> > incorrectly. The first image shows the 'garbage' left behind> > by playfield indicator if that option is set.?? It seems it was> > only tested in 'holders' and thus likely not picked up during
> > 'intended' use.
> >
> > Next, two pictures show scaling as where the misalignment> > starts.?? This might be why you could not recreate bug;> > resizing rectangle changes rectangle morph extent, whereas
> > scaling is a differnet piece of code and therefore different
> > outcome.
> >> > Image included.?? This works with *anything* scaled.> > https://imgur.com/a/6zEWq
> >
> > On Fri, Mar 2, 2018 at 10:20 AM, Bob Arning> > <[hidden email] <mailto:[hidden email]>> wrote:
> >
> > I tried to recreate your example and could not. How did
> > you create the two morphs in your example? Are you certain
> > the read/gray morph does not have some transparent pixels
> > along the top and left?
> >
> >
> > On 3/2/18 12:50 PM, Jeremy Landry wrote:
> >> I did a little more digging, just for the record...and it> >> turns out it's scaling error.?? No matter what, scaling
> >> offsets morphs by 1@-1.?? I'm still looking for where this
> >> occurs and why.?? So far, injecting intentionally bad> >> values into bordered morph and sketch classes hasn't> >> produced any change.?? It 'feels' like most of that code> >> isn't even used, but then again, I might not have
> >> genuinely created a new object with that code and system
> >> might have been giving me what was already in system...
> >>
> >>
> >> On Fri, Mar 2, 2018 at 7:15 AM, Bert Freudenberg> >> <[hidden email] <mailto:[hidden email]>> wrote:
> >>
> >> That bug tracker is pretty much dead, since all
> >> ongoing development moved to squeak.org> >> <http://squeak.org>.> >>
> >> The plan was to make a new Etoys release based on the
> >> latest Squeak source base, but we have not have
> >> enough developer time to make that actually happen.
> >>
> >> - Bert -
> >>
> >> On 1 March 2018 at 06:03, Nicco Kunzmann (rambler)
> >> <[hidden email]

> >> <mailto:[hidden email]>> wrote:
> >>
> >> Hi,
> >>
> >> I found a bug tracker on the squeakland site:
> >> http://tracker.squeakland.org/secure/Dashboard.jspa
> >> <http://tracker.squeakland.org/secure/Dashboard.jspa>
> >>
> >> I think, you can describe the problem there as an
> >> issue and hand in the fix.
> >> They may also know how to guide you further if
> >> the code base is somewhere else.
> >> If you have problems there (login, no response),
> >> I guess, this mailing list is one place to ask
> >> for help.
> >>
> >> Best,
> >> Nicco
> >>
> >>
> >> On 03/01/2018 03:34 AM, Jeremy Landry wrote:
> >>> Hi, while working on a project needing precise
> >>> alignment of sketches/bitmaps and rectangles
> >>> using playfield 'use gridding', it seems that
> >>> there's a difference of detected origin.
> >>>
> >>> Here's a screenshot with magnifier showing the
> >>> discrepency.
> >>> https://imgur.com/a/tcaRu
> >>>
> >>> I'm quite certain this bug is the one that
> >>> causes bad redrawing, especially when showing a
> >>> cursor move when 'indicate cursor' is activated
> >>> in a playfield.
> >>>
> >>> If I correct this bug inside of a project, will
> >>> it load into an image where it has not been
> >>> fixed and be fixed?
> >>>
> >>> I haven't actually fixed the bug yet, but didn't
> >>> want to waste time on it if the fix will not
> >>> travel with the project.
> >>>
> >>> Thanks in advance for any input.
> >>>
> >>>
> >>> _______________________________________________
> >>> squeakland mailing list
> >>> [hidden email]

So far, with a little testing, everything lines up much better with .1 instead of removing it. removing that offset still sees to make it offset, but .1 lines everything up visually more...still not perfect, but much less flagrant. It still has a clipping glitch (you can see it with a rectangle when rotating: the border gets clipped off) but it does visually appear more 'solid' and expected when aligning rectangular shapes together.

I'm going to keep experimenting to find something that keeps the rotated bitmap in tact while still aligning properly. I feel like I probably glanced at a method that needs an edit over and over but haven't realized which one it is yet. I still need to look into the cursor not being properly redrawn as well. I might be stretching or trying to make a connection that isn't there, but something 'feels' related to this and the cursor, like some common reference point is being shifted so that the cursor's area for drawing doesn't reach the left and bottom edges just like the origin doesn't reach the left and bottom edges correctly for the this rotation issue.

Does anything bad happen if the "expandBy: 1" is removed? I tried removing it
in my Squeak trunk image, and "CompassDialMorph new openInWorld" (which is one
user of TransformationMorph) seems to work nicely.

And if the "expandBy: 1" is removed in an Etoys image, does anything bad happen?
Does it fix the issue that Jeremy is seeing?

This would be an easy thing to fix in Squeak trunk, which hopefully will become
part of future Etoys releases, knock wood.

Dave

On Fri, Mar 02, 2018 at 03:19:54PM -0500, Bob Arning wrote:
> TransformationMorph>>computeBounds
> ?????? self hasSubmorphs ifTrue:
> ?????? ?????? [bounds _ (transform localBoundsToGlobal:
> ?????? ?????? ?????? ?????? ?????? (Rectangle merging:
> ?????? ?????? ?????? ?????? ?????? ?????? (self submorphs collect: [:m | m
> fullBounds]))) truncated
> ?????? ?????? ?????? ?????? expandBy: 1].
> ?????? fullBounds _ bounds.>
> Note the expandBy: 1
>
>
> On 3/2/18 1:59 PM, Jeremy Landry wrote:
> >Actually to add a little more insight if possible, you can create bug
> >with the following actions:
> >
> >make a new playfield
> >make 2 new rectangles and place them into the playfield.
> >Rotate one of them 90 degrees.
> >Turn gridding on in the playfield.
> >
> >The rotated and unscaled rectangle will not align with the non-rotated> >one with gridding.?? Something about making a bitmap copy is offsetting> >the values, my guess is there's a rounding problem that is popping up
> >on these objects, thus scale and rotation get offset for some reason,
> >and specifically changes the origin by 1@-1 somewhere...it causes
> >graphical glitches leaving 'garbage' with playfield indicators when
> >the object that has the indicator is moved and also shows up with> >rotated ellipses.?? What is the common thread through them all??? What> >method are they all accessing?
> >
> >On Fri, Mar 2, 2018 at 10:45 AM, Jeremy Landry <[hidden email]> ><mailto:[hidden email]>> wrote:
> >
> > You will also notice if you rotate any shape, it becomes a bit> > map.?? Scale it and you will see that problem re-occur even with
> > built-in objects.?? Could it be the masking offset, too??? that
> > causes this??? I'm still investigating, but I'm not sure how to> > step through 'already working' things specifically related to what
> > I'm trying to look at.
> >
> > On Fri, Mar 2, 2018 at 10:42 AM, Jeremy Landry <[hidden email]> > <mailto:[hidden email]>> wrote:
> >
> > Hi, it only appears when scaling a morph.?? Here is> > example...it is my belief (how does one step through code with
> > debugger if there's no bug happening?);
> >
> > Whatever code is common that scales morphs is being offset
> > incorrectly. The first image shows the 'garbage' left behind> > by playfield indicator if that option is set.?? It seems it was> > only tested in 'holders' and thus likely not picked up during
> > 'intended' use.
> >
> > Next, two pictures show scaling as where the misalignment> > starts.?? This might be why you could not recreate bug;> > resizing rectangle changes rectangle morph extent, whereas
> > scaling is a differnet piece of code and therefore different
> > outcome.
> >> > Image included.?? This works with *anything* scaled.> > https://imgur.com/a/6zEWq
> >
> > On Fri, Mar 2, 2018 at 10:20 AM, Bob Arning> > <[hidden email] <mailto:[hidden email]>> wrote:
> >
> > I tried to recreate your example and could not. How did
> > you create the two morphs in your example? Are you certain
> > the read/gray morph does not have some transparent pixels
> > along the top and left?
> >
> >
> > On 3/2/18 12:50 PM, Jeremy Landry wrote:
> >> I did a little more digging, just for the record...and it> >> turns out it's scaling error.?? No matter what, scaling
> >> offsets morphs by 1@-1.?? I'm still looking for where this
> >> occurs and why.?? So far, injecting intentionally bad> >> values into bordered morph and sketch classes hasn't> >> produced any change.?? It 'feels' like most of that code> >> isn't even used, but then again, I might not have
> >> genuinely created a new object with that code and system
> >> might have been giving me what was already in system...
> >>
> >>
> >> On Fri, Mar 2, 2018 at 7:15 AM, Bert Freudenberg> >> <[hidden email] <mailto:[hidden email]>> wrote:
> >>
> >> That bug tracker is pretty much dead, since all
> >> ongoing development moved to squeak.org> >> <http://squeak.org>.> >>
> >> The plan was to make a new Etoys release based on the
> >> latest Squeak source base, but we have not have
> >> enough developer time to make that actually happen.
> >>
> >> - Bert -
> >>
> >> On 1 March 2018 at 06:03, Nicco Kunzmann (rambler)
> >> <[hidden email]

> >> <mailto:[hidden email]>> wrote:
> >>
> >> Hi,
> >>
> >> I found a bug tracker on the squeakland site:
> >> http://tracker.squeakland.org/secure/Dashboard.jspa
> >> <http://tracker.squeakland.org/secure/Dashboard.jspa>
> >>
> >> I think, you can describe the problem there as an
> >> issue and hand in the fix.
> >> They may also know how to guide you further if
> >> the code base is somewhere else.
> >> If you have problems there (login, no response),
> >> I guess, this mailing list is one place to ask
> >> for help.
> >>
> >> Best,
> >> Nicco
> >>
> >>
> >> On 03/01/2018 03:34 AM, Jeremy Landry wrote:
> >>> Hi, while working on a project needing precise
> >>> alignment of sketches/bitmaps and rectangles
> >>> using playfield 'use gridding', it seems that
> >>> there's a difference of detected origin.
> >>>
> >>> Here's a screenshot with magnifier showing the
> >>> discrepency.
> >>> https://imgur.com/a/tcaRu
> >>>
> >>> I'm quite certain this bug is the one that
> >>> causes bad redrawing, especially when showing a
> >>> cursor move when 'indicate cursor' is activated
> >>> in a playfield.
> >>>
> >>> If I correct this bug inside of a project, will
> >>> it load into an image where it has not been
> >>> fixed and be fixed?
> >>>
> >>> I haven't actually fixed the bug yet, but didn't
> >>> want to waste time on it if the fix will not
> >>> travel with the project.
> >>>
> >>> Thanks in advance for any input.
> >>>
> >>>
> >>> _______________________________________________
> >>> squeakland mailing list
> >>> [hidden email]

So far, with a little testing, everything lines up much better with .1 instead of removing it. removing that offset still sees to make it offset, but .1 lines everything up visually more...still not perfect, but much less flagrant. It still has a clipping glitch (you can see it with a rectangle when rotating: the border gets clipped off) but it does visually appear more 'solid' and expected when aligning rectangular shapes together.

I'm going to keep experimenting to find something that keeps the rotated bitmap in tact while still aligning properly. I feel like I probably glanced at a method that needs an edit over and over but haven't realized which one it is yet. I still need to look into the cursor not being properly redrawn as well. I might be stretching or trying to make a connection that isn't there, but something 'feels' related to this and the cursor, like some common reference point is being shifted so that the cursor's area for drawing doesn't reach the left and bottom edges just like the origin doesn't reach the left and bottom edges correctly for the this rotation issue.

Does anything bad happen if the "expandBy: 1" is removed? I tried removing it
in my Squeak trunk image, and "CompassDialMorph new openInWorld" (which is one
user of TransformationMorph) seems to work nicely.

And if the "expandBy: 1" is removed in an Etoys image, does anything bad happen?
Does it fix the issue that Jeremy is seeing?

This would be an easy thing to fix in Squeak trunk, which hopefully will become
part of future Etoys releases, knock wood.

Dave

On Fri, Mar 02, 2018 at 03:19:54PM -0500, Bob Arning wrote:
> TransformationMorph>>computeBounds
> ?????? self hasSubmorphs ifTrue:
> ?????? ?????? [bounds _ (transform localBoundsToGlobal:
> ?????? ?????? ?????? ?????? ?????? (Rectangle merging:
> ?????? ?????? ?????? ?????? ?????? ?????? (self submorphs collect: [:m | m
> fullBounds]))) truncated
> ?????? ?????? ?????? ?????? expandBy: 1].
> ?????? fullBounds _ bounds.>
> Note the expandBy: 1
>
>
> On 3/2/18 1:59 PM, Jeremy Landry wrote:
> >Actually to add a little more insight if possible, you can create bug
> >with the following actions:
> >
> >make a new playfield
> >make 2 new rectangles and place them into the playfield.
> >Rotate one of them 90 degrees.
> >Turn gridding on in the playfield.
> >
> >The rotated and unscaled rectangle will not align with the non-rotated> >one with gridding.?? Something about making a bitmap copy is offsetting> >the values, my guess is there's a rounding problem that is popping up
> >on these objects, thus scale and rotation get offset for some reason,
> >and specifically changes the origin by 1@-1 somewhere...it causes
> >graphical glitches leaving 'garbage' with playfield indicators when
> >the object that has the indicator is moved and also shows up with> >rotated ellipses.?? What is the common thread through them all??? What> >method are they all accessing?
> >
> >On Fri, Mar 2, 2018 at 10:45 AM, Jeremy Landry <[hidden email]> ><mailto:[hidden email]>> wrote:
> >
> > You will also notice if you rotate any shape, it becomes a bit> > map.?? Scale it and you will see that problem re-occur even with
> > built-in objects.?? Could it be the masking offset, too??? that
> > causes this??? I'm still investigating, but I'm not sure how to> > step through 'already working' things specifically related to what
> > I'm trying to look at.
> >
> > On Fri, Mar 2, 2018 at 10:42 AM, Jeremy Landry <[hidden email]> > <mailto:[hidden email]>> wrote:
> >
> > Hi, it only appears when scaling a morph.?? Here is> > example...it is my belief (how does one step through code with
> > debugger if there's no bug happening?);
> >
> > Whatever code is common that scales morphs is being offset
> > incorrectly. The first image shows the 'garbage' left behind> > by playfield indicator if that option is set.?? It seems it was> > only tested in 'holders' and thus likely not picked up during
> > 'intended' use.
> >
> > Next, two pictures show scaling as where the misalignment> > starts.?? This might be why you could not recreate bug;> > resizing rectangle changes rectangle morph extent, whereas
> > scaling is a differnet piece of code and therefore different
> > outcome.
> >> > Image included.?? This works with *anything* scaled.> > https://imgur.com/a/6zEWq
> >
> > On Fri, Mar 2, 2018 at 10:20 AM, Bob Arning> > <[hidden email] <mailto:[hidden email]>> wrote:
> >
> > I tried to recreate your example and could not. How did
> > you create the two morphs in your example? Are you certain
> > the read/gray morph does not have some transparent pixels
> > along the top and left?
> >
> >
> > On 3/2/18 12:50 PM, Jeremy Landry wrote:
> >> I did a little more digging, just for the record...and it> >> turns out it's scaling error.?? No matter what, scaling
> >> offsets morphs by 1@-1.?? I'm still looking for where this
> >> occurs and why.?? So far, injecting intentionally bad> >> values into bordered morph and sketch classes hasn't> >> produced any change.?? It 'feels' like most of that code> >> isn't even used, but then again, I might not have
> >> genuinely created a new object with that code and system
> >> might have been giving me what was already in system...
> >>
> >>
> >> On Fri, Mar 2, 2018 at 7:15 AM, Bert Freudenberg> >> <[hidden email] <mailto:[hidden email]>> wrote:
> >>
> >> That bug tracker is pretty much dead, since all
> >> ongoing development moved to squeak.org> >> <http://squeak.org>.> >>
> >> The plan was to make a new Etoys release based on the
> >> latest Squeak source base, but we have not have
> >> enough developer time to make that actually happen.
> >>
> >> - Bert -
> >>
> >> On 1 March 2018 at 06:03, Nicco Kunzmann (rambler)
> >> <[hidden email]

> >> <mailto:[hidden email]>> wrote:
> >>
> >> Hi,
> >>
> >> I found a bug tracker on the squeakland site:
> >> http://tracker.squeakland.org/secure/Dashboard.jspa
> >> <http://tracker.squeakland.org/secure/Dashboard.jspa>
> >>
> >> I think, you can describe the problem there as an
> >> issue and hand in the fix.
> >> They may also know how to guide you further if
> >> the code base is somewhere else.
> >> If you have problems there (login, no response),
> >> I guess, this mailing list is one place to ask
> >> for help.
> >>
> >> Best,
> >> Nicco
> >>
> >>
> >> On 03/01/2018 03:34 AM, Jeremy Landry wrote:
> >>> Hi, while working on a project needing precise
> >>> alignment of sketches/bitmaps and rectangles
> >>> using playfield 'use gridding', it seems that
> >>> there's a difference of detected origin.
> >>>
> >>> Here's a screenshot with magnifier showing the
> >>> discrepency.
> >>> https://imgur.com/a/tcaRu
> >>>
> >>> I'm quite certain this bug is the one that
> >>> causes bad redrawing, especially when showing a
> >>> cursor move when 'indicate cursor' is activated
> >>> in a playfield.
> >>>
> >>> If I correct this bug inside of a project, will
> >>> it load into an image where it has not been
> >>> fixed and be fixed?
> >>>
> >>> I haven't actually fixed the bug yet, but didn't
> >>> want to waste time on it if the fix will not
> >>> travel with the project.
> >>>
> >>> Thanks in advance for any input.
> >>>
> >>>
> >>> _______________________________________________
> >>> squeakland mailing list
> >>> [hidden email]

Re: Found Bug But Not Sure How to Proceed To Fix

Not only is it affecting how sketches (which would be scaled/rotated items) are drawn and aligned to real shapes (like rectangles) but it's also having an effect on how the cursor in playfield is drawn. I'm adding small 'offsets' in-code for now, but I suspect there's something else at play here, possible with some rotation/scaling math handing off bad values? But then again, this would mean that cursors would not leave trails for rectangles and WOULD leave trails for rotated ones...hmmm...

So far, with a little testing, everything lines up much better with .1 instead of removing it. removing that offset still sees to make it offset, but .1 lines everything up visually more...still not perfect, but much less flagrant. It still has a clipping glitch (you can see it with a rectangle when rotating: the border gets clipped off) but it does visually appear more 'solid' and expected when aligning rectangular shapes together.

I'm going to keep experimenting to find something that keeps the rotated bitmap in tact while still aligning properly. I feel like I probably glanced at a method that needs an edit over and over but haven't realized which one it is yet. I still need to look into the cursor not being properly redrawn as well. I might be stretching or trying to make a connection that isn't there, but something 'feels' related to this and the cursor, like some common reference point is being shifted so that the cursor's area for drawing doesn't reach the left and bottom edges just like the origin doesn't reach the left and bottom edges correctly for the this rotation issue.

Does anything bad happen if the "expandBy: 1" is removed? I tried removing it
in my Squeak trunk image, and "CompassDialMorph new openInWorld" (which is one
user of TransformationMorph) seems to work nicely.

And if the "expandBy: 1" is removed in an Etoys image, does anything bad happen?
Does it fix the issue that Jeremy is seeing?

This would be an easy thing to fix in Squeak trunk, which hopefully will become
part of future Etoys releases, knock wood.

Dave

On Fri, Mar 02, 2018 at 03:19:54PM -0500, Bob Arning wrote:
> TransformationMorph>>computeBounds
> ?????? self hasSubmorphs ifTrue:
> ?????? ?????? [bounds _ (transform localBoundsToGlobal:
> ?????? ?????? ?????? ?????? ?????? (Rectangle merging:
> ?????? ?????? ?????? ?????? ?????? ?????? (self submorphs collect: [:m | m
> fullBounds]))) truncated
> ?????? ?????? ?????? ?????? expandBy: 1].
> ?????? fullBounds _ bounds.>
> Note the expandBy: 1
>
>
> On 3/2/18 1:59 PM, Jeremy Landry wrote:
> >Actually to add a little more insight if possible, you can create bug
> >with the following actions:
> >
> >make a new playfield
> >make 2 new rectangles and place them into the playfield.
> >Rotate one of them 90 degrees.
> >Turn gridding on in the playfield.
> >
> >The rotated and unscaled rectangle will not align with the non-rotated> >one with gridding.?? Something about making a bitmap copy is offsetting> >the values, my guess is there's a rounding problem that is popping up
> >on these objects, thus scale and rotation get offset for some reason,
> >and specifically changes the origin by 1@-1 somewhere...it causes
> >graphical glitches leaving 'garbage' with playfield indicators when
> >the object that has the indicator is moved and also shows up with> >rotated ellipses.?? What is the common thread through them all??? What> >method are they all accessing?
> >
> >On Fri, Mar 2, 2018 at 10:45 AM, Jeremy Landry <[hidden email]> ><mailto:[hidden email]>> wrote:
> >
> > You will also notice if you rotate any shape, it becomes a bit> > map.?? Scale it and you will see that problem re-occur even with
> > built-in objects.?? Could it be the masking offset, too??? that
> > causes this??? I'm still investigating, but I'm not sure how to> > step through 'already working' things specifically related to what
> > I'm trying to look at.
> >
> > On Fri, Mar 2, 2018 at 10:42 AM, Jeremy Landry <[hidden email]> > <mailto:[hidden email]>> wrote:
> >
> > Hi, it only appears when scaling a morph.?? Here is> > example...it is my belief (how does one step through code with
> > debugger if there's no bug happening?);
> >
> > Whatever code is common that scales morphs is being offset
> > incorrectly. The first image shows the 'garbage' left behind> > by playfield indicator if that option is set.?? It seems it was> > only tested in 'holders' and thus likely not picked up during
> > 'intended' use.
> >
> > Next, two pictures show scaling as where the misalignment> > starts.?? This might be why you could not recreate bug;> > resizing rectangle changes rectangle morph extent, whereas
> > scaling is a differnet piece of code and therefore different
> > outcome.
> >> > Image included.?? This works with *anything* scaled.> > https://imgur.com/a/6zEWq
> >
> > On Fri, Mar 2, 2018 at 10:20 AM, Bob Arning> > <[hidden email] <mailto:[hidden email]>> wrote:
> >
> > I tried to recreate your example and could not. How did
> > you create the two morphs in your example? Are you certain
> > the read/gray morph does not have some transparent pixels
> > along the top and left?
> >
> >
> > On 3/2/18 12:50 PM, Jeremy Landry wrote:
> >> I did a little more digging, just for the record...and it> >> turns out it's scaling error.?? No matter what, scaling
> >> offsets morphs by 1@-1.?? I'm still looking for where this
> >> occurs and why.?? So far, injecting intentionally bad> >> values into bordered morph and sketch classes hasn't> >> produced any change.?? It 'feels' like most of that code> >> isn't even used, but then again, I might not have
> >> genuinely created a new object with that code and system
> >> might have been giving me what was already in system...
> >>
> >>
> >> On Fri, Mar 2, 2018 at 7:15 AM, Bert Freudenberg> >> <[hidden email] <mailto:[hidden email]>> wrote:
> >>
> >> That bug tracker is pretty much dead, since all
> >> ongoing development moved to squeak.org> >> <http://squeak.org>.> >>
> >> The plan was to make a new Etoys release based on the
> >> latest Squeak source base, but we have not have
> >> enough developer time to make that actually happen.
> >>
> >> - Bert -
> >>
> >> On 1 March 2018 at 06:03, Nicco Kunzmann (rambler)
> >> <[hidden email]

> >> <mailto:[hidden email]>> wrote:
> >>
> >> Hi,
> >>
> >> I found a bug tracker on the squeakland site:
> >> http://tracker.squeakland.org/secure/Dashboard.jspa
> >> <http://tracker.squeakland.org/secure/Dashboard.jspa>
> >>
> >> I think, you can describe the problem there as an
> >> issue and hand in the fix.
> >> They may also know how to guide you further if
> >> the code base is somewhere else.
> >> If you have problems there (login, no response),
> >> I guess, this mailing list is one place to ask
> >> for help.
> >>
> >> Best,
> >> Nicco
> >>
> >>
> >> On 03/01/2018 03:34 AM, Jeremy Landry wrote:
> >>> Hi, while working on a project needing precise
> >>> alignment of sketches/bitmaps and rectangles
> >>> using playfield 'use gridding', it seems that
> >>> there's a difference of detected origin.
> >>>
> >>> Here's a screenshot with magnifier showing the
> >>> discrepency.
> >>> https://imgur.com/a/tcaRu
> >>>
> >>> I'm quite certain this bug is the one that
> >>> causes bad redrawing, especially when showing a
> >>> cursor move when 'indicate cursor' is activated
> >>> in a playfield.
> >>>
> >>> If I correct this bug inside of a project, will
> >>> it load into an image where it has not been
> >>> fixed and be fixed?
> >>>
> >>> I haven't actually fixed the bug yet, but didn't
> >>> want to waste time on it if the fix will not
> >>> travel with the project.
> >>>
> >>> Thanks in advance for any input.
> >>>
> >>>
> >>> _______________________________________________
> >>> squeakland mailing list
> >>> [hidden email]

Make the one change highlighted above and no others (to avoid
clashes). Get 4 RectangleMorphs, rotate them 0, 90, 180 and 270
degrees. Observe that they are placed in the magenta area
differently based on the angle. It's the topLeft of the magenta
area that will align with other morphs when gridding is on, so the
fact that the rectangles start at different distances from that
corner is what makes their alignments not the same. Hopefully we
can convince WarpBlt to position them the same way, although the
absence of a transformation on the 0 degree version means there is
still an issue to make it line up with the rotated ones.

On 3/2/18 10:11 PM, Jeremy Landry
wrote:

Update:
I've traced it down to bitBlt destRect:.

Not
only is it affecting how sketches (which would be
scaled/rotated items) are drawn and aligned to real shapes
(like rectangles) but it's also having an effect on how the
cursor in playfield is drawn. I'm adding small 'offsets'
in-code for now, but I suspect there's something else at play
here, possible with some rotation/scaling math handing off bad
values? But then again, this would mean that cursors would
not leave trails for rectangles and WOULD leave trails for
rotated ones...hmmm...

So far, with a little testing,
everything lines up much better with .1 instead
of removing it. removing that offset still sees
to make it offset, but .1 lines everything up
visually more...still not perfect, but much less
flagrant. It still has a clipping glitch (you
can see it with a rectangle when rotating: the
border gets clipped off) but it does visually
appear more 'solid' and expected when aligning
rectangular shapes together.

I'm going to keep experimenting to find
something that keeps the rotated bitmap in
tact while still aligning properly. I feel
like I probably glanced at a method that needs
an edit over and over but haven't realized
which one it is yet. I still need to look into
the cursor not being properly redrawn as
well. I might be stretching or trying to make
a connection that isn't there, but something
'feels' related to this and the cursor, like
some common reference point is being shifted
so that the cursor's area for drawing doesn't
reach the left and bottom edges just like the
origin doesn't reach the left and bottom edges
correctly for the this rotation issue.

Does
anything bad happen if the "expandBy: 1"
is removed? I tried removing it
in my Squeak trunk image, and
"CompassDialMorph new openInWorld"
(which is one
user of TransformationMorph) seems to
work nicely.

And if the "expandBy: 1" is removed in
an Etoys image, does anything bad
happen?
Does it fix the issue that Jeremy is
seeing?

This would be an easy thing to fix in
Squeak trunk, which hopefully will
become
part of future Etoys releases, knock
wood.

Dave

On Fri, Mar 02, 2018 at 03:19:54PM
-0500, Bob Arning wrote:
>
TransformationMorph>>computeBounds
> ?????? self hasSubmorphs ifTrue:
> ?????? ?????? [bounds _ (transform
localBoundsToGlobal:
> ?????? ?????? ?????? ?????? ??????
(Rectangle merging:
> ?????? ?????? ?????? ?????? ??????
?????? (self submorphs collect: [:m | m
> fullBounds]))) truncated
> ?????? ?????? ?????? ??????
expandBy: 1].
> ?????? fullBounds _ bounds.>
> Note the expandBy: 1
>
>
> On 3/2/18 1:59 PM, Jeremy Landry
wrote:
> >Actually to add a little more
insight if possible, you can create
bug
> >with the following actions:
> >
> >make a new playfield
> >make 2 new rectangles and
place them into the playfield.
> >Rotate one of them 90
degrees.
> >Turn gridding on in the
playfield.
> >
> >The rotated and unscaled
rectangle will not align with the
non-rotated> >one with gridding.??
Something about making a bitmap copy is
offsetting> >the values, my guess is
there's a rounding problem that is
popping up
> >on these objects, thus scale
and rotation get offset for some
reason,
> >and specifically changes the
origin by 1@-1 somewhere...it causes
> >graphical glitches leaving
'garbage' with playfield indicators
when
> >the object that has the
indicator is moved and also shows up
with> >rotated ellipses.?? What
is the common thread through them all???
What> >method are they all
accessing?
> >
> >On Fri, Mar 2, 2018 at 10:45
AM, Jeremy Landry <[hidden email]> ><mailto:[hidden email]>>
wrote:
> >
> > You will also notice if
you rotate any shape, it becomes a bit> > map.?? Scale it and
you will see that problem re-occur even
with
> > built-in objects.?? Could
it be the masking offset, too??? that
> > causes this??? I'm still
investigating, but I'm not sure how to> > step through 'already
working' things specifically related
to what
> > I'm trying to look at.
> >
> > On Fri, Mar 2, 2018 at
10:42 AM, Jeremy Landry <[hidden email]> > <mailto:[hidden email]>>
wrote:
> >
> > Hi, it only appears
when scaling a morph.?? Here is> > example...it is
my belief (how does one step through
code with
> > debugger if there's
no bug happening?);
> >
> > Whatever code is
common that scales morphs is being
offset
> > incorrectly. The
first image shows the 'garbage' left
behind> > by playfield
indicator if that option is set.?? It
seems it was> > only tested in
'holders' and thus likely not picked
up during
> > 'intended' use.
> >
> > Next, two pictures
show scaling as where the misalignment> > starts.?? This
might be why you could not recreate bug;> > resizing
rectangle changes rectangle morph
extent, whereas
> > scaling is a
differnet piece of code and therefore
different
> > outcome.
> >> > Image
included.?? This works with *anything*
scaled.> > https://imgur.com/a/6zEWq
> >
> > On Fri, Mar 2, 2018
at 10:20 AM, Bob Arning> > <[hidden email]
<mailto:[hidden email]>>
wrote:
> >
> > I tried to
recreate your example and could not.
How did
> > you create the
two morphs in your example? Are you
certain
> > the read/gray
morph does not have some transparent
pixels
> > along the top and
left?
> >
> >
> > On 3/2/18 12:50
PM, Jeremy Landry wrote:
> >> I did a
little more digging, just for the
record...and it> >> turns
out it's scaling error.?? No matter
what, scaling
> >> offsets morphs
by 1@-1.?? I'm still looking for where
this
> >> occurs and
why.?? So far, injecting intentionally
bad> >> values
into bordered morph and sketch classes
hasn't> >> produced
any change.?? It 'feels' like most of
that code> >> isn't
even used, but then again, I might not
have
> >> genuinely
created a new object with that code
and system
> >> might have
been giving me what was already in
system...
> >>
> >>
> >> On Fri, Mar
2, 2018 at 7:15 AM, Bert Freudenberg> >>
<[hidden email]
<mailto:[hidden email]>>
wrote:
> >>
> >> That bug
tracker is pretty much dead, since all
> >> ongoing
development moved to squeak.org> >> <http://squeak.org>.> >>
> >> The plan
was to make a new Etoys release based
on the
> >> latest
Squeak source base, but we have not
have
> >> enough
developer time to make that actually
happen.
> >>
> >> - Bert -
> >>
> >> On 1
March 2018 at 06:03, Nicco Kunzmann
(rambler)
> >> <[hidden email]

>
>> <mailto:[hidden email]>>
wrote:
> >>
> >> Hi,
> >>
> >> I
found a bug tracker on the
squeakland site:
> >> http://tracker.squeakland.org/secure/Dashboard.jspa
> >>
<http://tracker.squeakland.org/secure/Dashboard.jspa>
> >>
> >> I
think, you can describe the problem
there as an
> >>
issue and hand in the fix.
> >>
They may also know how to guide you
further if
> >> the
code base is somewhere else.
> >> If
you have problems there (login, no
response),
> >> I
guess, this mailing list is one
place to ask
> >> for
help.
> >>
> >>
Best,
> >>
Nicco
> >>
> >>
> >> On
03/01/2018 03:34 AM, Jeremy Landry
wrote:
> >>>
Hi, while working on a project
needing precise
> >>>
alignment of sketches/bitmaps and
rectangles
> >>>
using playfield 'use gridding', it
seems that
> >>>
there's a difference of detected
origin.
> >>>
> >>>
Here's a screenshot with magnifier
showing the
> >>>
discrepency.
> >>>
https://imgur.com/a/tcaRu
> >>>
> >>>
I'm quite certain this bug is the
one that
> >>>
causes bad redrawing, especially
when showing a
> >>>
cursor move when 'indicate cursor'
is activated
> >>>
in a playfield.
> >>>
> >>>
If I correct this bug inside of a
project, will
> >>>
it load into an image where it has
not been
> >>>
fixed and be fixed?
> >>>
> >>>
I haven't actually fixed the bug
yet, but didn't
> >>>
want to waste time on it if the fix
will not
> >>>
travel with the project.
> >>>
> >>>
Thanks in advance for any input.
> >>>
> >>>
> >>>
_______________________________________________
> >>>
squeakland mailing list
> >>>
[hidden email]

Re: Found Bug But Not Sure How to Proceed To Fix

Does anything bad happen if the "expandBy: 1" is removed? I tried removing it
in my Squeak trunk image, and "CompassDialMorph new openInWorld" (which is one
user of TransformationMorph) seems to work nicely.

​I bet it's there to avoid gribblies left behind when dragging.​ The damage rectangle needs to be large enough to cover every pixel touched even in rotated versions.

​Maybe the ​

​"​

truncated​ expandBy: 1

​"​ should be something like "rounded outwards"?

But generally speaking, as long as we have the warpblt hack + integer coords instead of a proper hierarchical transform framework we will run into these rounding issues again and again.

Re: Found Bug But Not Sure How to Proceed To Fix

I guess Etoys always had a bit of a
preference for rounded corners and softer shapes, so it may be
expecting too much for rotated rectangles all to grid nicely along
their top (or left) edge. As it stands

- the expandBy: 1 ensures that the rotated
ones are drawn down and right from the non-rotated one

- even the rotated ones are drawn at
differing positions within the expanded bounds

- in trying to see if this second effect is
an error or some profound mathematical truth, I noticed (in
versions 3.2 through 5.1 anyway) that the fallback code in
WarpBlt>>warpBitsSmoothing:sourceMap: does not function
correctly in all cases. To see this, get a RectangleMorph and
rotate it with the blue handle. Then comment out the primitive
call in WarpBlt>>warpBitsSmoothing:sourceMap:
and try rotating the rectangle again. Different, eh? I guess
figuring this out is the first step in seeing if the rotated
rects could line up nicely.

Does anything bad
happen if the "expandBy: 1" is removed? I tried removing
it
in my Squeak trunk image, and "CompassDialMorph new
openInWorld" (which is one
user of TransformationMorph) seems to work nicely.

​I
bet it's there to avoid gribblies left behind when
dragging.​ The damage rectangle needs to be large enough
to cover every pixel touched even in rotated versions.

​Maybe
the ​

​"​

truncated​ expandBy: 1

​"​
should be something like "rounded outwards"?

But
generally speaking, as long as we have the warpblt hack
+ integer coords instead of a proper hierarchical
transform framework we will run into these rounding
issues again and again.

Re: Found Bug But Not Sure How to Proceed To Fix

Attached is a hack to keep rotated
rectangles (well, most anything rotated, but rectangles are were
it really shows) all aligning as one might expect them. It
basically assumes that the bounds have been expanded by 1 and
scoots the drawing back to the top left when rotated by 90, 18
or 270. See if you like it.

On 3/2/18 8:59 PM, Jeremy Landry wrote:

So far, with a little testing, everything lines up
much better with .1 instead of removing it. removing that
offset still sees to make it offset, but .1 lines everything up
visually more...still not perfect, but much less flagrant. It
still has a clipping glitch (you can see it with a rectangle
when rotating: the border gets clipped off) but it does visually
appear more 'solid' and expected when aligning rectangular
shapes together.

I'm going to keep experimenting to find something that
keeps the rotated bitmap in tact while still aligning
properly. I feel like I probably glanced at a method that
needs an edit over and over but haven't realized which one it
is yet. I still need to look into the cursor not being
properly redrawn as well. I might be stretching or trying to
make a connection that isn't there, but something 'feels'
related to this and the cursor, like some common reference
point is being shifted so that the cursor's area for drawing
doesn't reach the left and bottom edges just like the origin
doesn't reach the left and bottom edges correctly for the this
rotation issue.

Does
anything bad happen if the "expandBy: 1" is removed? I tried
removing it
in my Squeak trunk image, and "CompassDialMorph new
openInWorld" (which is one
user of TransformationMorph) seems to work nicely.

And if the "expandBy: 1" is removed in an Etoys image, does
anything bad happen?
Does it fix the issue that Jeremy is seeing?

This would be an easy thing to fix in Squeak trunk, which
hopefully will become
part of future Etoys releases, knock wood.

Dave

On Fri, Mar 02, 2018 at 03:19:54PM -0500, Bob Arning wrote:
> TransformationMorph>>computeBounds
> ?????? self hasSubmorphs ifTrue:
> ?????? ?????? [bounds _ (transform localBoundsToGlobal:
> ?????? ?????? ?????? ?????? ?????? (Rectangle merging:
> ?????? ?????? ?????? ?????? ?????? ?????? (self
submorphs collect: [:m | m
> fullBounds]))) truncated
> ?????? ?????? ?????? ?????? expandBy: 1].
> ?????? fullBounds _ bounds.>
> Note the expandBy: 1
>
>
> On 3/2/18 1:59 PM, Jeremy Landry wrote:
> >Actually to add a little more insight if
possible, you can create bug
> >with the following actions:
> >
> >make a new playfield
> >make 2 new rectangles and place them into the
playfield.
> >Rotate one of them 90 degrees.
> >Turn gridding on in the playfield.
> >
> >The rotated and unscaled rectangle will not align
with the non-rotated> >one with gridding.?? Something about making
a bitmap copy is offsetting> >the values, my guess is there's a
rounding problem that is popping up
> >on these objects, thus scale and rotation get
offset for some reason,
> >and specifically changes the origin by 1@-1
somewhere...it causes
> >graphical glitches leaving 'garbage' with
playfield indicators when
> >the object that has the indicator is moved and
also shows up with> >rotated ellipses.?? What is the common
thread through them all??? What> >method are they all accessing?
> >
> >On Fri, Mar 2, 2018 at 10:45 AM, Jeremy Landry
<[hidden email]> ><mailto:[hidden email]>>
wrote:
> >
> > You will also notice if you rotate any shape,
it becomes a bit> > map.?? Scale it and you will see that
problem re-occur even with
> > built-in objects.?? Could it be the masking
offset, too??? that
> > causes this??? I'm still investigating, but I'm
not sure how to> > step through 'already working'
things specifically related to what
> > I'm trying to look at.
> >
> > On Fri, Mar 2, 2018 at 10:42 AM, Jeremy
Landry <[hidden email]> > <mailto:[hidden email]>>
wrote:
> >
> > Hi, it only appears when scaling a morph.??
Here is> > example...it is my belief
(how does one step through code with
> > debugger if there's no bug happening?);
> >
> > Whatever code is common that scales
morphs is being offset
> > incorrectly. The first image shows the
'garbage' left behind> > by playfield indicator if that
option is set.?? It seems it was> > only tested in 'holders' and
thus likely not picked up during
> > 'intended' use.
> >
> > Next, two pictures show scaling as where
the misalignment> > starts.?? This might be why you
could not recreate bug;> > resizing rectangle changes
rectangle morph extent, whereas
> > scaling is a differnet piece of code and
therefore different
> > outcome.
> >> > Image included.?? This works with
*anything* scaled.> > https://imgur.com/a/6zEWq
> >
> > On Fri, Mar 2, 2018 at 10:20 AM, Bob
Arning> > <[hidden email]
<mailto:[hidden email]>>
wrote:
> >
> > I tried to recreate your example and
could not. How did
> > you create the two morphs in your
example? Are you certain
> > the read/gray morph does not have
some transparent pixels
> > along the top and left?
> >
> >
> > On 3/2/18 12:50 PM, Jeremy Landry
wrote:
> >> I did a little more digging, just
for the record...and it> >> turns out it's scaling
error.?? No matter what, scaling
> >> offsets morphs by 1@-1.?? I'm still
looking for where this
> >> occurs and why.?? So far, injecting
intentionally bad> >> values into bordered
morph and sketch classes hasn't> >> produced any change.?? It
'feels' like most of that code> >> isn't even used, but
then again, I might not have
> >> genuinely created a new object
with that code and system
> >> might have been giving me what
was already in system...
> >>
> >>
> >> On Fri, Mar 2, 2018 at 7:15 AM,
Bert Freudenberg> >> <[hidden email]
<mailto:[hidden email]>>
wrote:
> >>
> >> That bug tracker is pretty
much dead, since all
> >> ongoing development moved to
squeak.org> >> <http://squeak.org>.> >>
> >> The plan was to make a new
Etoys release based on the
> >> latest Squeak source base,
but we have not have
> >> enough developer time to make
that actually happen.
> >>
> >> - Bert -
> >>
> >> On 1 March 2018 at 06:03,
Nicco Kunzmann (rambler)
> >> <[hidden email]

> >> <mailto:[hidden email]>>
wrote:
> >>
> >> Hi,
> >>
> >> I found a bug tracker
on the squeakland site:
> >> http://tracker.squeakland.org/secure/Dashboard.jspa
> >> <http://tracker.squeakland.org/secure/Dashboard.jspa>
> >>
> >> I think, you can
describe the problem there as an
> >> issue and hand in the
fix.
> >> They may also know how
to guide you further if
> >> the code base is
somewhere else.
> >> If you have problems
there (login, no response),
> >> I guess, this mailing
list is one place to ask
> >> for help.
> >>
> >> Best,
> >> Nicco
> >>
> >>
> >> On 03/01/2018 03:34 AM,
Jeremy Landry wrote:
> >>> Hi, while working
on a project needing precise
> >>> alignment of
sketches/bitmaps and rectangles
> >>> using playfield
'use gridding', it seems that
> >>> there's a
difference of detected origin.
> >>>
> >>> Here's a screenshot
with magnifier showing the
> >>> discrepency.
> >>> https://imgur.com/a/tcaRu
> >>>
> >>> I'm quite certain
this bug is the one that
> >>> causes bad
redrawing, especially when showing a
> >>> cursor move when
'indicate cursor' is activated
> >>> in a playfield.
> >>>
> >>> If I correct this
bug inside of a project, will
> >>> it load into an
image where it has not been
> >>> fixed and be fixed?
> >>>
> >>> I haven't actually
fixed the bug yet, but didn't
> >>> want to waste time
on it if the fix will not
> >>> travel with the
project.
> >>>
> >>> Thanks in advance
for any input.
> >>>
> >>>
> >>>
_______________________________________________
> >>> squeakland mailing
list
> >>> [hidden email]