I was hoping it was the rendering code that was the problem but I'm almost 100% certain that it isn't. If I just allow the emulation to run without drawing anything to the HTML canvas (and just writing a frame count to the console) the performance is still the same.
Good tip about Ebiten though. I don't think it'll help with my immediate problem but it shouldn't be too difficult to add it as an alternative presentation method. The main reason I opted for SDL was because I was familiar with it. Ebiten might be a good alternative. On Saturday, 4 September 2021 at 11:34:08 UTC+1 arn...@gmail.com wrote: > Hi Stephen, > > I haven't really looked at your code in detail but one obvious > difference between your version and the original is the rendering > code. Are you certain that the slowness is not confined to your > rendering code (I have no reason to believe it is btw)? > > Here is a suggestion. I have had a good experience using a 2d library > called ebiten (https://github.com/hajimehoshi/ebiten). It abstracts > the rendering and can target native or browsers via wasm. In my > experience performance when targeting the browser has been acceptable, > so you could write an implementation of television.PixelRenderer > backed by ebiten. You could then compile both to native and wasm and > see if there is still a big performance difference? > > HTH > > Arnaud > > On Sat, 4 Sept 2021 at 11:12, Stephen Illingworth > <stephen.i...@gmail.com> wrote: > > > > I don't think I'm going to be able to make any progress with this. I > chopped away enough code so that it compiles with TinyGo. It works but it's > even slower. > > > > I was hoping to find a way of profiling the WASM code but I see DWARF > support for WASM binaries is still a work in progress. > https://github.com/golang/go/issues/33503 I don't know enough about WASM > to be able to contribute to that issue unfortunately. > > > > Thanks to anyone who looked at this. > > On Friday, 3 September 2021 at 11:20:26 UTC+1 stephen.t....@gmail.com > wrote: > >> > >> To follow up on this I should clarify what my questions are: > >> > >> 1) How much of a performance drop (when compared to AMD64 for example) > should I expect when compiling to the WASM target? > >> > >> 2) Is there anything obvious I can do to counter any performance drops? > >> > >> And I suppose this is a non-Go question, but: > >> > >> 3) I know nothing about WASM beyond the bare minimum. How can I profile > and understand the compiled WASM binary? Is it possible to use the pprof > tool in some way? > >> > >> > >> On Fri, Sep 3, 2021 at 10:40 AM Stephen Illingworth < > stephen.t....@gmail.com> wrote: > >>> > >>> > >>> > >>> > >>> On Fri, Sep 3, 2021 at 10:15 AM Brian Candler <b.ca...@pobox.com> > wrote: > >>>> > >>>> Could you explain a bit more about what you're comparing? > >>>> > >>>> - Is the wasm version running in a browser? If so, which one? Or have > you got a way to run wasm directly on the host (in which case, what is it)? > >>> > >>> > >>> Running it in Firefox (78.13.0esr) and Chromium (92.0.4515.159) > >>> > >>>> > >>>> - How is the linux/amd64 version running, if it's not talking to a > DOM-type environment? If the native version is still using syscall/js, then > how is it doing so? Or is the native version in a different repo? > >>>> > >>>> - By "the parent emulator project" do you just mean web2600 itself? > >>> > >>> > >>> Web2600 is using the emulation core of the parent project > >>> > >>> https://github.com/JetSetIlly/Gopher2600 > >>> > >>> The parent project runs on the desktop. It currently uses SDL and > OpenGL etc. but it is designed to allow different methods of presentation. > >>> > >>> Web2600 is using the core of the emulator (ie. the non-presentation > parts) and so doesn't use SDL or OpenGL. > >>> > >>> For presentation, the television package in the core emulation allows > you to register "PixelRenderers". So Web2600 adds itself as a pixel > renderer. The implemented SetPixels(), NewFrame() (etc.) functions will > then talk to the DOM as appropriate. > >>> > >>> The web version works but is just exceedingly slow by comparison. > >>> > >>> > > -- > > 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...@googlegroups.com. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/6bb486eb-7481-4356-94cd-29c365c02416n%40googlegroups.com > . > -- 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/57e25373-2219-4d04-b45d-d8f24501b8c7n%40googlegroups.com.
