Re: [racket-users] Re: Typing lag with DrRacket on Linux

[evdubs]

I can confirm that using a non-integer PLT_DISPLAY_BACKING_SCALE value for 
DrRacket 8.4 does not cause performance issues seen in earlier releases. 
Anyone coming to this thread with Linux DrRacket performance issues should 
make sure they are on version 8.4 or higher.

Evan

On Thursday, October 28, 2021 at 9:32:10 AM UTC-10 evdubs wrote:

> 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 :
>>>
>> 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 

Re: [racket-users] Re: Typing lag with DrRacket on Linux

[evdubs]

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 :
>>
> 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))) 
> > 
> > 

Re: [racket-users] Re: Typing lag with DrRacket on Linux

[evdubs]

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  >:
>
>> 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 

Re: [racket-users] Re: Typing lag with DrRacket on Linux

[Jens Axel Søgaard]

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 :

> 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 

Re: [racket-users] Re: Typing lag with DrRacket on Linux

[evdubs]

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 

Re: [racket-users] Re: Typing lag with DrRacket on Linux

[evdubs]

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 

Re: [racket-users] Re: Typing lag with DrRacket on Linux

[Bryan Lee]

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 

Re: [racket-users] Re: Typing lag with DrRacket on Linux

[evdubs]

*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 
> 

Re: [racket-users] Re: Typing lag with DrRacket on Linux

[evdubs]

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
 

Re: [racket-users] Re: Typing lag with DrRacket on Linux

[evdubs]

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 

Re: [racket-users] Re: Typing lag with DrRacket on Linux

[evdubs]

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]

Re: [racket-users] Re: Typing lag with DrRacket on Linux

[evdubs]

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 

Re: [racket-users] Re: Typing lag with DrRacket on Linux

[evdubs]

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  > 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 

Re: [racket-users] Re: Typing lag with DrRacket on Linux

[Robby Findler]

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  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
>>>  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 racket-users+unsubscr...@googlegroups.com.
> 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 racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Re: Typing lag with DrRacket on Linux

[Evan Whitmer]

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 
>>  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 racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Re: Typing lag with DrRacket on Linux

[Evan Whitmer]

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 
>  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 racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Re: Typing lag with DrRacket on Linux

[George Neuner]

On Fri, 31 Mar 2017 13:34:38 -0700 (PDT), Dave Musicant
 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 racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.