Destroying many objects appears to take several frames

[BenjaminDRichards]

While testing something involving many objects, I noticed that if I created a thousand sprites, they appeared at the same time - but when I set exists = false on them, they seemed to blink out over a very brief period of time. If I added visible = false, they disappeared immediately.

I'm not sure why this is happening, off the top of my head. I looked into the RequestAnimationFrame code, but a new RAF only seems to fire after the game loop is complete, during which time all existence should have been revoked neatly.

Investigate further.

[mukeshyadav-cdac]

Hi @BenjaminDRichards
I would like to Investigate this issue further if you could guide me in appropriate direction.
Since I am new your help will be appreciated very much.

[BenjaminDRichards]

Hi @mukeshyadav-cdac
If you want to investigate deeper into the KiwiJS engine, you'll need to know how to make debug builds.

First, I assume you're comfortable with developer tools in modern browsers - we use Chrome. These allow you to set breakpoints in code, so you can pause execution and examine code state. That can be useful. However, the KiwiJS library runs to tens of thousands of lines of code, so it might be awkward to set breakpoints manually.

I prefer to add debug logs. We use Kiwi.Log.log() over console.log(), because it's got memory and filters. If you do Kiwi.Log.log( "#debug", "Description of code location", interestingObject ), you can later revisit that log by typing Kiwi.Log.showAll( "#debug" ) into your console.

Two important caveats. Console logs can severely degrade performance, so use them sparingly and intelligently; and if you invoke code objects directly, as in interestingObject in my example above, it will be reported as its current state whenever you look at it. If you showAll() later on, the object may have changed. It is preferable to log out individual object properties, which should be immutable.

When I debug, I like to make a copy of the kiwi.js file and change it directly. I denote areas that I've altered with the comment // HACK, so I can find them easily. This makes it quick to test and try out code.

That's all that is necessary to get a solution.

When I've found a solution, I edit the actual source code in src/. (This is in Typescript, so you need to know something about Typescript conventions before making major changes.) Once the source code is changed, I build a new kiwi.js file using the grunt command, and test it again to make sure the build works. You will need to know about Grunt tasks.

You don't need to build the source to find a solution. Simply describing the source of the problem, and explaining a possible fix, should be enough for us to implement a source build ourselves.

Let us know what you find out!