About a year ago I remember having an issue with my downloads folder on Win10. It had about 5000 images and opening the folder would be slow and subsequently scrolling the folder would have an occasional freeze too.

Now that problem is gone. I can open a folder with 50.000 images instantly and scroll it without any kind of hiccups. The icons are lazy loading on the visible area while scrolling the folder. What if some of the icon loading has been changed and now the API C2 uses is actually meant for lazy and not eager loading of the icons?

Also there's this: https://answers.microsoft.com/en-us/win ... a12?auth=1

dop2000 can you see if you experience odd behavior with the icon cache? The performance degradation over time may be related to this.

This may be worth a shot too: http://www.thewindowsclub.com/increase- ... in-windows

— has been helpful so far by providing workarounds, maintaining the thread and collecting data from people to find out what this is about.

I believe there's some level of misunderstanding which is causing some to get riled up. Nuance is hard for some to read, so please don't assume there's "blame" or "trolling" or any kind of ill will when someone's actions show they're doing their best to HELP.

People already pointed at win10 updates being a probable root cause way early on the thread, so I don't get why there's so persistent bickering about it. A change in Windows is the probable cause, get over it, it's still a problem that exists. It sucks for scirra as much as it sucks for us users.

So to keep the wagon moving:

While workarounds have decreased the issue somewhat for me, it's not completely gone.

Ashley reported 1 second to open the dialog, which means he can reproduce the problem.

To make it easier to debug, I have reduced an earlier example to a state that has the minimal amount of excess, while still showing the problem.

This capx only has a 1000 objects and some families, nothing else, while also consistently showing 1 second to open when clicking "add event"

https://www.dropbox.com/s/cm0dildivgcf6 ... .capx?dl=0

I've spent years dedicated to a project that is now suffering due to this, and I'm not the only one. (count on first post shows 14 users)

Beautiful. So it has been faster before, so Windows did something that makes what you use unusable.

The earth moves, so do you.

There are options to make it work fast again. A change to how the icons are loaded may be needed. A different way of showing them, or alternatively having them populate the dialog on the fly like so:

1. action popup opens with a text or other light way of showing objects that haven't loaded their icons yet.

2. icons load la-la, you can can still use the search and select an object you wanna use. Most of the time your typing what you need will take a second.

Like while implementing stuff fast, you know what object you need to select and what action to add, so you really don't need to see all of the objects at once anyway.

Alternatives: The thing that "add action" button does, can it be preloaded so that it doesn't need to do "the thing that is slow" every time you add an action?

--edit

What if from a certain point onwards, the icon cache on windows 10 is not big enough to accomodate all of the icons in your project, thus they need to be reloaded each time you click "add action"

Now a windows update might've decreased the size of the cache or done something that increases the footprint of the C2 icons.

Ashley

I assume you can still have a profiler on the dev version of C2 running while observing the 1 second opening on your end? That can give some hints? Catch the call that takes a lot of time. There might be something small that causes a hickup on newest version of windows, possible even a security vulnerability thing. Looking won't hurt at least. Comparing it to Windows 8 can help too.

For my project, it's definitely the object count that causes the problem once it triggers. I deleted everything except objects when I had the project running slow. Strangest thing is tho, right at this moment it's working just fine.

— if you make an extreme test case, I'll test that too to see if it can be reproduced reliably.

Oh and I have Win10 too, latest updates. Setup is otherwise fast enough to run new games good.

It's a chromium bug, there's an open report. This mentions multi monitor trouble: https://bugs.chromium.org/p/chromium/is ... ?id=467617

If you have two monitors with different hz, vsyncing is going apeshit.

I think it uses the frequency of the "main monitor" to vsync even if the project is playing on another monitor with different frequency.

Does changing the icon caching option in preferences affect this?

ATM the C2 editor is taking 1-1.5 seconds to open a dialog. "Don't show unique icons" setting doesn't seem to have an impact currently. I will try again if the editor becomes extremely unresponsive, like 3-5 seconds territory.

Haven't been able to pinpoint what exactly triggers the unresponsiveness.

That's probably coincidental. I get slightly different response time by resetting the computer normally. Sometimes better, sometimes worse.

I'm wondering if it would be possible to flag some objects to not be shown in the project. It's not a super good solution, but with that I could work normally. My project has plenty of objects that are done and final and never need to be touched again, so those might as well be hidden.

Can confirm. If I clear my project of anything but the objects, it can still behave slow. 3-5 seconds to open a dialog the first time, then 2-3 seconds the times after that. It's not super consistent. Sometimes it works faster than others, sometimes so slow the project is unusable. At best it's been just 1 second to open a dialog.

Having another empty project open at the same time and that one will work nice and fast, even if it's open on the same instance of C2 in a tab, so it might not be about some total resources limit?

Things I've tried so far.

Capx vs Project folder - no difference

HDD vs SDD - no difference

Disabling object icons - no difference

I'll try to keep my eye on what might make it go into lag-land and report back.

It's only really a minor issue. Most games are not affected by it. It causes maybe something like +/- 2px difference.

It's a meaningful difference for many pixel art games . Also due to it's sneakiness it can go unnoticed when people simply miss jumps without knowing it was an engine inaccuracy that caused it, causing the game to "feel bad"

Inaccuracies like this have forced me to do an extensive extra rig for the player to ensure jump consistency.

You can get around it case by case, like for height accuracy you can record your ground Y position on jump, then if your jump peak falls short of your projected max jump height and the jump button is still held down, you move the player to your max height position based on the initial jump Y position.

There's more to it, but for each game a few special case helpers should at least alleviate the issue, if not remove it completely.

In the end, jumping games often have a lot of smoke and mirrors going on anyway to improve game feel, like snapping, late jumping, placing the player on a platform they should've missed, conditional control overrides that try to guess the player intent and so on.

Having the default behavior as accurate as possible will improve game feel for C2/C3 games in general even if they have minimal "helpers" implemented.

You could try and increase GPU use on purpose by adding a ton of more additive layers and see if that makes the problem worse.

If it doesn't then you'll know if the GPU is bottlenecking.

I've found problems with the OR block too, but I think the previously picking event wasn't a "pick by comparison" but something else. I might have that block commented out in my events somewhere. Will report back if I find it.

Initially I thought I didn't understand the picking process correctly, but then figured the OR block was not reliable, so have been avoiding using it in a sub-event.