Poor C2 Editor Performance On Larger Projects

— 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)

—, sadly, it looks like it is not a specific Windows 10 Update that causes it, but yet the original Windows 10. I have gotten user reports that Windows 10 stock has the same issue. I have not confirmed myself (honestly, it would take me a long time to setup a VM for this and it won't really help the bug report I don't think).

I believe it is fair to assume for now, the bug existed since the initial Release of Windows 10.

But you are right, in either case. The real question is why is it happening. And, is there a fix or workaround. If it is Windows 10, why is it windows 10? Is it how C2 draws things? Is there a fix for it? What changes are involved and how intensive. Is it a 10 minute fix, or 1,000 hour fix? All of this needs to be determined. It would be fully reasonable if the exact root cause was found and announced, and if it is a 1000 hour fix then simply say it is too large to fix and explain why (these types of details might help people build their own workarounds). It is what it is. Or, if it turns out to be a quick fix, yeehaaa everyone is happy. But in order for that to happen, the exact root cause needs to be determined (to the level of knowing exactly what needs to be fixed/changed/patched). Everything else is a mute point.

Also, thanks for the sample CAPX. Much appreciated I shall add it to the first post.

The reason I feel like I'm being trolled is because it seems obvious to me that the cause is in Windows, and there seems to be some insistence that actually it's our fault. So I'm going to drop my usual engineering equivocation and just say: this is categorically an issue in Windows. Does anyone disagree?

Im just happy it still works with that much crap added.

Hi folks,

Ashley, myself, and a few others had a very productive conversation on Discord. A lot of misunderstanding from all parties was cleared up and everyone who has been antsy like myself can rest assured knowing that Ashley has given with confidence he has spent a long time on this issue and has agreed we are far from a solution. It is entirely possible, this issue could go as-is for a long time. Sometimes, that is the nature of the beast especially with this type of issue.

We have agreed to put this to the side for a few days to allow for the air to clear a bit. And, if anyone has encountered tough issues before, sometimes simply setting an issue to the side and coming back to it later allows you to think more clearly about it.

If anyone finds any more data, or settings that mitigate the issue feel free to post them. But, for now, let's let the air clear before coming back to it.

I'm glad you guys had a talk and reached some sort of agreement.

Meanwhile I just want to demonstrate how bad Sprite Editor performance is on my Windows 10 machine.

It takes about 0.5s to draw toolbars, 2-4 seconds to open the little window with image points, and if I right-click on animation frame - 2-4 seconds to show the context menu. This happens even with very small sprites in small projects.

Youtube video

Rebooting Windows fixes this temporarily, restarting C2 doesn't.

I'm glad you guys had a talk and reached some sort of agreement.

Meanwhile I just want to demonstrate how bad Sprite Editor performance is on my Windows 10 machine.

It takes about 0.5s to draw toolbars, 2-4 seconds to open the little window with image points, and if I right-click on animation frame - 2-4 seconds to show the context menu. This happens even with very small sprites in small projects.

Youtube video

Rebooting Windows fixes this temporarily, restarting C2 doesn't.

dop2000 the video you have clearly shows a worser case of the issues. It is frustrating indeed. I have hit similar timings at times on my machine (where the outline of the context menu shows, and it takes a few seconds to load contents). If your machine is powerful enough to run a Windows 7 VM, that could be an option for C2 dev for now. Not a great solution I know, but it is the best I have at the moment.

A bit of a long read. But, here is some concrete evidence, anecdotal notes, and trial runs about the issue which show roughly 20 hours per project can easily be lost to this bug (so, if you did 5 projects a year, that is roughly 100 hours of your time lost forever due to this issue . . . that is 2 and a half working weeks). It is important to note, these test below are only for the issue of the edit action functionality being slow. It is possible it is related to the other slowdowns experienced, but I could not validate that as it is too time intensive.

