Slower graphics (Emscripten/Wasm) with v1.1.05

About Monkey 2 Forums Monkey 2 Programming Help Slower graphics (Emscripten/Wasm) with v1.1.05

This topic contains 7 replies, has 2 voices, and was last updated by  Pakz 1 year, 9 months ago.

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
    Posts
  • #8949

    Pakz
    Participant

    I wanted to switch to the new version of monkey so I copied my code over and compiled. The desktop version runs as it did but the emscripten and wasm now makes my game unplayable. There is a big slowdown with drawing now.

    Did anyone else encounter this yet and is there a method I could use to bypass/fix this?

    I tried to place counters to see where the slowdown is but I could not immediatly find the problem. I tried to count the millisecs it takes to flush the canvas and this was a huge number. But when I removed the flushes the speed did not improve at all. I then timed a drawing section of my code and compared it to the previous monkey2 version and there was a rather big difference.

    edit : I will try to spend more time investigating to pinpoint the problem.

    #8963

    Pakz
    Participant

    I was drawing to images(buffers) and I had used static images and tried to set them up as dynamic images but it made no difference. It takes about 2 seconds now to redraw everything while in the previous monkey version it was done in a fraction of a second.

    I am using a lot of drawrect and drawpoint and drawoval and drawcircle commands. Rnd and new color.

    edit: I did some side by side testing. In the method I tested now it seems that the graphics drawing speed has halved in the new version.

    edit: I will spend some time creating code that shows the speed difference between the two versions. Might take a while since I am having such a fun time working on my current project. (I am using the previous monkey2 version) I am not to sure if it is my coding that is the blame for the problem so I will wait to post a bug report (spamming it with my newb things)

    edit : here is the project with which I tested it. It is a lot of code though.

    https://github.com/Pakz001/Monkey2examples/blob/master/CivClone%200.6.monkey2

    When I used to press ‘b’ to build a city it was immediat, now it takes a second or two. Happens with the map redraw.

    #8965

    Mark Sibly
    Keymaster

    Just looking into this now…

    The actually canvas drawing code hasn’t changed, but the ‘render to texture’ system has so I’ll start there…

    #8967

    Pakz
    Participant

    I created a little test program just in case it is my bad programming.

    The speed difference is. WIth the previous version ( +/-80ms per redraw) and with the new version (+/-600ms)

    This is emscripten in debug mode in latest chrome browser.

    #8968

    Mark Sibly
    Keymaster

    Ok, I can reproduce now and it appears to be Chrome related.

    Can you try ‘firefox nightly’ instead? The above little demo actually goes a bit faster in V1.1.05 with nightly for me (and using WASM) – but I can confirm very slow performance with Chrome.

    Firefox nightly is my default browser of choice for dev work as it’s usually the first to support any fancy new fangled features and seems to offer the best performance with webgl, wasm etc. I should probably test more often with Chrome though, as it’s now the IE of the tenties…

    Will keep looking into this though – could just be something I’m doing slightly differently is ‘trigerring’ crap performance on Chrome.

    #8970

    Mark Sibly
    Keymaster

    Unrelated, but another thing I recommend is using ‘TextureFlags.Dynamic’ when creating textures that are being constantly rendered to, eg: if you’re rendering frames off screen, eg: image=New Image( w,h,TextureFlags.Dynamic ).

    This tells monkey2 not to bother ‘backing up’ the texture after you’ve modified it in case of a ‘lost device’ event, eg: Alt-Tab, display mode change etc. Backing up after modification is slow, and there’s no point backing it up if you’re just gonna redraw it again next frame.

    Wont affect the above little demo, but could affect Civ.

    #8971

    Mark Sibly
    Keymaster

    I think I may have found it!

    As far as I can tell, glGetError() is VERY slow on Chrome. Perhaps it’s doing an internal flush or something?

    Anyway, you can verify this by sticking a ‘Return’ at the top of the glCheck function in modules/mojo/graphics/glutil.monkey2 and rebuilding modules for emscripten etc.

    Plese let me know if this fixes it. This may be worth a 1.1.05b release as it’ll affect 3d stuff too…

    (…that’ll teach me to ‘code defensively’!)

    #8975

    Pakz
    Participant

    Yes, this fixed it! Thanks.. Both Emscripten and Wasm now are fast as the previous version. I wil now start using 1.1.05 for development.

    And I wil start using the dynamic flags if I draw on them reguraly.

Viewing 8 posts - 1 through 8 (of 8 total)

You must be logged in to reply to this topic.