I made the following change to window.rkt <https://github.com/racket/gui/blob/master/gui-lib/mred/private/wx/gtk/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 <https://developer.gnome.org/gdk3/stable/gdk3-Windows.html#gdk-window-process-all-updates> 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]. For more options, visit https://groups.google.com/d/optout.
