[LV2] inline plugin displays (Robin Gareus)

[Robin Gareus]

On 03/17/2016 12:04 AM, Vladimir Sadovnikov wrote:
> My look towards the concept.
> 0. In general, the idea is cool but needs some fixes.
> 1. The idea to build-in the display as an plugin-extension interface is
> bad. The original concept of LV2 was to separate the UI and the DSP
> accorting to MVC concept. So we have to follow it.

There is no Controller here. Only a model and a view. I'd even go as far
as saying it's not a "view" but a status info [of the model] :)

> 2. I think that the better solution is to pass from the host the handle
> of the window/or context for drawing, not to get this context from the
> extension interface.
> For example, on Linux it can be an X Window, on Windows - HWND etc...

I prototyped this with X11 and Cocoa. Frankly, it's a non maintainable
mess for lay-outing. You'll basically end up with libsuil.

For this to work you'll need to bridge events: at least expose and
invalidate, window size requests + constraints (aspect ratio),
color-maps etc etc.

So far nobody stepped forward to improve support for Cocoa and HWND, and
Wayland will also change the game there.

The only advantage of using a window handle would be to allow sub-pixel
rendering of fonts on OSX and maybe some Linux systems, Windows' bitblt
can't composit to begin with.

The main intention for ARGB32 was to use a very common basic standard,
which - as RUI pointed out - is slated to become part of std C++. and
avoid _all_ platform specifics.

> 3. This idea can be extended to make possible the visibility of some
> important controls on the mixer stripe. So we return back to the UI
> extension.

This is an entirely different project IMHO. Frankly I don't see a valid
use-case for having *custom 3rd party controls* directly on a Mixer strip.

There are about two valid use cases: show EQ curves, show compressor
gain reduction. Maybe some one-off specific displays, but most
everything else just gets in the way when mixing or mastering under time
pressure.

> Conclusion: this can be implemented as the sort of UI, the class of UI
> could be called also 'thumbnail'.
> Because it is the sort of UI, I think, we don't need the additional
> extension interfaces, just the implementation of thumbnail UI (with
> support of GTK2, GTK3, QT4, QT5, etc...) and proper binding to the plugin.

Why would you do that? None of these toolkits provides any widgets
suitable for pro audio to begin with.

ciao,
robin