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/04f57b82-45d5-46d2-979b-4cdbd6b854e1%40googlegroups.com.
