Using Chrome DevTools Protocol for webvfx

[coolwanglu]

This is a followup to my comment in #422 . I'd like to bring up the idea ot use Chrome (instead of QtWebkit) for webvfx, here Chrome could be local, headless or remote.

I made a prototype the connects mlt/Shotcut with Chrome via DevTools Protocol: Demo, Explanation, Code

This is actually quite easy to implement, although there are still lots of details to work on.

In generall the prototype includes a mimimal MLT plugin (which is webvfx minus qtwebkit), that talks to a nodejs process via IPC. The nodejs code then talks to Chrome via DevTools Protocol.

This way we can always use the latest Chrome for rendering, which means better support for web standards, hardware acceleration and V8. Chrome is decoupled from MLT, it can be upgraded separately. Another benefit is that the MLT plugin code will be greatly simplified, there's no longer dependencies on qt or webkit. In my prototype the c++ code only need Boost.Interprocess and libpng.

There might be concerns about dependending on nodejs modules, but DevTools Protocol is in general JSON-RPC over Websockets, so with some efforts it should be possible to directly talking to Chrome from C++ (strangely I didn't find a library for this).

DevTools Protocol allows exposeFunction, evaluateOnNewDocument and evaluate. These should suffice for creating the webvfx object.

The only concern I have is performance. I didn't test it thoroughly but there must be quite some overhead. It works OK in my demo though.

[ddennedy]

I know about your work on this from your other posts. It is interesting, but I am also skeptical. Besides the performance overhead especially after increasing the feature scope, there is going to be brittleness with RPC and a dependency on Chrome. This will not support multiple processes well AFAIK. Think about background render/export in Shotcut while accessing a project using it in the Shotcut GUI foreground process. Basically, this is not something I want to help with at this time. I need to turn my attention to some different things in MLT for 2020 (e.g. performance and HDR). You should consider expanding on it out of your own need and curiosity, but I cannot say at this time if it will make it into Shotcut. When I think about the future of Shotcut and WebVfx, it seems current WebVfx will have to die or go pure QML. This approach could work out and win favor.