Trying out 5.3; typing is slow in Browser?
Locked
Trying out 5.3; typing is slow in Browser?
 
|
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 |
Re: Trying out 5.3; typing is slow in Browser?
|
|
On Wed, May 20, 2020 at 01:46:38PM -0700, Tim Johnson wrote:
> 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. > I have never noticed any slowness in this area. I tend to use very few add-on features when I configure the image. Just for purposes of narrowing down the issue, maybe you could try running a fresh image with no fancy preferenced enabled, just to see if the behavior changes. I use a Linux PC with various VMs and images, including the latest Squeak trunk, and I do not notice the symptoms that your are seeing. I hope your "little demo" went well :-) Dave > 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 > > > |
Re: Trying out 5.3; typing is slow in Browser?
|
In reply to this post by Tim Johnson-2
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
|
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |