Every now and then I think I should go back to using #GNOME because it would be simpler than my own weird mix of Mate and i3 and look a lot nicer, and then I try one of their apps… I just tried out their official Markdown editor and it starts running noticeably slowly (menus don't respond, the rendering preview gets locked up, etc.). This is on a very fast laptop and this is just a text editor. This matches my previous experiences running gnome years ago. Maybe I'll go with something else…
@gnomelibre yah, that's the one. It's not every gnome app, but I've had similar experiences with a lot of them (and with just using gnome itself. I don't know if it's a python thing (which I think is what Apostrophe is written in, IIRC), a GTK thing, or what, but if you have to have a recent computer to use a text editor we're really failing way more than I thought we were. Honestly, my computer isn't latest top of the line, but it's pretty good too.
@sam@gnomelibre Gimme a sample Markdown file and clear instructions on how to reproduce the issue and I will performance-profile it as a public service, if you can't.
@nekohayo@gnomelibre I don't really know what you'd need for this or how this works in the Python/GTK ecosystem, but thank you! That's really very kind of you and a great service!
@sam@gnomelibre I'm running 15-years-old hardware and I made the latest versions of GNOME Shell + apps fast on it over the past year of profiling and reporting.
You'll need to be MUCH more specific than your description above. Provide a way to instantly test your exact data and context (distro, software versions, packaging format, graphics driver, graphics server…). The basics of https://handbook.gnome.org/issues/reporting.html
No guarantees, as Sysprof doesn't do Python yet; manually profiling Python would be a pain
@nekohayo@gnomelibre I can provide os and package info (https://share.riseup.net/#7evaE8je0xyLw4tVqqDuRg) but I'm not sure about the rest of it; despite having been in this industry in the past, consider me a non-technical user for the purpose of this as this is all well outside my field. There's no specific steps to reproduce, just from the moment of opening it many things are randomly very laggy. Animations seem particularly bad, and this is not a particularly old or slow computer (i7 vPro 8th gen, 16 gigs ram).
@sam OK, so Intel GPU, not nVidia?… you're running on Xorg though, that'll slow you down a bit.
I see GTK 4.14.3 in your list of packages with Apostrophe 3.0. I'd bet the problem is that this version of GTK is running its new "NGL" renderer. It's the sole reason I haven't upgraded to Fedora 39 / GNOME 46, as I'm too scared of the glitches and perf regressions, with the amount of issues with that "gpu renderer" tag mentioned in https://gitlab.gnome.org/GNOME/gtk/-/issues/6411
@nekohayo thank you, that seems to have done it! Animations are still unbearably slow but something as simple as pressing the menu button doesn't seem to be freezing up anymore!
@sam Which animations where? And you are running Intel graphics (or at least open source AMD graphics), not nVidia, right?
Worst case scenario, you can disable most animations globally with GNOME Control Center's "Reduce Animations" accessibility setting, but animations "shouldn't" be slow if the graphics stack is in order.
@nekohayo like when you open and close panes and what not. Actually, I thought I had turned off animations, so I'm not sure if it's ignoring that setting because it's got a bunch of custom widges, if that only applied to gtk3, or if I just re-installed my system at some point and forgot to re-do that (or if I just made that up entirely). I should try to figure that out again.
I think it's intel, but I'm not sure? I didn't do anything special, so I'm assuming it's whatever the default is.
@sam Also use https://developer.gnome.org/documentation/tools/inspector.html to check the global properties of the app's graphics stack, and see if you see any mention of "LLVMpipe" in there. If so, that would mean the app/GTK is somehow running in software rendering mode, without any GPU assistance, everything on the CPU, and that's terribly slow. Also watch out if it's running Vulkan (instead of GL) on a GPU that is not actually Vulkan…
@sam I'm kind of out of ideas there, as it sounds like you're running non-broken Intel graphics, which is the best scenario… yet it seems like something is still wrong somewhere in Mesa/GTK, somewhere in middleware. It might fix itself with updates eventually.
Add comment