Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cursor movement through ToAlbum is sluggish #168

Open
Rinzwind opened this issue Jul 6, 2024 · 9 comments
Open

Cursor movement through ToAlbum is sluggish #168

Rinzwind opened this issue Jul 6, 2024 · 9 comments

Comments

@Rinzwind
Copy link
Contributor

Rinzwind commented Jul 6, 2024

Moving the cursor through a ToAlbum by just holding the right arrow key seems a bit slow compared to doing the same with a RubScrolledTextMorph:

Demo.ToAlbum.Cursor.Movement.1.mp4

I thought it was probably due to the ToAlbum being hosted in Morphic but it doesn’t seem faster when opened in a separate window:

Demo.ToAlbum.Cursor.Movement.2.mp4

Versions used: Toplo commit a55be92 in Pharo 12 build 1521.

@Rinzwind
Copy link
Contributor Author

Rinzwind commented Jul 6, 2024

For the RubScrolledTextMorph, the cursor speed depends on the “Key repeat rate” setting in the macOS System Settings. See the Apple support article “Set how quickly a key repeats on Mac”. I have it set to the highest rate. For ToAlbum, the cursor speed depends on a BlKeyboardProcessor’s value for ‘shortcutRepeatInterval’, which is only assigned to in the #initialize method with the value always being a Duration of 100 milliseconds. It would seem better if that also followed the system setting.

@plantec
Copy link
Collaborator

plantec commented Jul 8, 2024

thanks

@tinchodias
Copy link
Collaborator

For the record. I checked that SDL2 does take into account the key repeat setting in Mac with this script based on another from issue #567.

Steps to execute.
Execute in a terminal ./pharo Pharo.image st example.st --quit after saving next contents in "example.st":

| window renderer eventHandlerBlock renderBlock background event shouldQuit |

"-- initialize SDL2 --"

SDL2 initEverything.
Stdio stdout print: SDL2 version; lf.

"-- create and show window --"

window := SDL2
            createWindow: 'Press any key to change color; Click on close window button to quit.'
			x: 100 y: 100
			width: 400 height: 200
			flags: 0.
renderer := window createDefaultRenderer.
window show.


"-- prepare to loop --"

shouldQuit := false.
background := Color blue.

eventHandlerBlock := [ :anEvent |
    anEvent class = SDL_QuitEvent
        ifTrue: [ shouldQuit := true ].
    anEvent class = SDL_KeyDownEvent
        ifTrue: [ background := Color random ].
    (anEvent isKindOf: SDL_KeyboardEvent)
        ifTrue: [ Stdio stdout << anEvent asString; lf ] ].
renderBlock := [
    renderer
        drawColorR: background red * 255
            g: background green * 255
            b: background blue * 255
            a: 255;
        clear;
        present ].


"-- loop until quit --"

event := SDL_Event new.
[ shouldQuit ] whileFalse: [
    [ (SDL2 pollEvent: event) > 0 ] whileTrue: [
        eventHandlerBlock value: event mapped ].
        renderBlock value.
        5 milliSeconds wait ].

@tinchodias
Copy link
Collaborator

I wrote a benchmarks / automated profile around this topic. It's in BlocBenchs repo, executable by: BlKeysCursorMoveTextEditorProfileCase example. The simulation sends "key down", not "key right", however... Results:

Screenshot 2024-08-30 at 12 30 02

the 3 main columns are:

  • 45% rendering
  • 8% re-layout the elements (text)
  • 18% recalculating the text selection

It very simple to modify BlKeysCursorMoveTextEditorProfileCase>>#dispatchEvent to simulate "key right". The results were different: most much more time was spent in re-layouting and ~5% in text selection recalculation.

@Rinzwind
Copy link
Contributor Author

Thanks, I was wondering whether the command is not missing --headless but then I saw that question is already answered in Bloc issue #567 (I’m not sure where I can find the script and what else it does though).

@tinchodias
Copy link
Collaborator

@Rinzwind I'm sorry I missed initial steps I did to set up Pharo... In a terminal (Linux or Mac), create a directory, cd, and run: curl https://get.pharo.org/110+vm | bash. This downloads the vm, a fresh image, and two bash scripts: pharo (for headless) and pharo-ui for the "normal" IDE. After that download finished, one can run ./pharo Pharo.image eval 1+2. You will see a 3 printed in stdout, the result of the evaluation of the sum. pharo is a bash script that uses --headless argument... so you were right.

Also I wasn't clear on the script. What I mean is that the code in monospace format, copy it and paste in a text editor. Then save as example.st those contents, in the same directory as Pharo.image.

Finally, now you should be ready to execute ./pharo Pharo.image st example.st --quit. And you can edit the example.st file to play, if you want. If Pharo was downloaded in another way than the curl command, then yes, for example in Windows should be something like Pharo.exe --headless Pharo.image st example.st.

Hope it helps!

@tinchodias
Copy link
Collaborator

I didn't mention that the visualization in the screenshot is https://github.com/tinchodias/pharo-sauco-profiler, a visualization created with help of @akevalion in Roassal to show the results of Pharo profiler in another format, but you may prefer to read directly the output of Pharo profiler... it is available too in the inspector that the benchmark opens.

@tinchodias
Copy link
Collaborator

benchmark

@Rinzwind
Copy link
Contributor Author

Ah right! It hadn’t occurred to me it would be the script created through ZeroConf (I’ve used it on Linux but don’t use it on macOS).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants