noio
commented
10 years ago So you're saying that a resolution other than 1:1 is slowing things down? (edit: nvm I re-read your comment. ynohtna's suggestion is useful though)
Aside from that, I think a clean solution would be to always have the canvas resolution match the window size (handle onresize), but allow the user to reduce that for performance reasons using a menu button in the top bar; or perhaps a code call: resolution half or something.
ynohtna
davidedc
There should be a way to better control the resolution of the canvas context(es). Going full-resolution,especially on high-dpi devices, is an overkill and a fps killer.
Currently, the resolution is set to the size of the browser window when the system is initialised. BUT note that fps changes a lot when the browser window is enlarged or enters in presentation mode - even if the resolution of the contexts seems to be remaining to the original resolution, which shouldn't really happen because the GPU should be still working on the original-size buffers and just then cheaply scale them to the new extent of the window.
A little investigation is needed on why that happens, as it shouldn't happen.
For example, in the default mode of retina macbook 13'' of 2013 (i.e. "Best for display"), opening LCL at the minimum possible size runs the turbine demo at 60fps:
...then degrades when the window is expanded (note that the resolution of the 3d context is still the original -very small- resolution)
...and also has the same unacceptably low fps in presentation mode, although again the context resolution is the same:
On the same machine, the performance is vastly better when in scaled -> Larger text mode - see 60 fps here at a context resolution clearly higher than the previous example:
Some of this may be due to quirks of browser/gpu/os, but I remember that suspicious varying-fps-with-same-context-resolution happened on non-retina display macbook pro as well, so there is something fishy going on there.
Possible ways to investigate: