<div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000">
Hi Tim!<div><br></div><div>Thank you for trying out Squeak 5.3! :-)</div><div><br></div><div>> <span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">every character I type destroys the shadow beneath the browser window.</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">I just checked. Having soft shadows enabled and tying in a code browser's text pane, the #dropShadow of that window is not destroyed on every keypress.</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><div style="font-size: 13.3333px"><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">> </span><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">something about the extent (?) of text-related morph extended far beyond the bottom of the area containing it (?) but that is all a distant memory to me now.</span><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"> </span></div><div style="font-size: 13.3333px"><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div style="font-size: 13.3333px"><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">There was a bug with #areasRemainingToFill: and invisible edge grips leaking "over the edge" :-) Does not happen anymore. There is also a test for this issue.</span></div></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">> </span><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"> This seems like a very big "damage area,"</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">Yeah, that's an unfortunate known bug. It happens because the resize grips of the window need a better layout implementation. Every keypress triggers a re-compution of the text field's paragraph and thus bubbles up a #layoutChanged up to the window. The window then calles those grips, which do not react with a "no op" but modify their geometry back and forth. So, unforunately, the resize grips do always interfere even though their layout does not change. You can delete those top/left/right/bottom grips and try again.</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">Still, I wonder why you notice it. Maybe it's an issue with graphics on macOS? I don't notice it in Windows.</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">Most time for those key presses is spent in text paragraph re-composing. You can bench it if you like. Here is some code. Just use the halo to inspect a text field, then run this code:</span></div><div><br></div><div><div style=""><span style="font-family: Arial, Helvetica, sans-serif"><span style="font-size: 13px">| textField keystroke |</span></span></div><div style=""><span style="font-family: Arial, Helvetica, sans-serif"><span style="font-size: 13px">textField := self.</span></span></div><div style=""><span style="font-family: Arial, Helvetica, sans-serif"><span style="font-size: 13px">keystroke := (UserInputEventTests new setUp</span></span></div><div style=""><span style="font-family: Arial, Helvetica, sans-serif"><span style="font-size: 13px"><span style="white-space:pre"> </span>keystroke: $x at: textField center).</span></span></div><div style=""><span style="font-family: Arial, Helvetica, sans-serif"><span style="font-size: 13px">textField containingWindow beKeyWindow. "show soft drop shadow"</span></span></div><div style=""><span style="font-family: Arial, Helvetica, sans-serif"><span style="font-size: 13px">[keystroke resetHandlerFields. textField processEvent: keystroke] bench. </span></span></div><div style=""><span style="font-family: Arial, Helvetica, sans-serif"><span style="font-size: 13px">"--- no grips --- '1,950 per second. 512 microseconds per run. 5.68 % GC time.'"</span></span></div><div style=""><span style="font-family: Arial, Helvetica, sans-serif"><span style="font-size: 13px">[keystroke resetHandlerFields. textField processEvent: keystroke] bench.</span></span></div><div style=""><span style="font-family: Arial, Helvetica, sans-serif"><span style="font-size: 13px">"--- with grips --- '2,030 per second. 492 microseconds per run. 5.5 % GC time.'"</span></span></div></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">The grips and thus shrinking damage area don't change thing. Bigger damage areas might, however, be an issue if you have multiple overlapping windows.</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">Best,</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">Marcel</span></div><div class="mb_sig"></div>
<blockquote class="history_container" type="cite" style="border-left-style: solid;border-width: 1px;margin-top: 20px;margin-left: 0px;padding-left: 10px;min-width: 500px">
<p style="color: #AAAAAA; margin-top: 10px;">Am 20.05.2020 22:46:49 schrieb Tim Johnson <digit@sonic.net>:</p><div style="font-family:Arial,Helvetica,sans-serif">Hi Squeakers,<div class=""><br class=""></div><div class="">Been away for a while, but trying out 5.3 now. Congratulations on another quality release.</div><div class=""><br class=""></div><div class="">I am wondering if anyone else has noticed typing into the code pane of a browser (seemingly a PluggableTextMorphPlus) being very slow*. I haven't tried it with Shout (if syntax highlighting is still called that) turned off.</div><div class=""><br class=""></div><div class="">I'm noticing this now: every character I type destroys the shadow beneath the browser window. This seems like a very big "damage area," so to speak. Could it have anything to do with the options I chose at the initial image configuration?</div><div class=""><br class=""></div><div class=""><div class="">Any chance this slowness has already been witnessed and repaired? Or is it just me? Happy to test any available fixes. Was about to run a little demo of Squeak for a coworker (in 22 minutes now), but ... maybe I'll go back to 5.2 for the demo.</div></div><div class=""><br class=""></div><div class="">FWIW, I do recall discovering, and submitting a fix for, another issue similar to this sometime in the last 2-3 years — something about the extent (?) of text-related morph extended far beyond the bottom of the area containing it (?) but that is all a distant memory to me now. My change was discussed on the list, but I don't recall if it was accepted into trunk (I think it was) and of course have no idea whether it was cherrypicked for release (if that's something that happens).</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Tim</div><div class=""><br class=""></div><div class="">* macOS 10.14, 64-bit, <i class=""><b class="">2.9 GHz 6-core Intel Core i9</b></i></div><div class=""><i class=""><b class=""><br class=""></b></i></div><div class=""><i class=""><b class=""><br class=""></b></i></div></div></blockquote></div>