[+][BUG][PL] Level Select Menu: Crash after multiple clicks

[Flopsy]

So I was recording NeoLemmix 30 episodes today and I encountered crashes during one of my videos. The video is not live until mid September but I did record another video replicating what I did. It does seem to happen pretty randomly but when I click to open a tree of levels, the window might sometimes freeze and if I were to click again in this timeframe, I'll get the (not responding) on the window top line. Pressing X on the window then leads to the NeoLemmix is not responding window popping up.

This happens when I clicked the God Save The Queen pack in the embedded video, it's nothing to do with that pack, it's just a random thing that happens.

[WillLem]

The Level Select Menu going unresponsive is something I've been continually working to prevent ever since I started working on SuperLemmix. It's come a long way, but clearly could go further. I discovered the other day that the Search feature can still crash; I thought this was sorted, but it isn't.

This seems to happen most often with large level collections; measures have been taken to make larger collections more manageable, but there is still more to do.

Best guess: the message queue is being flooded with each click, and the UI doesn't have time to fully update before being given more clicks to resolve. I imagine that the best way to handle this is to find a way to actively ditch the existing queue whenever a new click is made. I'm not even sure if that's possible (or if it's standard programming practice), it's just what I'm guessing.

I'll investigate this again soon. Optimizing/improving the Level Select menu is one of my favourite things to do.

[WillLem]

Looking at the video again, this is a repeat of this bug in SuperLemmix. I never did figure out exactly what was causing it because it's impossible to test for. It happens randomly, and there are no definite steps that will cause it to happen. I can click many times in the Level Select menu and not duplicate the reported behaviour.

So, unless anyone has any debugging suggestions, this might be another one we just have to live with.

[Simon]

Flopsy filed this after a discussion that his level loading was slow. He said that some Lix levels took 5 seconds to load on cold disk cache, and similarly NL levels took a while to load. This can be mere coincidence, or it can point at a real connection.

Debugging idea: Introduce artificial delay in level loading or in tile loading. E.g., every tile loaded freshly from disk should make its loading thread sleep for 100 ms, or do some absurd extra file I/O like logging numbers from 1 through 10,000. Maybe the delay helps with reproducing this bug?

-- Simon

[WillLem]

Debugging idea

Thanks for the ideas

For now, I've guarded against re-entrancy for treeview and preview loading, both of which are relatively expensive tasks. They've already been fairly well optimized, but I realised that there's nothing actually preventing them from being called multiple times. Multiple quick-succession clicks would be a problem, then.

The re-entrancy guard should hopefully do it. Flopsy is testing now.

Caching is a very good idea, but... it would need to perform a cache every time it opens/closes to keep it up to date (potentially?).