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 On Thursday, May 28, 2020 at 4:18:44 AM UTC-10 evdubs wrote: > 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 > > On Thursday, May 28, 2020 at 2:37:49 AM UTC-10, Jens Axel Søgaard wrote: > >> 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/de7d997e-7ec6-432a-8fe9-c6732688be9cn%40googlegroups.com.
