Is it just me, or has Racket’s gui gotten more and more sluggish lately?

(At least on linux)

I am not on Linux - but I think a Linux related thing was fixed very recently. Are you using a snapshot?

@leif Was is your value of PLT_DISPLAY_BACKING_SCALE ? Set it to 1 or 2.

https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/racket-users/U3UhWBxJUQg/ogL1qIenAAAJ

@soegaard2 I don’t set it.

And it doesn’t look to be set in my environment

I am on a snapshot.

I’ll update and see if that helps.

@leif It seems I misremembered. The problem wasn’t fixed - just identified.

Aww…sad. :disappointed:

Its making drracket unusable for me. Sigh.

Thanks anyway.

I’ll look into fixing it.

Using 1 or 2 as the value of PLT_DISPLAY_BACKING_SCALE makes a difference.

1.25 or 1.5 turns out to be slow (at least on some machines)

There was a blog post that I saw a while ago about the reasons we switched away from using planet require forms to using raco pkg, but I can’t seem to find it. Can anyone point me to it?

@michaelmmacleod Maybe it was linked to in the discussion in this group yesterday?

Unfortunately it wasn’t :disappointed:.

Maybe this one? https://blog.racket-lang.org/2014/12/the-racket-package-system-and-planet.html

Yep, that’s it. Thanks!

@soegaard2 So I just checked out racket 7.5, and while its still pretty sluggish, its no where near as bad.

So while I think there’s more going on here, that certainly is a factor.

Thanks.

@leif Do you use Wayland?

Nope, I use x.

Reading a bit of code from the gtk layer. I noticed (define/override (make-backing-bitmap w h) (cond [(and (not is-transparentish?) (not wayland?) (eq? 'unix (system-type))) (make-object x11-bitmap% w h (send canvas get-client-gtk))] [(and (not is-transparentish?) (not wayland?) (eq? 'windows (system-type))) (make-object win32-bitmap% w h (widget-window (send canvas get-client-gtk)))] [else ;; Transparent canvas always use a Cairo bitmap: (make-object cairo-bitmap% (max 1 w) (max 1 h) (send canvas get-client-gtk))])) https://github.com/racket/gui/blob/55cc692234ae9eceac3e3a511dfc6559a40870e3/gui-lib/mred/private/wx/gtk/dc.rkt#L197

Also if you don’t set the PLT backing scale explicitly it uses a setting from Gnome: (define (get-interface-scale-factor display-num) (or (get-environment-variable-scale-factor) (get-gnome-interface-scale-factor) 1.0))

https://github.com/racket/gui/blob/55cc692234ae9eceac3e3a511dfc6559a40870e3/gui-lib/mred/private/wx/gtk/resolution.rkt#L9

Commits 70c318b2fd5c57d534fdb4b7f5fe3696523e6c2a and 55cc692234ae9eceac3e3a511dfc6559a40870e3 in racket/gui may be relevant. I hope not, but do you see anything different by reverting those (55cc before 70c3)?

@mflatt Reverting 55cc didn’t do anything, but reverting 70c3did.

So it might be the problem.

Ah, okay

In that case I have my scale set to 100% iirc.

Also, the date of that commit coincides around the time DrRacket started getting really painful to use.

(Which is to say a week or two later, when a next pulled.)

Would it be possible to just push reverts for those commits?

Yes, I think reverting is probably right. I’ll look one more time tomorrow.