Re: Found Bug But Not Sure How to Proceed To Fix
Bob Arning <[email protected]> Sat, 3 Mar 2018 08:34:32 -0500
| Newsgroups | gmane.comp.lang.smalltalk.squeak.squeakland |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --===============7395924129356989997== Content-Type: multipart/alternative; boundary="------------313A8BB4C9DD04AE7DD408C6" Content-Language: en-US This is a multi-part message in MIME format. --------------313A8BB4C9DD04AE7DD408C6 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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 <[email protected] > <mailto:[email protected]>>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-bD51WKytQuId/fn+uklp/[email protected] > http://lists.squeakland.org/mailman/listinfo/squeakland --------------313A8BB4C9DD04AE7DD408C6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> <p><font face="Georgia">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</font></p> <p><font face="Georgia">- the expandBy: 1 ensures that the rotated ones are drawn down and right from the non-rotated one</font></p> <p><font face="Georgia">- even the rotated ones are drawn at differing positions within the expanded bounds</font></p> <p><font face="Georgia">- 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 </font><font face="Georgia">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.<br> </font></p> <br> <div class="moz-cite-prefix">On 3/3/18 7:44 AM, Bert Freudenberg wrote:<br> </div> <blockquote type="cite" cite="mid:CACnEXeewDdo_FYWM4T1roS_Df+pRc7PcZ4Rf9PjS-9qfjdeZmQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org"> <div dir="ltr"> <div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><span style="font-family:arial,sans-serif;color:rgb(34,34,34)">On 3 March 2018 at 02:37, David T. Lewis </span><span dir="ltr" style="font-family:arial,sans-serif;color:rgb(34,34,34)"><<a href="mailto:[email protected]" target="_blank" moz-do-not-send="true">[email protected]</a>></span><span style="font-family:arial,sans-serif;color:rgb(34,34,34)"> wrote:</span><br> </div> <div class="gmail_extra"> <div class="gmail_quote"> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Does anything bad happen if the "expandBy: 1" is removed? I tried removing it<br> in my Squeak trunk image, and "CompassDialMorph new openInWorld" (which is one<br> user of TransformationMorph) seems to work nicely.<br> </blockquote> <div><br> </div> <div> <div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">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.</div> </div> <br> </div> <div class="gmail_quote"> <div class="gmail_quote"> <div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0);display:inline">Maybe the </div> <div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0);display:inline">"</div> truncated expandBy: 1 <div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0);display:inline">" should be something like "rounded outwards"?</div> </div> <div class="gmail_quote"> <div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0);display:inline"><br> </div> </div> <div class="gmail_quote"> <div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0);display:inline">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.</div> <br> </div> <div class="gmail_quote"><br> </div> </div> <div class="gmail_quote"> <div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">- Bert -</div> <br> </div> </div> </div> <br> <fieldset class="mimeAttachmentHeader"></fieldset> <br> <pre wrap="">_______________________________________________ squeakland mailing list <a class="moz-txt-link-abbreviated" href="mailto:squeakland-bD51WKytQuId/fn+uklp/[email protected]">squeakland-bD51WKytQuId/fn+uklp/[email protected]</a> <a class="moz-txt-link-freetext" href="http://lists.squeakland.org/mailman/listinfo/squeakland">http://lists.squeakland.org/mailman/listinfo/squeakland</a> </pre> </blockquote> <br> </body> </html> --------------313A8BB4C9DD04AE7DD408C6-- --===============7395924129356989997== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18Kc3F1ZWFrbGFu ZCBtYWlsaW5nIGxpc3QKc3F1ZWFrbGFuZEBsaXN0cy5zcXVlYWtsYW5kLm9yZwpodHRwOi8vbGlz dHMuc3F1ZWFrbGFuZC5vcmcvbWFpbG1hbi9saXN0aW5mby9zcXVlYWtsYW5kCg== --===============7395924129356989997==--