I created PR 95 <https://github.com/racket/gui/pull/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 > <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.
