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.
Hi,
I found a bug tracker on the squeakland site: 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 squeakland@lists.squeakland.org http://lists.squeakland.org/mailman/listinfo/squeakland
That bug tracker is pretty much dead, since all ongoing development moved to 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) <niccokunzmann@rambler.ru
wrote:
Hi,
I found a bug tracker on the squeakland site: 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 listsqueakland@lists.squeakland.orghttp://lists.squeakland.org/mailman/listinfo/squeakland
squeakland mailing list squeakland@lists.squeakland.org http://lists.squeakland.org/mailman/listinfo/squeakland
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 bert@freudenbergs.de wrote:
That bug tracker is pretty much dead, since all ongoing development moved to 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) < niccokunzmann@rambler.ru> wrote:
Hi,
I found a bug tracker on the squeakland site: 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 listsqueakland@lists.squeakland.orghttp://lists.squeakland.org/mailman/listinfo/squeakland
squeakland mailing list squeakland@lists.squeakland.org http://lists.squeakland.org/mailman/listinfo/squeakland
squeakland mailing list squeakland@lists.squeakland.org http://lists.squeakland.org/mailman/listinfo/squeakland
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 <bert@freudenbergs.de mailto:bert@freudenbergs.de> 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) <niccokunzmann@rambler.ru <mailto:niccokunzmann@rambler.ru>> 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 squeakland@lists.squeakland.org <mailto:squeakland@lists.squeakland.org> http://lists.squeakland.org/mailman/listinfo/squeakland <http://lists.squeakland.org/mailman/listinfo/squeakland>_______________________________________________ squeakland mailing list squeakland@lists.squeakland.org <mailto:squeakland@lists.squeakland.org> http://lists.squeakland.org/mailman/listinfo/squeakland <http://lists.squeakland.org/mailman/listinfo/squeakland> _______________________________________________ squeakland mailing list squeakland@lists.squeakland.org <mailto:squeakland@lists.squeakland.org> http://lists.squeakland.org/mailman/listinfo/squeakland <http://lists.squeakland.org/mailman/listinfo/squeakland>
squeakland mailing list squeakland@lists.squeakland.org http://lists.squeakland.org/mailman/listinfo/squeakland
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 arning315@comcast.net 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 bert@freudenbergs.de wrote:
That bug tracker is pretty much dead, since all ongoing development moved to 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) < niccokunzmann@rambler.ru> wrote:
Hi,
I found a bug tracker on the squeakland site: 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 listsqueakland@lists.squeakland.orghttp://lists.squeakland.org/mailman/listinfo/squeakland
squeakland mailing list squeakland@lists.squeakland.org http://lists.squeakland.org/mailman/listinfo/squeakland
squeakland mailing list squeakland@lists.squeakland.org http://lists.squeakland.org/mailman/listinfo/squeakland
squeakland mailing listsqueakland@lists.squeakland.orghttp://lists.squeakland.org/mailman/listinfo/squeakland
squeakland mailing list squeakland@lists.squeakland.org http://lists.squeakland.org/mailman/listinfo/squeakland
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 hakyoku@gmail.com 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 arning315@comcast.net 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 bert@freudenbergs.de wrote:
That bug tracker is pretty much dead, since all ongoing development moved to 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) < niccokunzmann@rambler.ru> wrote:
Hi,
I found a bug tracker on the squeakland site: 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 listsqueakland@lists.squeakland.orghttp://lists.squeakland.org/mailman/listinfo/squeakland
squeakland mailing list squeakland@lists.squeakland.org http://lists.squeakland.org/mailman/listinfo/squeakland
squeakland mailing list squeakland@lists.squeakland.org http://lists.squeakland.org/mailman/listinfo/squeakland
squeakland mailing listsqueakland@lists.squeakland.orghttp://lists.squeakland.org/mailman/listinfo/squeakland
squeakland mailing list squeakland@lists.squeakland.org http://lists.squeakland.org/mailman/listinfo/squeakland
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 hakyoku@gmail.com 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 hakyoku@gmail.com 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 arning315@comcast.net 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 bert@freudenbergs.de wrote:
That bug tracker is pretty much dead, since all ongoing development moved to 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) < niccokunzmann@rambler.ru> wrote:
Hi,
I found a bug tracker on the squeakland site: 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 listsqueakland@lists.squeakland.orghttp://lists.squeakland.org/mailman/listinfo/squeakland
squeakland mailing list squeakland@lists.squeakland.org http://lists.squeakland.org/mailman/listinfo/squeakland
squeakland mailing list squeakland@lists.squeakland.org http://lists.squeakland.org/mailman/listinfo/squeakland
squeakland mailing listsqueakland@lists.squeakland.orghttp://lists.squeakland.org/mailman/listinfo/squeakland
squeakland mailing list squeakland@lists.squeakland.org http://lists.squeakland.org/mailman/listinfo/squeakland
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 <hakyoku@gmail.com mailto:hakyoku@gmail.com> 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 <hakyoku@gmail.com <mailto:hakyoku@gmail.com>> 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 <arning315@comcast.net <mailto:arning315@comcast.net>> 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 <bert@freudenbergs.de <mailto:bert@freudenbergs.de>> 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) <niccokunzmann@rambler.ru <mailto:niccokunzmann@rambler.ru>> 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 squeakland@lists.squeakland.org <mailto:squeakland@lists.squeakland.org> http://lists.squeakland.org/mailman/listinfo/squeakland <http://lists.squeakland.org/mailman/listinfo/squeakland>_______________________________________________ squeakland mailing list squeakland@lists.squeakland.org <mailto:squeakland@lists.squeakland.org> http://lists.squeakland.org/mailman/listinfo/squeakland <http://lists.squeakland.org/mailman/listinfo/squeakland> _______________________________________________ squeakland mailing list squeakland@lists.squeakland.org <mailto:squeakland@lists.squeakland.org> http://lists.squeakland.org/mailman/listinfo/squeakland <http://lists.squeakland.org/mailman/listinfo/squeakland> _______________________________________________ squeakland mailing list squeakland@lists.squeakland.org <mailto:squeakland@lists.squeakland.org> http://lists.squeakland.org/mailman/listinfo/squeakland <http://lists.squeakland.org/mailman/listinfo/squeakland>_______________________________________________ squeakland mailing list squeakland@lists.squeakland.org <mailto:squeakland@lists.squeakland.org> http://lists.squeakland.org/mailman/listinfo/squeakland <http://lists.squeakland.org/mailman/listinfo/squeakland>
Thanks for the tip. I was finding myself in WarpBlt (nothing I messed with was causing any changes there!)
Throwing in random values definitely makes a change here.
On Fri, Mar 2, 2018 at 12:19 PM, Bob Arning arning315@comcast.net 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 hakyoku@gmail.com 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 hakyoku@gmail.com 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 arning315@comcast.net 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 bert@freudenbergs.de wrote:
That bug tracker is pretty much dead, since all ongoing development moved to 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) < niccokunzmann@rambler.ru> wrote:
Hi,
I found a bug tracker on the squeakland site: 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 listsqueakland@lists.squeakland.orghttp://lists.squeakland.org/mailman/listinfo/squeakland
squeakland mailing list squeakland@lists.squeakland.org http://lists.squeakland.org/mailman/listinfo/squeakland
squeakland mailing list squeakland@lists.squeakland.org http://lists.squeakland.org/mailman/listinfo/squeakland
squeakland mailing listsqueakland@lists.squeakland.orghttp://lists.squeakland.org/mailman/listinfo/squeakland
squeakland mailing list squeakland@lists.squeakland.org http://lists.squeakland.org/mailman/listinfo/squeakland
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 <hakyoku@gmail.com mailto:hakyoku@gmail.com> 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 <hakyoku@gmail.com mailto:hakyoku@gmail.com> 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 <arning315@comcast.net <mailto:arning315@comcast.net>> 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 <bert@freudenbergs.de <mailto:bert@freudenbergs.de>> 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) <niccokunzmann@rambler.ru <mailto:niccokunzmann@rambler.ru>> 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 squeakland@lists.squeakland.org <mailto:squeakland@lists.squeakland.org> http://lists.squeakland.org/mailman/listinfo/squeakland <http://lists.squeakland.org/mailman/listinfo/squeakland>_______________________________________________ squeakland mailing list squeakland@lists.squeakland.org <mailto:squeakland@lists.squeakland.org> http://lists.squeakland.org/mailman/listinfo/squeakland <http://lists.squeakland.org/mailman/listinfo/squeakland> _______________________________________________ squeakland mailing list squeakland@lists.squeakland.org <mailto:squeakland@lists.squeakland.org> http://lists.squeakland.org/mailman/listinfo/squeakland <http://lists.squeakland.org/mailman/listinfo/squeakland> _______________________________________________ squeakland mailing list squeakland@lists.squeakland.org <mailto:squeakland@lists.squeakland.org> http://lists.squeakland.org/mailman/listinfo/squeakland <http://lists.squeakland.org/mailman/listinfo/squeakland>_______________________________________________ squeakland mailing list squeakland@lists.squeakland.org <mailto:squeakland@lists.squeakland.org> http://lists.squeakland.org/mailman/listinfo/squeakland <http://lists.squeakland.org/mailman/listinfo/squeakland>
squeakland mailing list squeakland@lists.squeakland.org http://lists.squeakland.org/mailman/listinfo/squeakland
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.
On Fri, Mar 2, 2018 at 5:37 PM, David T. Lewis lewis@mail.msen.com wrote:
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 <hakyoku@gmail.com mailto:hakyoku@gmail.com> 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 <hakyoku@gmail.com mailto:hakyoku@gmail.com> 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 <arning315@comcast.net <mailto:arning315@comcast.net>> 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 <bert@freudenbergs.de <mailto:bert@freudenbergs.de>>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) <niccokunzmann@rambler.ru <mailto:niccokunzmann@rambler.ru>> 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 squeakland@lists.squeakland.org <mailto:squeakland@lists.squeakland.org> http://lists.squeakland.org/mailman/listinfo/squeakland
<http://lists.squeakland.org/mailman/listinfo/squeakland>
_______________________________________________ squeakland mailing list squeakland@lists.squeakland.org <mailto:squeakland@lists.squeakland.org> http://lists.squeakland.org/mailman/listinfo/squeakland
<http://lists.squeakland.org/mailman/listinfo/squeakland>
_______________________________________________ squeakland mailing list squeakland@lists.squeakland.org <mailto:squeakland@lists.squeakland.org> http://lists.squeakland.org/mailman/listinfo/squeakland
<http://lists.squeakland.org/mailman/listinfo/squeakland>
_______________________________________________ squeakland mailing list squeakland@lists.squeakland.org <mailto:squeakland@lists.squeakland.org> http://lists.squeakland.org/mailman/listinfo/squeakland <http://lists.squeakland.org/mailman/listinfo/squeakland>_______________________________________________ squeakland mailing list squeakland@lists.squeakland.org <mailto:squeakland@lists.squeakland.org> http://lists.squeakland.org/mailman/listinfo/squeakland <http://lists.squeakland.org/mailman/listinfo/squeakland>
squeakland mailing list squeakland@lists.squeakland.org http://lists.squeakland.org/mailman/listinfo/squeakland
squeakland mailing list squeakland@lists.squeakland.org http://lists.squeakland.org/mailman/listinfo/squeakland
And I can back that up, now...
PasteUpMorph cursor _also_ uses the expandBy: method and has redrawing issues.
Somehow I think morphs are either giving wrong information to the the expandBy: method or expandBy: is doing it's own calculations incorrectly....
Change the expandBy: to any number and the cursor square will change (use a larger number, btw) and it will still not erase correctly. It has a 2 pixel offset, the same as the thickness of the cursor.
On Fri, Mar 2, 2018 at 5:59 PM, Jeremy Landry hakyoku@gmail.com 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.
On Fri, Mar 2, 2018 at 5:37 PM, David T. Lewis lewis@mail.msen.com wrote:
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 <hakyoku@gmail.com mailto:hakyoku@gmail.com> 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 <hakyoku@gmail.com mailto:hakyoku@gmail.com> 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 <arning315@comcast.net <mailto:arning315@comcast.net>> 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 wherethis
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 <bert@freudenbergs.de <mailto:bert@freudenbergs.de>>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) <niccokunzmann@rambler.ru <mailto:niccokunzmann@rambler.ru>> 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 squeakland@lists.squeakland.org <mailto:squeakland@lists.squeakland.org> http://lists.squeakland.org/mailman/listinfo/squeakland
<http://lists.squeakland.org/mailman/listinfo/squeakland>
_______________________________________________ squeakland mailing list squeakland@lists.squeakland.org <mailto:squeakland@lists.squeakland.org> http://lists.squeakland.org/mailman/listinfo/squeakland
<http://lists.squeakland.org/mailman/listinfo/squeakland>
_______________________________________________ squeakland mailing list squeakland@lists.squeakland.org <mailto:squeakland@lists.squeakland.org> http://lists.squeakland.org/mailman/listinfo/squeakland
<http://lists.squeakland.org/mailman/listinfo/squeakland>
_______________________________________________ squeakland mailing list squeakland@lists.squeakland.org <mailto:squeakland@lists.squeakland.org> http://lists.squeakland.org/mailman/listinfo/squeakland <http://lists.squeakland.org/mailman/listinfo/squeakland>_______________________________________________ squeakland mailing list squeakland@lists.squeakland.org <mailto:squeakland@lists.squeakland.org> http://lists.squeakland.org/mailman/listinfo/squeakland <http://lists.squeakland.org/mailman/listinfo/squeakland>
squeakland mailing list squeakland@lists.squeakland.org http://lists.squeakland.org/mailman/listinfo/squeakland
squeakland mailing list squeakland@lists.squeakland.org http://lists.squeakland.org/mailman/listinfo/squeakland
Apologies, correctly to the PasteUp method...it's PasteupMorph selectedRect
On Fri, Mar 2, 2018 at 6:18 PM, Jeremy Landry hakyoku@gmail.com wrote:
And I can back that up, now...
PasteUpMorph cursor _also_ uses the expandBy: method and has redrawing issues.
Somehow I think morphs are either giving wrong information to the the expandBy: method or expandBy: is doing it's own calculations incorrectly....
Change the expandBy: to any number and the cursor square will change (use a larger number, btw) and it will still not erase correctly. It has a 2 pixel offset, the same as the thickness of the cursor.
On Fri, Mar 2, 2018 at 5:59 PM, Jeremy Landry hakyoku@gmail.com 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.
On Fri, Mar 2, 2018 at 5:37 PM, David T. Lewis lewis@mail.msen.com wrote:
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 <hakyoku@gmail.com mailto:hakyoku@gmail.com> 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 <hakyoku@gmail.com mailto:hakyoku@gmail.com> 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 itwas
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 <arning315@comcast.net <mailto:arning315@comcast.net>> 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 wherethis
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 <bert@freudenbergs.de <mailto:bert@freudenbergs.de>>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) <niccokunzmann@rambler.ru <mailto:niccokunzmann@rambler.ru>> 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 > squeakland@lists.squeakland.org > mailto:squeakland@lists.squeakland.org > http://lists.squeakland.org/ma
ilman/listinfo/squeakland
ailman/listinfo/squeakland>
_______________________________________________ squeakland mailing list squeakland@lists.squeakland.org <mailto:squeakland@lists.squeakland.org> http://lists.squeakland.org/mailman/listinfo/squeakland
<http://lists.squeakland.org/mailman/listinfo/squeakland>
_______________________________________________ squeakland mailing list squeakland@lists.squeakland.org <mailto:squeakland@lists.squeakland.org> http://lists.squeakland.org/mailman/listinfo/squeakland
<http://lists.squeakland.org/mailman/listinfo/squeakland>
_______________________________________________ squeakland mailing list squeakland@lists.squeakland.org <mailto:squeakland@lists.squeakland.org> http://lists.squeakland.org/mailman/listinfo/squeakland <http://lists.squeakland.org/mailman/listinfo/squeakland_______________________________________________ squeakland mailing list squeakland@lists.squeakland.org <mailto:squeakland@lists.squeakland.org> http://lists.squeakland.org/mailman/listinfo/squeakland <http://lists.squeakland.org/mailman/listinfo/squeakland>
squeakland mailing list squeakland@lists.squeakland.org http://lists.squeakland.org/mailman/listinfo/squeakland
squeakland mailing list squeakland@lists.squeakland.org http://lists.squeakland.org/mailman/listinfo/squeakland
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...
On Fri, Mar 2, 2018 at 6:18 PM, Jeremy Landry hakyoku@gmail.com wrote:
And I can back that up, now...
PasteUpMorph cursor _also_ uses the expandBy: method and has redrawing issues.
Somehow I think morphs are either giving wrong information to the the expandBy: method or expandBy: is doing it's own calculations incorrectly....
Change the expandBy: to any number and the cursor square will change (use a larger number, btw) and it will still not erase correctly. It has a 2 pixel offset, the same as the thickness of the cursor.
On Fri, Mar 2, 2018 at 5:59 PM, Jeremy Landry hakyoku@gmail.com 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.
On Fri, Mar 2, 2018 at 5:37 PM, David T. Lewis lewis@mail.msen.com wrote:
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 <hakyoku@gmail.com mailto:hakyoku@gmail.com> 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 <hakyoku@gmail.com mailto:hakyoku@gmail.com> 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 itwas
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 <arning315@comcast.net <mailto:arning315@comcast.net>> 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 wherethis
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 <bert@freudenbergs.de <mailto:bert@freudenbergs.de>>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) <niccokunzmann@rambler.ru <mailto:niccokunzmann@rambler.ru>> 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 > squeakland@lists.squeakland.org > mailto:squeakland@lists.squeakland.org > http://lists.squeakland.org/ma
ilman/listinfo/squeakland
ailman/listinfo/squeakland>
_______________________________________________ squeakland mailing list squeakland@lists.squeakland.org <mailto:squeakland@lists.squeakland.org> http://lists.squeakland.org/mailman/listinfo/squeakland
<http://lists.squeakland.org/mailman/listinfo/squeakland>
_______________________________________________ squeakland mailing list squeakland@lists.squeakland.org <mailto:squeakland@lists.squeakland.org> http://lists.squeakland.org/mailman/listinfo/squeakland
<http://lists.squeakland.org/mailman/listinfo/squeakland>
_______________________________________________ squeakland mailing list squeakland@lists.squeakland.org <mailto:squeakland@lists.squeakland.org> http://lists.squeakland.org/mailman/listinfo/squeakland <http://lists.squeakland.org/mailman/listinfo/squeakland_______________________________________________ squeakland mailing list squeakland@lists.squeakland.org <mailto:squeakland@lists.squeakland.org> http://lists.squeakland.org/mailman/listinfo/squeakland <http://lists.squeakland.org/mailman/listinfo/squeakland>
squeakland mailing list squeakland@lists.squeakland.org http://lists.squeakland.org/mailman/listinfo/squeakland
squeakland mailing list squeakland@lists.squeakland.org http://lists.squeakland.org/mailman/listinfo/squeakland
Here is a little help in visualizing the problem with rotated rectangles.
========================
FormCanvas>>transformBy: aDisplayTransform clippingTo: aClipRect during: aBlock smoothing: cellSize
"Note: This method has been originally copied from TransformationMorph." | innerRect patchRect sourceQuad warp start subCanvas | (aDisplayTransform isPureTranslation) ifTrue:[ ^aBlock value: (self copyOffset: aDisplayTransform offset negated truncated clipRect: aClipRect) ]. "Prepare an appropriate warp from patch to innerRect" innerRect := aClipRect. *self fillRectangle: aClipRect color: Color magenta. "<---show the space we are working in"* patchRect := (aDisplayTransform globalBoundsToLocal: innerRect) truncated. sourceQuad := (aDisplayTransform sourceQuadFor: innerRect) collect: [:p | p - patchRect topLeft]. warp := self warpFrom: sourceQuad toRect: innerRect.
"Render the submorphs visible in the clipping rectangle, as patchForm" start := (self depth = 1 and: [self isShadowDrawing not]) "If this is true B&W, then we need a first pass for erasure." ifTrue: [1] ifFalse: [2]. start to: 2 do: [:i | "If i=1 we first make a shadow and erase it for opaque whites in B&W" subCanvas := self class extent: patchRect extent depth: self depth. i=1 ifTrue: [subCanvas shadowColor: Color black. warp combinationRule: Form erase] ifFalse: [self isShadowDrawing ifTrue: [subCanvas shadowColor: self shadowColor]. warp combinationRule: Form paint]. subCanvas translateBy: patchRect topLeft negated during:[:offsetCanvas| aBlock value: offsetCanvas]. warp sourceForm: subCanvas form; cellSize: cellSize; warpBits. warp sourceForm: nil. subCanvas := nil "release space for next loop"]
=======================
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...
On Fri, Mar 2, 2018 at 6:18 PM, Jeremy Landry <hakyoku@gmail.com mailto:hakyoku@gmail.com> wrote:
And I can back that up, now... PasteUpMorph cursor _also_ uses the expandBy: method and has redrawing issues. Somehow I think morphs are either giving wrong information to the the expandBy: method or expandBy: is doing it's own calculations incorrectly.... Change the expandBy: to any number and the cursor square will change (use a larger number, btw) and it will still not erase correctly. It has a 2 pixel offset, the same as the thickness of the cursor. On Fri, Mar 2, 2018 at 5:59 PM, Jeremy Landry <hakyoku@gmail.com <mailto:hakyoku@gmail.com>> 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. On Fri, Mar 2, 2018 at 5:37 PM, David T. Lewis <lewis@mail.msen.com <mailto:lewis@mail.msen.com>> wrote: 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 <hakyoku@gmail.com <mailto:hakyoku@gmail.com> > ><mailto:hakyoku@gmail.com <mailto:hakyoku@gmail.com>>> 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 <hakyoku@gmail.com <mailto:hakyoku@gmail.com> > > <mailto:hakyoku@gmail.com <mailto:hakyoku@gmail.com>>> 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 > > <arning315@comcast.net <mailto:arning315@comcast.net> <mailto:arning315@comcast.net <mailto:arning315@comcast.net>>> 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 > >> <bert@freudenbergs.de <mailto:bert@freudenbergs.de> <mailto:bert@freudenbergs.de <mailto:bert@freudenbergs.de>>> wrote: > >> > >> That bug tracker is pretty much dead, since all > >> ongoing development moved to squeak.org <http://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) > >> <niccokunzmann@rambler.ru <mailto:niccokunzmann@rambler.ru> > >> <mailto:niccokunzmann@rambler.ru <mailto:niccokunzmann@rambler.ru>>> 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> > >> <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 > >>> squeakland@lists.squeakland.org <mailto:squeakland@lists.squeakland.org> > >>> <mailto:squeakland@lists.squeakland.org <mailto:squeakland@lists.squeakland.org>> > >>> http://lists.squeakland.org/mailman/listinfo/squeakland <http://lists.squeakland.org/mailman/listinfo/squeakland> > >>> <http://lists.squeakland.org/mailman/listinfo/squeakland <http://lists.squeakland.org/mailman/listinfo/squeakland>> > >> > >> > >> _______________________________________________ > >> squeakland mailing list > >> squeakland@lists.squeakland.org <mailto:squeakland@lists.squeakland.org> > >> <mailto:squeakland@lists.squeakland.org <mailto:squeakland@lists.squeakland.org>> > >> http://lists.squeakland.org/mailman/listinfo/squeakland <http://lists.squeakland.org/mailman/listinfo/squeakland> > >> <http://lists.squeakland.org/mailman/listinfo/squeakland <http://lists.squeakland.org/mailman/listinfo/squeakland>> > >> > >> > >> > >> _______________________________________________ > >> squeakland mailing list > >> squeakland@lists.squeakland.org <mailto:squeakland@lists.squeakland.org> > >> <mailto:squeakland@lists.squeakland.org <mailto:squeakland@lists.squeakland.org>> > >> http://lists.squeakland.org/mailman/listinfo/squeakland <http://lists.squeakland.org/mailman/listinfo/squeakland> > >> <http://lists.squeakland.org/mailman/listinfo/squeakland <http://lists.squeakland.org/mailman/listinfo/squeakland>> > >> > >> > >> > >> > >> _______________________________________________ > >> squeakland mailing list > >> squeakland@lists.squeakland.org <mailto:squeakland@lists.squeakland.org> > >> <mailto:squeakland@lists.squeakland.org <mailto:squeakland@lists.squeakland.org>> > >> http://lists.squeakland.org/mailman/listinfo/squeakland <http://lists.squeakland.org/mailman/listinfo/squeakland> > >> <http://lists.squeakland.org/mailman/listinfo/squeakland <http://lists.squeakland.org/mailman/listinfo/squeakland>> > > > > > > _______________________________________________ > > squeakland mailing list > > squeakland@lists.squeakland.org <mailto:squeakland@lists.squeakland.org> > > <mailto:squeakland@lists.squeakland.org <mailto:squeakland@lists.squeakland.org>> > > http://lists.squeakland.org/mailman/listinfo/squeakland <http://lists.squeakland.org/mailman/listinfo/squeakland> > > <http://lists.squeakland.org/mailman/listinfo/squeakland <http://lists.squeakland.org/mailman/listinfo/squeakland>> > > > > > > > > > > _______________________________________________ > squeakland mailing list > squeakland@lists.squeakland.org <mailto:squeakland@lists.squeakland.org> > http://lists.squeakland.org/mailman/listinfo/squeakland <http://lists.squeakland.org/mailman/listinfo/squeakland> _______________________________________________ squeakland mailing list squeakland@lists.squeakland.org <mailto:squeakland@lists.squeakland.org> http://lists.squeakland.org/mailman/listinfo/squeakland <http://lists.squeakland.org/mailman/listinfo/squeakland>
squeakland mailing list squeakland@lists.squeakland.org http://lists.squeakland.org/mailman/listinfo/squeakland
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.
On Fri, Mar 2, 2018 at 5:37 PM, David T. Lewis <lewis@mail.msen.com mailto:lewis@mail.msen.com> wrote:
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 <hakyoku@gmail.com <mailto:hakyoku@gmail.com> > ><mailto:hakyoku@gmail.com <mailto:hakyoku@gmail.com>>> 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 <hakyoku@gmail.com <mailto:hakyoku@gmail.com> > > <mailto:hakyoku@gmail.com <mailto:hakyoku@gmail.com>>> 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 > > <arning315@comcast.net <mailto:arning315@comcast.net> <mailto:arning315@comcast.net <mailto:arning315@comcast.net>>> 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 > >> <bert@freudenbergs.de <mailto:bert@freudenbergs.de> <mailto:bert@freudenbergs.de <mailto:bert@freudenbergs.de>>> wrote: > >> > >> That bug tracker is pretty much dead, since all > >> ongoing development moved to squeak.org <http://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) > >> <niccokunzmann@rambler.ru <mailto:niccokunzmann@rambler.ru> > >> <mailto:niccokunzmann@rambler.ru <mailto:niccokunzmann@rambler.ru>>> 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> > >> <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 > >>> squeakland@lists.squeakland.org <mailto:squeakland@lists.squeakland.org> > >>> <mailto:squeakland@lists.squeakland.org <mailto:squeakland@lists.squeakland.org>> > >>> http://lists.squeakland.org/mailman/listinfo/squeakland <http://lists.squeakland.org/mailman/listinfo/squeakland> > >>> <http://lists.squeakland.org/mailman/listinfo/squeakland <http://lists.squeakland.org/mailman/listinfo/squeakland>> > >> > >> > >> _______________________________________________ > >> squeakland mailing list > >> squeakland@lists.squeakland.org <mailto:squeakland@lists.squeakland.org> > >> <mailto:squeakland@lists.squeakland.org <mailto:squeakland@lists.squeakland.org>> > >> http://lists.squeakland.org/mailman/listinfo/squeakland <http://lists.squeakland.org/mailman/listinfo/squeakland> > >> <http://lists.squeakland.org/mailman/listinfo/squeakland <http://lists.squeakland.org/mailman/listinfo/squeakland>> > >> > >> > >> > >> _______________________________________________ > >> squeakland mailing list > >> squeakland@lists.squeakland.org <mailto:squeakland@lists.squeakland.org> > >> <mailto:squeakland@lists.squeakland.org <mailto:squeakland@lists.squeakland.org>> > >> http://lists.squeakland.org/mailman/listinfo/squeakland <http://lists.squeakland.org/mailman/listinfo/squeakland> > >> <http://lists.squeakland.org/mailman/listinfo/squeakland <http://lists.squeakland.org/mailman/listinfo/squeakland>> > >> > >> > >> > >> > >> _______________________________________________ > >> squeakland mailing list > >> squeakland@lists.squeakland.org <mailto:squeakland@lists.squeakland.org> > >> <mailto:squeakland@lists.squeakland.org <mailto:squeakland@lists.squeakland.org>> > >> http://lists.squeakland.org/mailman/listinfo/squeakland <http://lists.squeakland.org/mailman/listinfo/squeakland> > >> <http://lists.squeakland.org/mailman/listinfo/squeakland <http://lists.squeakland.org/mailman/listinfo/squeakland>> > > > > > > _______________________________________________ > > squeakland mailing list > > squeakland@lists.squeakland.org <mailto:squeakland@lists.squeakland.org> > > <mailto:squeakland@lists.squeakland.org <mailto:squeakland@lists.squeakland.org>> > > http://lists.squeakland.org/mailman/listinfo/squeakland <http://lists.squeakland.org/mailman/listinfo/squeakland> > > <http://lists.squeakland.org/mailman/listinfo/squeakland <http://lists.squeakland.org/mailman/listinfo/squeakland>> > > > > > > > > > > _______________________________________________ > squeakland mailing list > squeakland@lists.squeakland.org <mailto:squeakland@lists.squeakland.org> > http://lists.squeakland.org/mailman/listinfo/squeakland <http://lists.squeakland.org/mailman/listinfo/squeakland> _______________________________________________ squeakland mailing list squeakland@lists.squeakland.org <mailto:squeakland@lists.squeakland.org> http://lists.squeakland.org/mailman/listinfo/squeakland <http://lists.squeakland.org/mailman/listinfo/squeakland>
squeakland mailing list squeakland@lists.squeakland.org http://lists.squeakland.org/mailman/listinfo/squeakland
I had thought about doing this as a hack to leave the rest of the system alone, as well. I'm still trying to find why playfield cursors are boogered up as much as they are. It's *really* bad...my personal 'hack' is just to make a new default playfield as an etoys button as a 'new project template' that replaces the cursor with a another etoys rectangle that can be toggled, but hack up on hack upon hack isn't really...well, it's certainly not ideal. I am also looking at cuis smalltalk a little to find out if there's anything in there that was fixed that might be portable back into etoys to fix this. It still 'feels' like these little anomolies have a common origin. From what I understand, Cuis deleted a lot of things and then re-inserted them one by one from the lowest level first and went from there. Someone on that project might have found a fix that would work here too...
On Sat, Mar 3, 2018 at 1:28 PM, Bob Arning arning315@comcast.net wrote:
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.
On Fri, Mar 2, 2018 at 5:37 PM, David T. Lewis lewis@mail.msen.com wrote:
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 <hakyoku@gmail.com mailto:hakyoku@gmail.com> 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 <hakyoku@gmail.com mailto:hakyoku@gmail.com> 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 <arning315@comcast.net <mailto:arning315@comcast.net>> 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 wherethis
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 <bert@freudenbergs.de <mailto:bert@freudenbergs.de>>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) <niccokunzmann@rambler.ru <mailto:niccokunzmann@rambler.ru>> 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 squeakland@lists.squeakland.org <mailto:squeakland@lists.squeakland.org> http://lists.squeakland.org/mailman/listinfo/squeakland
<http://lists.squeakland.org/mailman/listinfo/squeakland>
_______________________________________________ squeakland mailing list squeakland@lists.squeakland.org <mailto:squeakland@lists.squeakland.org> http://lists.squeakland.org/mailman/listinfo/squeakland
<http://lists.squeakland.org/mailman/listinfo/squeakland>
_______________________________________________ squeakland mailing list squeakland@lists.squeakland.org <mailto:squeakland@lists.squeakland.org> http://lists.squeakland.org/mailman/listinfo/squeakland
<http://lists.squeakland.org/mailman/listinfo/squeakland>
_______________________________________________ squeakland mailing list squeakland@lists.squeakland.org <mailto:squeakland@lists.squeakland.org> http://lists.squeakland.org/mailman/listinfo/squeakland <http://lists.squeakland.org/mailman/listinfo/squeakland>_______________________________________________ squeakland mailing list squeakland@lists.squeakland.org <mailto:squeakland@lists.squeakland.org> http://lists.squeakland.org/mailman/listinfo/squeakland <http://lists.squeakland.org/mailman/listinfo/squeakland>
squeakland mailing list squeakland@lists.squeakland.org http://lists.squeakland.org/mailman/listinfo/squeakland
squeakland mailing list squeakland@lists.squeakland.org http://lists.squeakland.org/mailman/listinfo/squeakland
squeakland mailing listsqueakland@lists.squeakland.orghttp://lists.squeakland.org/mailman/listinfo/squeakland
squeakland mailing list squeakland@lists.squeakland.org http://lists.squeakland.org/mailman/listinfo/squeakland
On 3 March 2018 at 02:37, David T. Lewis lewis@mail.msen.com wrote:
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.
- Bert -
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.
On 3/3/18 7:44 AM, Bert Freudenberg wrote:
On 3 March 2018 at 02:37, David T. Lewis <lewis@mail.msen.com mailto:lewis@mail.msen.com>wrote:
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.
- Bert -
squeakland mailing list squeakland@lists.squeakland.org http://lists.squeakland.org/mailman/listinfo/squeakland
Which option is it that makes this appear?
On 3/2/18 1:42 PM, Jeremy Landry wrote:
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.
It was 'lumped in' with my earlier report, but inside 'playfield options' is 'indicate cursor'. Anything you move or resize with a playfield cursor leaves garbage everywehre. This was what i was using for testing out warpblt edits.
On Sat, Mar 3, 2018 at 3:23 PM, Bob Arning arning315@comcast.net wrote:
Which option is it that makes this appear?
On 3/2/18 1:42 PM, Jeremy Landry wrote:
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.
Well, here's something you could try...
'From Squeak3.2gamma of 15 January 2002 [latest update: #4743] on 3 March 2018 at 9:02:03 pm'!
!PasteUpMorph methodsFor: 'misc' stamp: 'raa 3/3/2018 21:00'! invalidRect: damageRect from: aMorph "Clip damage reports to my bounds, since drawing is clipped to my bounds."
self == self outermostWorldMorph ifTrue: [worldState recordDamagedRect: (damageRect intersect: self bounds)] ifFalse: [super invalidRect: (self indicateCursor ifTrue: [self bounds] ifFalse: [damageRect]) from: aMorph] ! !
On 3/3/18 7:45 PM, Jeremy Landry wrote:
It was 'lumped in' with my earlier report, but inside 'playfield options' is 'indicate cursor'. Anything you move or resize with a playfield cursor leaves garbage everywehre. This was what i was using for testing out warpblt edits.
On Sat, Mar 3, 2018 at 3:23 PM, Bob Arning <arning315@comcast.net mailto:arning315@comcast.net> wrote:
Which option is it that makes this appear? On 3/2/18 1:42 PM, Jeremy Landry wrote: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.
On 1 March 2018 at 03:34, Jeremy Landry hakyoku@gmail.com 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?
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.
- Bert -
squeakland@lists.squeakfoundation.org
-
Bert Freudenberg -
Bob Arning -
David T. Lewis -
Jeremy Landry -
Nicco Kunzmann (rambler)