search

ShortestPathLab / posthoc-app

Posthoc is a way to build simple and effective visualisations ✨ for sequential decision-making algorithms, such as search.
http://posthoc-app.pathfinding.ai/
29 stars 5 forks source link

Firefox performance issues #51

Open dharabor opened 1 month ago

dharabor commented 1 month ago

The app is quite slow to load at the moment (Firefox 130.01). The only feedback the app gives is that it's trying to connect to a solver. If the solver is indeed slowing things down, it seems better to connect to it only when some solver-specific functionality is required.

For discussion.

dharabor commented 1 month ago

I managed to get the app to load, eventually, by forcing a reload via the inbuilt browser debugger. I then tried to upload a trace and the app went into an infinite loading state. I tried the same example in Chrome, and it all works. Two things then:

  1. Something is wrong here. I'm not sure how to get more information.
  2. We need to treat Firefox as a first-class target platform in development. If Posthoc doesn't work on FF, it doesn't work.
spaaaacccee commented 1 month ago

TL;DR it seems Firefox has some issues with WebGL.

I'm not able to reproduce the loading problem (tried Windows 11 + FF, Windows 11 WSL + FF)

I do get this warning in Firefox:

image

This issue appears to be related to https://github.com/pixijs/pixijs/issues/5751 and https://bugzilla.mozilla.org/show_bug.cgi?id=1246410 and https://discourse.threejs.org/t/firefox-on-windows-webgl-creation-failed/51365/3

The author suggests Firefox (maybe worse in Linux) seems to have some problems with WebGL: https://github.com/pixijs/pixijs/issues/5751#issuecomment-498615121

Trying out a WebGL aquarium benchmark, I was able to get 20k fish before the FPS falls below 60 in Chrome, but only 1K in Firefox. image

Ok I started to get the same error as in Posthoc in the aquarium demo when I went to take a screenshot: image

If WebGL2 not loading is the cause, the lagginess will be due to falling back to a canvas renderer, which will be much slower. This seems to be a Firefox bug.

Workaround would be to use the Pixel Nano renderer, which will be slightly lighter on the system.

dharabor commented 1 month ago

Interesting. The bug I experienced wasn't slow performance, but it's good to know that could be an issue. Do you know if Safari suffers in any way? I'm hoping no, given it uses WebKit instead of Gecko?

Anyway, my error is complete unresponsiveness and a lack of any UI. Just endless spinner. I tried a few more configurations of the browser and eventually narrowed it down: it only happens when the VimVixen plugin is running. Once disabled, I was able to load a trace and visualise the result.

I'm wondering if there's a some way to handle these kinds of issues. In the case of slow performance, it would be good to indicate to the user that there is some kind progress (like, percentage loaded, when uploading a trace). What about in the latter case? The browser hasn't crashed and some kind of web worker is still responsive (we continue to show the spinning animation) but other parts of the loading process have not progressed in a while. It would be good to print an warning or some informational text in this case? e.g., "this is taking too long; check your browser settings/plugins"