Videos don't stop between layouts. And stacks memory.

0 favourites
  • 9 posts
From the Asset Store
Add SubRip (SRT) subtitles to your videos in Construct 3
  • Problem Description

    So I've had a hunch that it's my use of video that results in poor performance and lagspikes in Klang. I made this little stress test to see how the video object works across layouts, and it seems like a played video is a burden for the remaining of the play session. I easily got this empty project with one 5 sec video file to take 7gb of ram on firefox64 bit, and I crashed NW.js preview. The memory never seemed to get cleaned either. The video doesn't even stop playing between layouts, so if you press f1 and f2 continiously it feels like 20 videos playing on top of each other. THIS IS BAD!!!

    One important difference to notice here though. In FIrefox the video stops playing every time I change the layout. This explains why I don't really have this bizarre frame skips and slow downs when I play the game in Firefox. In NWjs though the video champs on to the next layout, and even stacks with a new video instance if I go back.

    Considering how my game runs on NWjs, and uses lots of video, I can only point fingers to this and blame this. It just makes too much sense considering all the performance drop patterns I've seen in game

    Chrome manages to clean itself faster than I can raise the memory level. The video also stops. This is a NWjs issue.

    Attach a Capx

    https://drive.google.com/file/d/0B1n4Fd ... sp=sharing

    Description of Capx

    Play it in NW.js

    Steps to Reproduce Bug

    • run the game in preview and open the task manager
    • press f1 and f2 continiously
    • watch the mayhem, and keep doing it till the browser crashes.

    Observed Result

    Memory use through the roof, videos don't stop between layouts on NWjs. I get a feeling they never stop being a burden to the playsession

    Expected Result

    I'm expecting the video to stop when changing the layout, and restart with only 1 instance when I return to layout1.

    Affected Browsers

    • Chrome: (NO)
    • FireFox: (YES)
    • NWjs: (YES!!!)

    Windows 7 service pack 1

    Construct 2 Version ID

    233 (newest as of 10.08.2016

  • Memory went up.

    Then it went down when I stopped.

    It's not unexpected.

    It takes a bit for the memory to be released.

    Might check what version you are using:

    https://www.scirra.com/nwjs

    I was using the one from July 21

    Although I have no idea if preview actually uses the newest c2nwjs install.

  • newt Doesn't happen for me no... Also just the fact that memory stacks is proof how it's madly unoptimized the videos are. Also doesn't change the fact that a new instance of the video starts playing, proving that the videos don't stop existing once you change layouts. Destroying the video doesn't work either. Very bad...

  • It's been stated quite a bit that browser garbage collection is pretty bad, but I don't think any framework is going plan on this sort of use.

    A video gets loaded, it's expected to be viewed, giving the system time to adjust.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • i CAN'T see any "videos" mp4, i export my app in EXE for window and the video player is not visible, video doesn't PLAY at all!!!

  • i CAN'T see any "videos" mp4, i export my app in EXE for window and the video player is not visible, video doesn't PLAY at all!!!

    imothep85

    Please stop hijacking other users threads. Your issue is not the same as the OP.

    If you think you have an actual bug then please post your own bug report, ensuring you follow all of the requirements.

  • Huh, this is interesting - I could actually reproduce a leak in Chrome by pressing F1 and F2 pretty quickly. I got it up to 1 GB at one point. The video plugin is destroyed when you change layout, and it does run cleanup code, which includes pausing the video if playing (there's no "stop" in JS), and throwing away the video (just dropping the reference, there's no "destroy" or "cleanup" command in JS for video). However this does not seem to be enough to have it released from memory. I found one tiny tweak which seems to fix it though: now when the video is cleaned up we reset the video src to empty, so it drops the reference to the video file. This appears to properly clean it up and prevents Chrome heaping up memory. It seems to work OK in NW.js as well.

    Here's the tweaked video plugin runtime.js if you want to test it yourself: https://dl.dropboxusercontent.com/u/15217362/video_runtime.zip

    (Extract over exporters\html5\plugins\video\runtime.js and restart C2)

    I think this is a workaround to what is basically a browser memory leak. If it works, this could save a lot of memory!

  • A little hard to verify wether it works, since I actually manually changed sources on every video instance in the game prior to this (which seems to have helped). The new runtime hasn't hurt stability yet though, so I'll keep working with it.

  • I'll close this report since my numbers indicate it resolves the memory buildup, and the change is in the next build as well, so I guess file a new issue if you still have trouble.

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