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 On Monday, May 11, 2020 at 2:05:06 PM UTC-10, evdubs wrote: > > 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 > > On Friday, March 29, 2019 at 12:29:11 AM UTC-10, Bryan Lee wrote: >> >> 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? >> >> >> >> On Friday, 2 November 2018 10:46:29 UTC+8, evdubs wrote: >> > 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 >> > >> > >> > On Wednesday, February 21, 2018 at 10:50:58 PM UTC-10, evdubs wrote: >> > 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 >> > >> > On Wednesday, February 21, 2018 at 10:42:22 AM UTC-10, evdubs wrote: >> > 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 >> > >> > On Sunday, February 11, 2018 at 11:41:53 AM UTC-10, evdubs wrote: >> > 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 >> > >> > On Saturday, February 10, 2018 at 12:39:58 PM UTC-10, evdubs wrote: >> > 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 >> > >> > On Saturday, February 10, 2018 at 11:08:16 AM UTC-10, evdubs wrote: >> > 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 >> > >> > On Saturday, February 10, 2018 at 3:35:35 AM UTC-10, Robby Findler >> wrote: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) >> > >> > >> > >> > >> > >> > On Fri, Feb 9, 2018 at 11:05 PM, Evan Whitmer <[email protected]> >> wrote: >> > >> > > I forgot to mention that I have a 4K display, and I think that's >> important >> > >> > > to note here. >> > >> > > >> > >> > > >> > >> > > On Friday, February 9, 2018 at 7:00:18 PM UTC-10, Evan Whitmer wrote: >> > >> > >> >> > >> > >> 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 >> > >> > >> >> > >> > >> On Saturday, April 1, 2017 at 6:07:28 AM UTC-10, gneuner2 wrote: >> > >> > >>> >> > >> > >>> On Fri, 31 Mar 2017 13:34:38 -0700 (PDT), Dave Musicant >> > >> > >>> <[email protected]> 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 >> > >> > >>> >> > >> > > -- >> > >> > > 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 [email protected]. >> > >> > > For more options, visit https://groups.google.com/d/optout. >> > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/c369c5b0-9c78-4636-be07-1a36c4f35bdd%40googlegroups.com.
