search

Looking-Glass / HoloPlayJS_Issues

A repository for feature requests and bug reports for the HoloPlay.js library. This repository doesn't contain source code. You can download the HoloPlay.js library at http://look.glass/threejs
0 stars 0 forks source link

Performance issue, because canvas is resized before every render #15

Open soadzoor opened 3 years ago

soadzoor commented 3 years ago

I've been playing around with holoplay.js for a few days. I have the 8.9" version of looking glass. With some minor modifications I was able to make one of my three.js projects (a model-viewer) compatible with it, but I immediately noticed a massive performance drop (FPS went from 60 to 15). First I thought it was the model being too complex, and the fact that it needs to be rendered from 45 different angles. Then it quickly turned out it doesn't matter which model I'm viewing, whether it has 500k vertices or 8, the FPS can't really go above 15-16 FPS.

See this for an example: https://photos.app.goo.gl/6wfmzHQjg7u43itf7

So I've made some investigation, performance monitoring, and it turned out that 90% of the processing time is spent with resizing the canvas. Before every render, the canvas is being resized, and it causes a huge performance issue. I thought I could "hack" my way through this with putting a simple check within holoplay.js, like if (newWidth != oldWidth), but it seemed the resolution switched between 4096x4096, and 2560x1600 (the native resolution of the looking glass display).

Can anybody point me to the right direction? Why do we resize the canvas twice / render, when the common sense tells me it should be resized only when the browser window is rezised (or the user goes to fullscreen)?

Thanks in advance

alxdncn commented 3 years ago

Hi @soadzoor!

We resize the canvas in order to create a quilt that is 4096 by 4096. Then we return it to the resolution of the display, and blit the result of that quilt with the lenticular shader applied to it to the screen.

This is our best understanding of how to do this currently. There is no question that we have heavier rendering requirements than normal, so it doesn't surprise me that it's slowing down your project. We're working on a lot of performance optimization stuff, but currently that is being directed towards OpenGL renderers - we'll need to circle back to WebGL.

soadzoor commented 3 years ago

Hi @alxdncn ! Thank you for the quick response! I don't claim I understand everything that's happening behind the scenes, so forgive me if my question is stupid:

alxdncn commented 3 years ago

It may be possible to do two separate canvases - I'm not a three.js expert by any means! Really all we need is to create a texture that is 4096 by 4096, apply a shader to it, and then blit that to the 2560 by 1600 canvas. If that doesn't require resizing and that can save us some processing time, that would be great!

We're looking at ways to make our software more open and accessible in 2021 - we'd like to be more open, and more open source. I'll look over some of our options for HoloPlay.js - we'd love to get some pull requests to help improve the software!

soadzoor commented 3 years ago

In this case, I think it would work! Let me know if there's a way I can help, I'm quite familiar with three.js!

brianpeiris commented 3 years ago

Somehow this is not an issue in Firefox, but Firefox suffers from #16.