(Links to screenshots) https://github.com/JetSetIlly/Gopher2600-Utils/blob/master/web2600/Doom_profile.png
https://github.com/JetSetIlly/Gopher2600-Utils/blob/master/web2600/Web2600_profile.png On Sunday, 5 September 2021 at 15:13:32 UTC+1 Stephen Illingworth wrote: > Thanks for that, it was interesting reading. The problem he was describing > in the Doom case seems to be have been caused by the WASM program taking up > all the CPU time, meaning the browser itself is unresponsive. I've solved > that by using a Web Worker. From what I understand requestAnimationFrame() > is a different solution to the same problem. Somebody correct me if I'm > wrong. > > What is interesting though is the profile differences between his Doom > port and my 2600 emulator. The top image is from the Doom port: > > > And this is from Web2600, over a similar time period: > > > We can see a lot more gaps in the second case than the first, which would > account for the performance drop I think. > > Does this bring me closer to a solution? > > On Sunday, 5 September 2021 at 13:28:44 > >> I had read an article that may be useful (format was different so may not >> be the same) --> https://github.com/diekmann/wasm-fizzbuzz (goes from >> basic WASM to Doom) >> >> The key thing in the Doom port that I recall was needed was to change the >> perspective of the owning thread (now the browser) so needed to ensure it >> was never blocked/ responded quickly. When you read through you may find >> your answer or something that gives you an idea to start searching through >> in your code. >> >> Hope it helps, David >> > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/6439a977-9f25-454a-bed1-c8d8cc1027ecn%40googlegroups.com.