TL;DR;: C2 does not run well on W10. Even a small object count (such as sprites) causes slowdowns. The slowdown is overtime as you add more objects, so you don't notice and get "used" to it. By the time you notice, it is too late for your project. Layouts, layers, and global variables do not seem to contribute any notable difference to the general slowdown reported. Several W10 settings/optimizations were attempted with no real difference.

Ran some test with a fresh install of Windows 10, still, need to run a few more to be complete. Essentially going under the assumption *if* the issue is Windows, then there must be a way to make it better. These tests were using the same project each time, same edit each time, fresh reboot each time, and no other applications notably running (one drive shut down, nothing else really has been installed).

Quick Summary: No Windows changes made any real difference so far. However, selecting not to cache icons (within) made the biggest noticeable difference (but not enough of a difference).

Conclusion of the test(s) in this post: No significant change in performance, still at unacceptable levels. (See summary of time lost below)

Overview of time results

When I was done with this batch of testing:

First load (first action change) Icon Full Cache (C2 setting): ~3s

Subsequent loads: ~1.6-1.7s

First load Icon Cache Off (lowest C2 setting): ~1.7s

Subsequent loads: ~1.5s

Note: By load, I mean editing an action. The time it takes from clicking the action, until the dialog pops open.

Quick estimation of time lost in W10 versus W7:

Assume 5,000 events.

Each event has on average 10 actions.

Just to create these 50,000 actions is (best case): 75,000s lost (1,250 minutes or 20.83 hours)

If you do smaller projects, estimate accordingly (500 events means ~2 hours lost).

This is a rough estimation and in my opinion best case scenario. In reality, it is much worse because more than just adding/editing actions are affected as seen in dop2000 video and others. This is also ignoring the slowdown overtime issue. It also ignores edits to actions (aka you wrote "perfect" code and ran into zero errors).

Test run so far:

Indexing completely shut off. No difference.

All background apps, telemetry, and so forth shut down. No difference.

Display settings set to best performance. No difference.

C2 in Compatability mode: No difference.

C2 with higher affinity/process power: No difference.

C2 with elevated priviledges: No difference.

Note: I did not test for extended use in these scenarios. This means, how C2 slows down while the computer is on longer. This type of test would be too intensive for all of the scenarios I am running.

Final thoughts

Once time allows, I have several other tests to run (such as caching size, paging, and some other test which I have run already but am now collecting concrete data on).

Side Note/Test

I wanted to see at what point did the project become fast again. I did a series of "reverse coding" or stripping down. Here is the results:

Deleted all global variables: No difference.

Deleted all sounds: No difference.

Deleted all but 1 layout and event sheets: No difference.

Deleted Sprites: This is where it got interesting. Deleting the first couple, took forever. You could see the Object Properties scan through every object (or so it seems). It took a couple seconds (5 seconds for the first batch) to delete each one (once less objects existed, it was near instant). It was not until I had a couple left did the editor become more responsive. By the time I deleted every object, the window pops after 0.2s (visibly, it is instant). A difference of ~1.5s. The dialog pops so fast, I cannot time it accurately.

This confirms what others have mentioned, about object count is the killer.

The project did not have that many objects to start with. Even at ~30 objects, the editor was terribly slow. (speed is directly correlated with number of objects/sprites as shown in this thread throughout numerous examples).

My question or thought as a result of this is , why would this slow down updating a variable in an action? What is C2 doing that is taking so long, if it is drawing icons as suggested in another post, something does not add up. Does C2 redraw the whole window, and all objects, when opening the edit action pane?

What I found from the above "tear down":

1) The editor for some reason goes through all objects below the object being deleted. I can visibly see the objects underneath being processed. If I have 10 objects, 1-10. If I deleted #1, I see 2-10 in the object info window. If I delete 9 I only see 10 get processed and it is incredibly faster than deleted #1. This means, if you had 100 objects, deleting object 1 will cause C2 to spin gears while you wait. This is not part of the bug (unless they are related, but I have no way of knowing), but an interesting finding.

2) More objects causes the project to go slower. Slow downs seem to be seen pretty easily. The slowdown is rapid and hard. When deleted the objects one by one, the editor got faster and faster.

