DrRacket Performance on Large Resolution Displays

[evdubs]

Hi,

I recently switched from Windows to Linux, and I have noticed that the performance of DrRacket seems to be worse on Linux where simple things like typing in characters can take a while (hundreds of milliseconds to seconds) to display. I have tried to do things that I didn't have to do on windows like disable background expansion, restrict memory, disable debugging support, etc. and nothing seemed to help. The only thing that seems to help is reducing the window size. By doing this, DrRacket becomes more responsive the smaller the window size. This seems strange to me as other Linux text editors and the Gnome terminal seem to handle the larger resolution just fine.

Are there pointers for bits of DrRacket code that might be sensitive to larger text areas that I can try to see if I can make faster?

[evdubs]

I think this is a performance problem within racket/gui. Using the following code from StackOverflow:

#lang racket

(require racket/gui)

(define frame (new frame% [label "Simple Edit"]
                          [width 800]
                          [height 800]))
(define canvas (new editor-canvas% [parent frame]))
(define text (new text%))
(send canvas set-editor text)
(send frame show #t)

(define delta (make-object style-delta% 'change-size 14))
(send delta set-face "Menlo")
(send text change-style delta)

It takes maybe a second to paint each character as I type when I maximize the window on my 4K display.

[JMendyk]

Hi,

I experience very same issue (both in case of DrRacket and provided script by @evdubs; I ran the script inside DrRacket and from terminal - issue exists in both cases) on my PC running Ubuntu 16.04 LTS with AMD cpu and NVIDIA gpu.

Is there anything that I can help with to resolve this issue?

[evdubs]

@JMendyk This issue is partially related to a fix made to racket/gui#95. The fix made to racket/gui doesn't completely resolve the issue, but it makes the latency a bit better to be somewhat usable. You can likely get by if you apply that simple change to /usr/share/racket/pkgs/gui-lib/mred/private/wx/gtk/window.rkt and run raco setup after. This change should hopefully make it into 6.13.

[evdubs]

@JMendyk Also, I opened a thread on racket-users where I attempt to go through my performance issues: https://groups.google.com/d/msg/racket-users/U3UhWBxJUQg/1YJNA2SZAAAJ. I think there is some flushing done that is not necessary, but I couldn't figure out a simple way to make it better. I have given up on trying to solve it for now, so feel free to dig in and add your analysis to that thread.

[JMendyk]

@evdubs Thanks for your answer. The change to window.rkt does seem to decrease the latency.

[tcstory]

is this problem solved?

[evdubs]

@tcstory not fully, no.

[evdubs]

Here's a message I left in the google groups thread:

However, I eventually stumbled upon the environment variable PLT_DISPLAY_BACKING_SCALE. By using an integer value for this variable, performance is nice and smooth (I tried 1 and 2; trying 1.25 and 1.5 hurt performance). In Ubuntu, I do not have my display set to a fractional scaling value, but I do have "Large Text" enabled. I am unsure if this setting interferes with whatever PLT_DISPLAY_BACKING_SCALE defaults to.

I am not sure why fractional scaling seems to cause performance issues, but there's at least a workaround. I don't know if the workaround is sufficient to close the issue.

Edit: this issue is better placed in the racket/gui project.

[jackfirth]

I think we should keep the issue open. At the very least, on linux DrRacket should log a warning somewhere if you set PLT_DISPLAY_BACKING_SCALE to a non-integer value.

[OmarShawky1]

This issue still remains in DrRacket V6.11 (via Debian Repo); tried to install the latest version from the website but the issue persisted.

[evdubs]

@OmarShawky1 does using PLT_DISPLAY_BACKING_SCALE=1 fix the performance issue for you?

[OmarShawky1]

@OmarShawky1 does using PLT_DISPLAY_BACKING_SCALE=1 fix the performance issue for you?

@evdubs
Hello, Very sorry for the very late reply.
I really do not know where to write such attribute. Furthermore, I tried using WINE to install the Windows version of DRRacket on my intel GPU and it worked much better even than the native but there was another bug in it; after sometime, the entire program stops responding and I have to close it and reopen again. If WINE can be used as an acceptable solution; I can send the winecfg to debug such issue. I also tried much more programs of course to try to solve it on my own like winetricks, playonlinux or crossover software but it failed even to launch the program.

I tried installing it via adding the PPA and the solution seemed to be somehow solved. it got faster but not totally eliminated.

I believe that the best solution would be actually to make a container for drracket so that it works on every machine the same without any unexpected bugs.

[sorawee]

I really do not know where to write such attribute.

Run the following command in terminal:

PLT_DISPLAY_BACKING_SCALE=1 drracket

[mflatt]

It's possible that the latest snapshot will behavior differently: https://www.cs.utah.edu/plt/snapshots/

On a machine that I set up with a large screen, I was able to speed up canvas refresh with a non-integer backing scale. Due to various layers of refresh and delays, it's difficult for me to tell the difference when just typing. But if I measure the refresh call with time, it went from 100ms to a fraction of a millisecond, so maybe this will make a significant difference for someone.