[LV2] inline plugin displays

[David Robillard]

On Wed, 2016-03-16 at 22:59 +0100, Robin Gareus wrote:
> On 03/16/2016 10:49 PM, David Robillard wrote:
> > On Tue, 2016-03-15 at 03:47 +0100, Robin Gareus wrote:
> >> Hi all,
> >>
> >> Here's another small ad-hoc LV2 extension. I've just prototyped adding
> >> inline mixer-strip displays. A picture says more than words here:
> >>
> >>   http://robin.linuxaudio.org/tmp/inline_display.png
> >>
> >> small LV2 UIs; display only (non interactive) pixmaps.
> >>
> >> The API consists of two calls:
> >>
> >> 1) A LV2 extension provided by the plugin to render a pixmap.
> >>
> >> This is function is provided by the plugin's shared-object itself (not
> >> the GUI) because it must also be available when the plugin GUI is not
> >> visible (not even loaded). It's intended for visualizing the most
> >> relevant plugin parameters in a tiny area (~100x100px).
> > 
> > There is a longish discussion on IRC about this, but in summary, I think
> > this should indeed be a UI 
> 
> [..]
> 
> > But, to avoid too tedious
> > of a discussion, I could sum it up with: the *possibility* of DSP/UI
> > separation in LV2 is non-negotiable. 
> 
> Agreed. Which is exactly why I didn't propose this extension as an UI.
> 
> (no port events, no dedicated instantiate, not UI events).
> 
> Think of it as a "lv2:Worker" thread which works in the background and
> generates an image. That would be my proposed fallback solution:
> defining a few URIs to ship out the image on an Atom port. Though I'll
> have to do my homework regarding performance there first.

Even worse.  It's still clearly "UI stuff", but with lack of separation
built-in (i.e. forced), and forces host authors to implement a bunch of
new stuff they shouldn't have to.

Not a chance I'll be messing up my hosts like that, without some very
good reasons why I should, and I don't see any.

> IMHO inline-displays are orthogonal to a new UI type. That being said I
> do very much welcome proposals to add a dedicated ui:argb32 LV2 GUI
> type, or even better ui:cairo_t  Any takers?

Cairo would be nice, but I doubt any strong long-term binary
compatibility there is really possible, and people would probably like
to be able to render with other things anyway.

Cost of drawing the entire pixmap each time is inherent, but the
lifetime rules in the API should be written carefully to allow for the
possibility of partially regenerating images, i.e. re-using the old
buffer in the process of generating the new one.

-- 
dr