3) Number of variables, does not seem to have any affect. Number of layouts either. Not in this test atleast.

4) Having Properties Bar, Project Bar, Layer Bar, Object bar enabled or disabled had no difference.

5) Having dozens of layouts + event sheets open versus just 1, made no difference.

6) Based on my tear down, if you hit this issue it is already too late. The object count is super low to start having issues, and its compounds in itself terribly. Re-use sprites as much as you can, but unfortunately, it seems even optimized projects with low object counts can hit this issue. I cannot think of a reasonable workaround at the moment, as any full-blown mobile app/game would reasonably go over this threshold of the object count. Since the issue is slowly rising, you get used to it and explains why so many people did not realize it was an issue until they compared between two projects, or compared W7 vs W10.

7) I tried moving objects into folders, this had no effect on action dialog time in the end. However, it did trigger the "slowdown overtime" issue. The dialogs took 4x as long to pop after moving a bunch of objects into folders. Upon a system restart, the times went back down. For example 1.5s load. Move a bunch of objects to folders. 5-6s load time for dialogs. Restart, back to 1.5s. This is unconfirmed if reproducible. If I have time I shall try this a few more times, it just takes forever to repeat since moving objects is crazy slow to do.

8) The issue is not resource bound. I tried this while mining on both CPU and GPU. Similar times were experienced (This was near constant 100% load on my CPU and GPU).

So, real questions here: even if the issue is 100% "Windows fault," does that matter? The software is made to run on Windows. It's also still for sale. Shouldn't it be Scirra's responsibility to fix the software that is supposed to run properly on the platform it's marketed as being designed for? Does the placement of blame matter? Doesn't the responsibility ultimately fall on Scirra, the software developers, and not Microsoft?

