I’ve been pleasantly surprised by the HTMLTexture nodes ability to handle complex WebGL. But the framerate of a 1920x1080 texture is very low, say 2FPS, while the patch is reporting running at 60FPS (see attached patch).
What’s odd is that my CPU usage (i7-3770K) is still very low, with no cores showing more than 30% and the graphics card (GTX770) is showing no use at all (5%).
The FPS depends on the texture size, so it would seem rendering or memory related, but I don’t see it in my machine activity levels.
If you run the patch, it will take a while to load the WebGL page, but then start it. If you click the camera icon in the lower right you can then use mouse drag to change the camera position. The lag is quite pronounced; and seems to get worse when there is more rendering (side shots).
HTML-WebGL.v4p (9.0 kB)
AHA! I suspect it has something to do with CEF thread sync. I noticed when I clicked on this web page, the FPS of the renderer dropped to 30FPS (default MainLoop behavior when in background) but the HTML rendering dramatically sped up! Hmmm, slowing the vvvv main loop down allowed the rendering to get in to update…
So I set the Renderer presentation interval to “immediately” and BAM! Considerably higher framerate. CPU and GPU levels still the same, so must be some kind of sync problem.
Now it gets some horizontal tearing of course, but no comparison on how it works. Setting the MainLoop foreground and background rate to 60 (my display rate) seems to help a bit with the tearing and smoothness.
In any case, seems like a bug. There should be some better way to sync the CEF texture (HTMLTexture input pin with mS to wait? Option to block for it?).
Now if someone can just tell me why the tires are invisible…
HTML-WebGL-Immediately.v4p (11.2 kB)
