Typing lag with DrRacket on Linux

[Dave Musicant]

Hey folks,

I'm using DrRacket on a 64-bit Ubuntu 16.04 system with the default Unity windowing system, and am finding that typing in the definitions window is laggy. The problem isn't a show-stopper, as it keeps up more or less as I type, but it's disorienting. I teach a class using DrRacket, and I had the experience today of coding in front of the class and the lag was just disorienting enough that I kept making typos I don't usually make. It's a psychological thing. That, and when I hold down a cursor key to quickly move through the program and then let go, the cursor keeps moving for a while from buffered keystrokes. If I give it a good burst of typing, I can sit back and watch the text fill in while I wait. I don't see this behavior in other programs (terminal windows, text editors, etc.)

I've tried both version 6.3 (in the Ubuntu repos) and 6.8 (downloaded from racket-lang.org).

I've have tried turning off incremental syntax checking and background expansion. No significant effect. What does matter is the size of the window. If I shrink the DrRacket window, typing lag goes away. So, I can solve the problem by making the window significantly smaller than I'd like, but of course, I'd prefer to run maximized. I'm running on a Lenovo Thinkpad t460s at native resolution, which is 1920x1080. I'm otherwise running at Ubuntu defaults on the display settings, as far as I know. I typically set menu/title-bar scaling to 1.25, but I've verified that the same behavior persists in DrRacket if I drop that scaling back down to 1.

Any thoughts on how this might be resolved?

Thanks, much appreciated.

--
Dave Musicant

[George Neuner]

On Fri, 31 Mar 2017 13:34:38 -0700 (PDT), Dave Musicant
<musi...@gmail.com> wrote:

>I'm using DrRacket on a 64-bit Ubuntu 16.04 system with the
>default Unity windowing system, and am finding that typing
>in the definitions window is laggy.

I've seen similar behavior on CentOS 6.5-6.8 under Gnome(2) - it has
persisted across a number of OS and Racket versions.

I have seen the lag in Dr Racket with 6.1, 6.5, 6.7 and 6.8. I
compiled 6.1 and 6.5 myself, so there might have been something
strange in those cases, but 6.7 and 6.8 were stock Linux x86_64
downloads.

Turning off background expansion helps somewhat, but I have found that
limiting memory seems to help the most. On Linux I run Dr Racket with
the limit set to 512MB. That might be too low for some people, but it
works fine for my typical (webserver app) uses.

George

[Evan Whitmer]

I, too, am having typing latency issues in DrRacket in the definitions window. As Dave noted, the size of the window seems to be related to the issue, and, in my experience, it's not just an issue with the Definitions window. Both the Interactions window and even the following code snippet (taken from StackOverflow) will have this same lag:

(define frame (new frame% [label "Simple Edit"]
                   [width 1800]
                   [height 1800]))
(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)

I am on Ubuntu 17.10 using Racket 6.11 with the proprietary nVidia drivers and X.org. My GTK version is 3. I don't have this issue with any of the other text editors that I've tried to use.

I tried to profile the above text editor, but I am a novice Racketeer and could not figure out a way to profile a thread managed in racket/gui. Does anyone perhaps know of a way to hook the above into a profiler to see what might be the cause of this lag?

Has anyone happened to stumble onto this issue recently and solved it?

Evan

[Evan Whitmer]

I forgot to mention that I have a 4K display, and I think that's important to note here.

[Robby Findler]

If you run this code, does the profiling information reveal anything
interesting?

#lang racket/gui
(require profile)
(define ec%
(class editor-canvas%
(define/override (on-paint)
(profile (super on-paint)))
(define/override (on-char e)
(profile (super on-char e)))
(super-new)))

(define frame (new frame% [label "Simple Edit"]
[width 1800]
[height 1800]))

(define canvas (new ec% [parent frame]))