If a Windows update slows down some Windows code that C2 calls, the root cause is categorically with Windows itself. We might be able to work around it, and I'm looking in to it today. What is annoying though is when users blame us specifically for the problem, when all the evidence points to it not being our fault. It sucks enough that we're a small team left scrambling to cover up for Microsoft's mistake, and then having people blame us specifically for the issue and refusing to accept the possibility that it could be anyone else's fault (as if we're totally incompetent and all problems are obviously our fault)... that's just salt in the wound.

Basically I think this would be reasonable: "Hey Scirra, it looks like a recent Windows update slows down C2. This kind of sucks, do you think there's anything you could do to help?"

But this is unreasonable: "A recent Windows update slows down C2. OMFG C2 is so crap and is broken. WTF is wrong with Scirra. Why haven't they fixed it already? Do they even know what they're doing? Unbelievably poor service OMG!" (Maybe nobody used those exact words, but it's definitely the impression I get)

Thanks for the update Ashley, truly appreciate it.

I believe you are looking at this the wrong way in terms of passing blame, and ultimately is getting us nowhere. No one is trying to blame anyone here, we are simply trying to use the software and it is not working as expected. No one is calling you incompetent, or anything along those lines. You built a great tool for creating applications and games and not many people have the dedication, skill, or will to do that.

Sometimes, updates make older optimizations not work well. For example, a game that worked well on iOS 7, could be laggy as hell on iOS 10. The developer needs to update the game for iOS 10. It is not Apple or the developer's fault, at the end of the day the developer is the one who needs to do something about it.

Similarly, when going from C2 to C3, a project needs to be converted. Plugins need to be converted. And so forth. That is on the plugin developers and developers of the project. There is no blame, just the fact that work needs to get done for it to work properly.

There are numerous, and I mean countless pieces of software that had to do numerous patches and fixes for W10. That all fell on the software creators and not W10. Sure, there are some things that Microsoft broke, but they only came to light by software developers doing their due diligence in debugging their software to determine the root cause. Most software updates for W10, were in the same boat as you. No ones fault, simply changing times.

Now, if you connect the dots here. W7 updated to 8 then 10. C2 did not change for W10. It is not working properly on W10. That ultimately puts it in your hands. Again, no blame, but going back to the software cycle it ultimately falls on you to look at it (which you are currently doing).

Now, it is entirely possible you find some sort of Microsoft Library they broke and they never noticed. Then a bug can be filed with Microsoft, but only once that is determined (which, only you can determine). Simply saying W10 broke it, is not enough. Microsoft would say C2 needs to optimize itself.

Perhaps, there are workarounds you can find. Who knows.

I just want to be clear. At the end of the day, there is no blame. The blame game gets no one anywhere. It is simply who ultimately needs to look at it, and you are doing just that. You are looking at it, and that is all we can ask. We the users, cannot look into this issue beyond what we have done. We also cannot bring this issue to Microsoft with the little knowledge of C2 users have (we don't know the libraries, how the internals work, only you do). Putting all that together, we the users have our hands tied and you are the only one who can free us. That is a lot of responsibility on your plate, I get that. But if you look at it from our perspective, it might shed some light on the issue. It is beyond frustrating, to say the least, for these performance issues to be hit. The way you were responding previously, added to the frustration. Your new stance on it is much better and definitely cools the tide.

Not taking "sides" as I haven't read all comments, but I did try to open the test project and it was slow the first time to open. And fully understand that its annoying.

But im not really sure what was expected by people? Wont all programs at some point suffer. I could understand if the issue had to do with a structured well designed app, but this is just a lot of objects and events just for the sake of being many. Which is fine for testing, at least to some degree.

By that I mean I use both Photoshop and 3D applications and don't really see a huge difference between those and a huge project in C2. To explain it a bit better. If I make a ridiculous large image like 100000 x 100000 in Photoshop, it will take around 27.9 GB. it will take for ever to open if it doesn't crash Photoshop first. But that wouldn't make me instantly go to Adobe and complain that there software is slow or bugged. Same goes for 3D applications which can be crashed or force you to restart in less than 5 seconds if you simply crank up the number of subdivisions for an object.

What I mean by these examples is that all programs will suffer in performance if you push them to the limits or beyond. The test program have around 11000 events and lots of objects. C2 will have to load all of them and obviously it will take longer the more objects it have to load. It seems a bit like my example above with Photoshop, its easy to have a go at software if you are not reasonable, but it doesn't really make a valid point, I think. Because even if Scirra solves it for this project, what prevent someone else to make a similar post just with 5000 objects and make a similar complain?

But if C2 is supposed to do it and this project is seemed as a valid test project, then I guess its fair to raise the issue. Anyway as I said, Im not taking "side" just think its a weird test, as I have made many huge projects and never ran into this being an issue, unless it was my own fault for making a poor design in the first place, and this test project just seems like that to me.

— - you repeatedly said "C2 is broken on Windows 10" earlier in the thread, and now you say "No one is trying to blame anyone here". This is obviously contradictory. I've also seen you repeatedly edit previous posts in this thread, sometimes deleting a lot of content. I mean, this whole thing started with you pressuring us to fix it over the holidays treating it like an emergency even though we currently have other more serious issues. Frankly what I take away from that is your objective is mainly to troll over this issue and make everyone as upset as possible. This is a totally needless attitude; after this issue is resolved, I will be updating our bug report guidelines accordingly, so that no Scirra engineer is obliged to investigate an issue that users are being needlessly combative about.

Anyways, I'm looking in to the issue and I should have an experimental build out soon to trial a fix.

nimos100, the performance issue is hit with only a few objects. The sample capx's were to show the issue.

Some people are hitting 4-5s per dialog, with only a handful of objects.

When comparing to W7, the same project loads instantly.

That is the issue in the thread.

nimos100, the performance issue is hit with only a few objects. The sample capx's were to show the issue.

Some people are hitting 4-5s per dialog, with only a handful of objects.

When comparing to W7, the same project loads instantly.

That is the issue in the thread.

Ok fair enough, Im using Windows 7 so all good here

With only a handful of objects, I fully understand that it annoys people (And Scirra as well).