UI slowdown over time

Hi team
I have a strange problem that I’m struggling to diagnose.

I have a helper app with a small UI that shows as a small window unless I mouse over it. When you do it shows more information and quite a few more controls. The app does quite a lot in the background from sending Socket comms to shell commands etc.

The issue I have is that the app behaves really well for the first hour or two but then starts to slow down the UI updates over time. If left on overnight when mousing over the window, the controls show as white and can take 10-15 seconds to update and show correctly.
Memory usage and cpu usage are both staying low so I don’t suspect a memory leak and I’m not appending text to text boxes etc.

Any suggestions on how to track down the slowdown?

Running on windows using any compiler over the past few years.

you could output data from runtime

i remember some mouse events are fired very often and not just once as you may be expected.

follow your app flow with system.debuglog(currentmethodname)

Thanks Markus.

I’m seeing this even when I haven’t moused over so presumable the mouse events haven’t fired. Just something really slowing th UI after a number of hours.

have you used threads or wait loops?

Not in this application.

How are you showing/hiding the extra controls? I wonder if they’re not being properly destroyed.

More generally speaking I would look into memory leaks to start.


Hi Eric

I’m actually just resizing the window so the controls are not visible if I’m minimized mode. Is this bad?

This looks amazing!
Should I see more memory being consumed if I had a leak though?

You take “snapshots” of the runtime structures, over time, and then compare them. You will see differences, including some objects increasing their sizes.

So I’ve just completed a test after a couple of hours and I see no change in the number of objects unfortunately.
I see a significant ui redraw slowdown though. It’s a really great tool though! Any other suggestions?

I guess you are piling a lot of things busy (even in a shell) over time in an one thread only app, and it maybe should the normal behavior for your use case and Xojo architecture.

Thanks Rick,

I’d love to understand how I can make this better though. I’m not doing anything crazy and I’m certainly trying to clean up anything I create.

if it is slow have you looked in ms ressource monitor?
this behaviour is only in your app?
is there a issue with energy saving? lost network or something?

Resource monitor looks ok. If I restart the program all is well. Nothing else is affected, just my app.
I’ve seen this before if I appended text to an editfield but I’m not doing this in this instance.

Do you have an antivirus; could it be flagging the app after monitoring all the socket calls? Can you add your helper app to the A/V “whitelist” (just to test)? Keeping with the subject of graphics redrawing; do you see indication the GPU is clocking more utilization and/or memory over time?

No AV running.

GPU doesn’t show much change, but we are running a pretty intensive graphics program in the back end. Doesn’t really explain why restarting the app fixes the issue though.

Here is a link to the video showing my UI update:


Unfortunately, UI performance dropped significantly when Xojo switched from GDI+ to Direct2D.
Have you checked that the Transparent / DoubleBuffer properties are switched off for as many controls as possible as that can help?
I also heard that there are tweaks to the rendering code when using API 2 controls so you could try hacking your project to use the new controls.

Otherwise I think you will need to provide your project to Xojo for investigation.

Thanks Kevin

I’ll try to strip out hardware dependency and get a project together. Will also confirm transparency/double buffer. I guess I just find it strange that the problem only manifests after a couple of hours. CPU usage peaks at about 11% and memory at a couple of hundred MB on an I7 machine so not bandwidth constrained.