(define text (new text%))
(send canvas set-editor text)
(send frame show #t)

> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[evdubs]

I had to add a sampler to that code so what I really had was this:

#lang racket/gui

(require profile)
(require profile/analyzer)
(require profile/render-text)
(require profile/sampler)

(define s (create-sampler (current-thread) 0.0))

(s 'get-snapshots)

(define ec%
  (class editor-canvas%
    (define/override (on-paint)

      (profile (super on-paint) #:threads #t #:order 'self))
    (define/override (on-char e)
      (profile (super on-char e) #:threads #t #:order 'self))

    (super-new)))
(define frame (new frame% [label "Simple Edit"]
                   [width 1800]
                   [height 1800]))

(define canvas (new ec% [parent frame]))
(define text (new text%))
(send canvas set-editor text)
(send frame show #t)

Then, I could use the following in the interactions window to get results after typing in some text to the text editor.

(render (analyze-samples (s 'get-snapshots)))

Here are my results for the rows that had significant values for "self"

================================================================================================================
                                    Caller
 Idx     Total          Self      Name+src                                                                Local%
         ms(pct)        ms(pct)     Callee
================================================================================================================
                                    call-with-break-parameterization [2]                                  100.0%
 [5]  19000(10.6%)    6221(3.5%)  dispatch-on-char method in window% ...ow.rkt:778:4
                                    ??? [45]                                                               29.3%
                                    flush-display [14]                                                     27.8%
                                    call-pre-on-char method in window% [15]                                10.2%
----------------------------------------------------------------------------------------------------------------
                                    call-with-break-parameterization [2]                                  100.0%
 [7]   2580(1.4%)     2580(1.4%)  ??? ...acket/collects/ffi/unsafe/atomic.rkt:115:16
----------------------------------------------------------------------------------------------------------------
                                    dispatch-on-event method in window% [9]                                 3.1%
                                    dispatch-on-char method in window% [5]                                 96.9%
[14]   5442(3.0%)     5442(3.0%)  flush-display ...d/private/wx/gtk/window.rkt:891:0
----------------------------------------------------------------------------------------------------------------
                                    ??? [13]                                                              100.0%
[22] 179456(100.0%) 158080(88.1%) loop .../drracket/drracket/private/rep.rkt:1456:17
                                    ??? [3]                                                                11.3%
                                    wait-now [32]                                                           0.0%
----------------------------------------------------------------------------------------------------------------
                                    ??? [70]                                                              100.0%
[75]   5512(3.1%)     5512(3.1%)  channel-put ...lects/racket/private/misc.rkt:169:2
----------------------------------------------------------------------------------------------------------------

The culprit, to me, looks like flush-display. Do you perhaps have any thoughts on the flush-display usage within window.rkt? I will try to poke at this a bit more.

Evan

[evdubs]

I made the following change to window.rkt's flush-display

(define (flush-display)
  (try-to-sync-refresh)
  ;; (gdk_window_process_all_updates)
  (gdk_display_flush (gdk_display_get_default)))

I made this change after finding the following note for the gdk_window_process_all_updates documentation

gdk_window_process_all_updates has been deprecated since version 3.22 and should not be used in newly-written code.

Things run much better now in DrRacket (and in the little editor example), but still the performance isn't great.

I would create a pull request with the removal of gdk_window_process_all_updates but I don't know if there are other Racket instances out there relying on older GTK versions that need this call. Is there a way to check for that?

Evan

[evdubs]

I created PR 95 to remove the call to gdk_window_process_all_updates. I am still unsure if there are legacy or compatibility reasons for having this call.

Evan

[evdubs]

I played around with is a bit more and noticed that setting editor-canvas%'s style to (list 'transparent) greatly increases the performance of the simple editor to where it performs just like any other text editor. However, I tried applying this to DrRacket in drracket/drracket/private/app.rkt and this did not seem to make much of a difference. Anyway, I think the key to improving performance here is still the removal of the call to gdk_window_process_all_updates. The "improved" editor looks like:

#lang racket

(require racket/gui)

(define frame (new frame% [label "Simple Edit"]
                   [width 1800]
                   [height 1800]))
(define canvas (new editor-canvas% [parent frame]

                      [style (list 'transparent)]))

(define text (new text%))
(send canvas set-editor text)
(send frame show #t)

Evan

[evdubs]

My apologies for the continued spam, but it feels like I am close to having buttery-smooth text editing in DrRacket on large resolution windows. I just need some help :)

When I set the interactions-canvas% and definitions-canvas% in unit.rkt to have the 'transparent style (after hacking the background handling to not throw an exception when 'transparent is set while backgrounds are being set), I can get smooth text entry in DrRacket until it starts getting really buggy due to my hack (like when inserting an end-parenthesis or when resizing the window). So, it seems like what is desired here is something like 'transparent in editor-canvas% that isn't forcing flushes or refreshes while respecting the background setting. It looks like canvas% provides 'no-autoclear, but editor-canvas% does not. I am not sure where to start to see if implementing that in editor-canvas% makes sense. Also, I tried to set lazy-refresh for the interactions-canvas% and definitions-canvas% but this does not seem to have the same performance impact as 'transparent.

Anyway, if someone still happens to be following along with this and has any ideas for what to do here, please let me know.

Evan

[evdubs]

Resurrecting an old thread.

I recently tried to see what would happen if I changed the interactions-canvas% and definitions-canvas% to be the following:

  (define interactions-canvas%
    (class editor-canvas%
      (init [style '(transparent)])
      (super-new (style (cons 'auto-hscroll style)))
      (inherit set-scroll-via-copy)
      (set-scroll-via-copy #t)))

  (define definitions-canvas%
    (class editor-canvas%
      (init [style '(transparent)])
      (super-new (style (cons 'auto-hscroll style)))
      (inherit set-scroll-via-copy)
      (set-scroll-via-copy #t)))

This seemed to work well for entering text into a blank file, but opening another file still showed the same lag. I was able to remove this last bit of lag by unchecking Edit / Preferences / Editing / General Editing / Color syntax interactively. I can now enter text into Dr Racket as smoothly as I can in most other text editors and even the example 'transparent editor-canvas% text editor. Background expansion can even be enabled without incurring a per-character-entered performance hit.

I do not know why setting 'transparent helps the performance of editor-canvas%. Likewise, I do not know why interactive syntax coloring also incurs a noticeable performance hit. As a reminder, this is mostly a problem for large resolution displays. Shrinking the DrRacket window will improve performance at the cost of not being able to see as much of the text.

If anyone has advice for why this might be so, or how to better profile this code to determine what can be improved, please share. I do not think my current modifications merit a PR to the DrRacket repository.

Evan

[Bryan Lee]

I’m facing the same issues, and I came across an interesting observation.

It seems that DrRacket mimics scrolling behaviour by literally replacing each line of code with the line above or below, and uses a really inefficient method of tracking which lines should go where, thereby limiting how fast you can “scroll”.

I realised that resizing the window horizontally does nothing to improve performance, but shrinking the window height significantly improved performance, even if the canvas area is adjusted to remain the same.

In addition to some function definitions in unit.rkt describing the transposing of lines, that leads me to my conclusion.

Thoughts?

[evdubs]

I think what I have seen previously with setting the canvas style to 'transparent ultimately is turning off antialiasing in Cairo.

Using the sample text editor from this thread, I ran the following:

$ cairo-trace racket text-editor.rkt

$ cairo-trace racket text-editor-transparent.rkt

In the non-transparent version, we see these two lines:

16 0 0 16 0 0 matrix 2 0 0 2 0 0 matrix << /antialias //ANTIALIAS_SUBPIXEL /subpixel-order //SUBPIXEL_ORDER_RGB /hint-style //HINT_STYLE_SLIGHT /hint-metrics //HINT_METRICS_ON >> scaled-font /sf0 exch def
f0 32 0 0 32 0 0 matrix 2 0 0 2 0 0 matrix << /antialias //ANTIALIAS_SUBPIXEL /subpixel-order //SUBPIXEL_ORDER_RGB /hint-style //HINT_STYLE_SLIGHT /hint-metrics //HINT_METRICS_ON >> scaled-font /sf1 exch def

These lines look like this in the transparent version:

16 0 0 16 0 0 matrix 2 0 0 2 0 0 matrix << /hint-metrics //HINT_METRICS_ON >> scaled-font /sf0 exch def
f0 32 0 0 32 0 0 matrix 2 0 0 2 0 0 matrix << /hint-metrics //HINT_METRICS_ON >> scaled-font /sf1 exch def

I am not really sure how this initialization is happening. Can someone help me poke through the code to see how I might disable antialiasing? Should I try to make changes to gui-lib/mred/private/wx/gtk/gcwin.rkt?

Evan

[evdubs]

I did some more digging and found locations in racket/draw that control antialiasing. I tried changing them around, and saw no impact on performance.

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.

If you're having typing lag issues on Linux within Dr Racket or other Racket GUI applications, you may want to try PLT_DISPLAY_BACKING_SCALE=1 to see if that affects performance.

Evan

[Jens Axel Søgaard]

Slack users confirm the problem when the backing scale is 1.5.

Should DrRacket give a warning dialog on Linux, when started with a non-integer backing scale?

/Jens Axel

To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/c369c5b0-9c78-4636-be07-1a36c4f35bdd%40googlegroups.com.

--

--
Jens Axel Søgaard

[evdubs]

I suppose that may be helpful, but this performance issue extends to any other Racket GUI application on Linux, including the simple editor example from earlier in this thread. Maybe printing something to a console could help, but it would be better if there was some fix to improve fractional scaling performance :)

Evan

To unsubscribe from this group and stop receiving emails from it, send an email to racket...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/c369c5b0-9c78-4636-be07-1a36c4f35bdd%40googlegroups.com.

[evdubs]

Resurrecting this old thread.

This issue should now be resolved with this commit: https://github.com/racket/gui/commit/20e589c091998b0121505e25c7ff2f95e8116dcb

No need to use PLT_DISPLAY_BACKING_SCALE with this fix.

Evan

[evdubs]

I can confirm that using a non-integer PLT_DISPLAY_BACKING_SCALE value for DrRacket 8.4 does not cause performance issues seen in earlier releases. Anyone coming to this thread with Linux DrRacket performance issues should make sure they are on version 8.4 or higher.

Evan