Webpage rendering problems

[Bodysoulspirit]

Steps causing the bug to occur

Yesterday as I posted a feature request for Lottie files (https://community.vuo.org/t/-/7086), I thought "before having to implement the whole thing natively into Vuo, why not just a web browser engine and the Make Image From Web node ?
Tried with : https://lottiefiles.com/111792-preloader

But then some bugs happened.

a - For the joined composition, it does load the webpage, but then
b - It stays static at first.
c - It’s only when you set the composition in fullscreen that it still stays static, but after you EXIT the fullscreen mode, the page animation is displayed.
d - And an artefact appears, an extra image of the web page beside the composition screen that only disappears when quitting the composition (see screenshot).

e - Then going back fullscreen the animating stops again.
f - Also sometimes, when changing the output image size, it stops also, and you have to redo the go-fullscreen + undo-fullscreen to see the animation again.

Not specifically linked to this Url though. The same happens for example with https://cdn.svgator.com/images/2021/10/solar-system-animation.svg

I’ve been reading this bug report (Fire periodically and OS Monterey on ARM Mac : https://community.vuo.org/t/-/7048) and Jaymie’s answer. But somehow it’s sad we can’t have a robust and speedy way to display all kind of html stuff.
The world is so web based nowadays and there is such a big amount of web related technologies that are being developed faster than any other.

I really wished there was an up to date browser / render engine that would allow all web stuff to be displayed smoothly.

Side question : Even though an hypothetical up to date engine would be used and everything would be displayed, would we always be getting a speed trade of because the node outputs an IMAGE ?
I mean would it be faster if we had a thing like “Render HTML to window” as a port type and Render node set ?

Thanks

Hardware : MacBook Pro M1 Pro 14"

Have you found a workaround?

No

Other notes

• Vuo version: 2.4.0
• macOS version: macOS 12
• CPU: arm64
• Have you been able to reproduce the problem? Yes, the problem occurs consistently when I follow the steps above
• How severely does this bug affect you? It prevents me from completing a specific task with Vuo.

Render Web Page.vuo (2.64 KB)

[jstrecker (Jaymie)]

As you noted, problems playing videos and Lottie files in Make Image from Web Page are caused by basically the same underlying problem: limitations with the macOS web browser engine that the node uses to render web pages.

We recently tried a few more experiments in search of a relatively quick fix or workaround. But there really doesn’t seem to be one. The node renders the web pages to an offscreen window and then turns the result into an image. There doesn’t seem to be any way to trick the browser engine into playing Lottie animations when rendering to an offscreen window.

You asked about outputting an image vs. outputting directly to a window. If literally all you want to do is display the webpage, then you can use the Open URL in Browser node (and Lottie animations will work). In contrast, outputting to an image makes it possible to integrate the image with other Vuo graphics and to interact with the page within Vuo. Outputting directly to a window would not be noticeably faster, since macOS would still be internally rendering to an image that it provides to the window manager.

Coming back to the main question of the bug report — We’d have to investigate further to know just how difficult it would be to get around the limitations currently in the Make Image from Web Page node. Recently we thought of one potential solution, which would be to render the image to a virtual screen rather than an offscreen window, but we’d have to try it and see if it worked. If not, the only solution we know of would be to reimplement the node with a different web browser engine, as I mentioned on the other bug report.

Although the limitations with Make Image from Web Page are arguably a bug rather than a missing feature, the amount of effort required to fix the limitations is more like a feature request than a typical bug report. So if this is important to you, please create a feature request, linking to this bug report, so the community can prioritize it relative to other improvements.