Hi Tim!

Thank you for trying out Squeak 5.3! :-)

> every character I type destroys the shadow beneath the browser window.

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.

> 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. 

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.

>  This seems like a very big "damage area,"

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.

Still, I wonder why you notice it. Maybe it's an issue with graphics on macOS? I don't notice it in Windows.

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:

| textField keystroke |
textField := self.
keystroke := (UserInputEventTests new setUp
keystroke: $x at: textField center).
textField containingWindow beKeyWindow. "show soft drop shadow"
[keystroke resetHandlerFields. textField processEvent: keystroke] bench. 
"--- no grips --- '1,950 per second. 512 microseconds per run. 5.68 % GC time.'"
[keystroke resetHandlerFields. textField processEvent: keystroke] bench.
"--- with grips --- '2,030 per second. 492 microseconds per run. 5.5 % GC time.'"

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.

Best,
Marcel
Am 20.05.2020 22:46:49 schrieb Tim Johnson <digit at sonic.net>:
Hi Squeakers,

Been away for a while, but trying out 5.3 now.  Congratulations on another quality release.

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.

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?

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.

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).

Thanks,
Tim

* macOS 10.14, 64-bit, 2.9 GHz 6-core Intel Core i9

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200521/1490c14e/attachment.html>