Poor event sheet editor performance

0 favourites
From the Asset Store
Bring the Wild West to life with this Cowgirl Sprite Sheet!.
  • Ashley

    (Disclaimer: Specs are i5-6600k, GTX 1080ti, 16gb RAM. GPU setting in C3 on high performance. Dark theme.)

    I find that in my larger event sheets, C3 has a hard time keeping up. There's a distinct delay to every action - Highlighting or rearranging events, opening the action or condition window, clicking OK or cancel on any expression window, etc. all takes up to 0.5 seconds per. Said event sheets aren't even that big (300-800 events).

    I'm posting to see if others have this issue, if I need to report a bug, or if the event sheet editor just needs some optimizing and if there are plans to do so.

    Technically I could break down the event sheets into smaller ones and use a bunch of includes, but I shouldn't have to. I prefer the setup I have here and used with no issues in C2.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • Might be this issue: github.com/Scirra/Construct-3-bugs/issues/445

    Try switching to the default theme, might improve things.

  • I also reported this problem a long time ago, even providing a performance recording, which was dismissed.

    https://github.com/Scirra/Construct-3-bugs/issues/611

    When i get to around 1000 events the editor is very laggy. The only solution i've found is to use groups and close them when there not being edited.

  • This is a very old problem, and isn't a bug as it's how much can Construct keep in 1 event_sheet, and your pc reading all that (having a SSD assigned to Construct caching and processing might help a bit).

    Cheap solution to this problem i found a long time ago, since i started using Construct 2, don't keep all events in 1 event sheet, also don't have more than 10-12 actions in 1 condition(you can add blank sub_conditions instead of keeping all actions in the main condition - for some reason, it kinda clears the heaviness)

    if you have different events and conditions for different characters hud etc splice them up into other event_sheets and use include, separate all events into other event_sheets where you can, and use the include.

    reuse code either by using functions or families, so you don't have to repeat the same code by copy pasting it and fire it 100 times from 10 different conditions when can actually be done once and run for all the objects that apply to that code.

    having groups only lowers the usage when u close them, but is not gonna solve the issue, if u start searching for a line of code as an example ... it will unlock everything basically and crash Construct.

    this is kinda the same issue as with any software, if you overload the screen or event sheet in screen it will eventually crash, you can see wordpress and unity even, and other platforms have the same issue, they can handle the stuff, but to a surtain limit, you have to organize.

    when i started with Construct i was creating like 2 conditions and each condition would had like 20 30 actions, and wondering what is going on... because the game was relatively small... but u gotta remember, that each action has to check if condition is ok, the more u add the more u check that condition, and the system has to do all that in a tick, cause under it there are 300 more lines....

  • but u gotta remember, that each action has to check if condition is ok, the more u add the more u check that condition, and the system has to do all that in a tick, cause under it there are 300 more lines....

    I disagree that its about construct having to read and check the events, i've never experienced any editor performance issues with C2 on the same computer and had thousands of events. This is a browser issue.

  • > but u gotta remember, that each action has to check if condition is ok, the more u add the more u check that condition, and the system has to do all that in a tick, cause under it there are 300 more lines....

    I disagree that its about construct having to read and check the events, i've never experienced any editor performance issues with C2 on the same computer and had thousands of events. This is a browser issue.

    if you want to see a heaviness C2 event usage, il send u my store item, drawing template( i done that one early when i started with C2). has about 500 events only, shouldn't matter if i messed up the code or looped it once or twice right? the moment u click stuff waits 1 second to process. i do admit i kinda messed up code overcomplicating things, but all the code is in 1 event, each condition has probably 15/20 actions.

  • You may be right, but i would consider 15-20 actions per event line an extreme case. I can create 1000 blank events in C3 and get lag in the editor.

  • You may be right, but i would consider 15-20 actions per event line an extreme case. I can create 1000 blank events in C3 and get lag in the editor.

    if you do blanks, wouldn't do nothing if you don't add actions to them, shouldn't as there is nothing to check upon.

    but i see this as a issue if you want to develop a bigger game, that has like 10-20,000 events right... now even if you splice them up in event_sheets, at some point you will have so many includes that would probably be unusable... i wonder how Penelope was made and avoided this issue, and other games released that were bigger than our normal single player game with 10 levels.

    Edited: i read the bug report,it's the theme or the way theme of the construct is being applied that is doing it,...even though shouldn't it be just a CSS stylesheet of sorts since is browser based?

  • Yeah you are right about that, but as a test having 1000 blank events that should be doing nothing therefore in my mind points the problem more towards some kind of browser layout/ui rendering issue (i don't know anything about browser tech so i'm just guessing). The fact also that changing themes effects performance also seems to support this idea.

  • Yeah you are right about that, but as a test having 1000 blank events that should be doing nothing therefore in my mind points the problem more towards some kind of browser layout/ui rendering issue (i don't know anything about browser tech so i'm just guessing). The fact also that changing themes effects performance also seems to support this idea.

    Agree there, i wonder if Construct 2/3 is using webgl in order to boost performance of the editor... i know Chrome has this webgl boost stuff(active by default and a webgl test mode... extra on top of that) and might cause crashes for like random bullshitery, as webgl seems from my usage so far it's not really stable, on browsers atleast. I've also experienced a lot of webgl crashes on C3 editor, when i was doing some projects that were rather heavy on the code + images.

  • just FYI. I have about 7 sheets in my current project included in main.

    Two of those sheets are running at around 500 events each with no discernible lag (well nothing that has made me notice anything anyway)

    this is on surface pro 4 I5 with integrated gfx and 8gb ram.

    maybe some browser plug in or other open app eating resources? (things like facebook and active one note sync are resource killers) or maybe hard drive full / failing?

    also

    I think I did notice a small improvement in snappiness and feel by deleting the chrome IndexedDB storage data which had maxed out at 16GB! maybe try that.

    construct.net/en/forum/construct-3/general-discussion-7/16gb-for-indexeddb-in-chrome-u-141219

  • Just to follow.

    I just combined a few sheets into one to get an event sheet with over 1300 real events some with many actions.

    This is not on the surface pro but on a work laptop I7 with quaddro gfx (similar to maybe 1060 with 5GB gfx ram) and 8GB system ram.

    No discernible lag on any operations.

    Will try the pro tonight.

  • This might be related to this bug: construct.net/en/forum/construct-2/closed-bugs-22/poor-c2-editor-performance-on-131074/page-4

    That project loads slowly in construct 2, but it may load slowly in construct 3 as well.

  • Well, I'm at least glad to hear I'm not the only one experiencing this.

    My project was ported from C2. The exact same event sheets had absolutely no lag in C2. C3 & my project are operating on an SSD.

    Browser-based editors FTW, yeah? Ugh. I assumed it was something to do with this and haven't been proven wrong yet. For the record, disabling the dark theme does help a bit, but there's still some lag on my largest event sheet. I'm not about to disable that, my poor eyes need it.

    NetOne Only chrome extensions I have are dark reader and Adblock. I'm running the desktop version anyway so these should be completely disabled.

    Side note...the layout editor is super responsive and I've got some preeeetty massive areas in there. Perhaps we can have the GPU help out with the event sheet editor too? lol

  • Worth noting my CPU shoots up to ~35% just from expanding and collapsing events and scrolling around. I think some optimization is in order here...

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)