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 Den ons. 13. maj 2020 kl. 05.48 skrev evdubs <[email protected]>: > 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 > <https://groups.google.com/d/msgid/racket-users/c369c5b0-9c78-4636-be07-1a36c4f35bdd%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- -- Jens Axel Søgaard -- 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/CABefVgwsJVtGHg-5HH2fBCbHR7JZoG%2B8QZRcbbLRYBbBA6ckyw%40mail.gmail.com.
