[LV2] Ui update rate

[David Robillard]

On Sun, 2013-05-05 at 13:31 +0200, Robin Gareus wrote:
> On 05/05/2013 05:53 AM, hermann meyer wrote:
> > Am 04.05.2013 20:36, schrieb hermann meyer:
> >> Am 04.05.2013 19:53, schrieb Robin Gareus:
> >>> On 05/04/2013 07:38 PM, hermann meyer wrote:
> >>>> Am 30.04.2013 16:10, schrieb Harry van Haaren:
> >>>>> On Tue, Apr 30, 2013 at 3:00 PM, hermann meyer<brummer- at web.de
> >>>>> <mailto:brummer- at web.de>>  wrote:
> >>>>>
> >>>>>      Is there a way to receive the UI refresh rate from the host?
> >>>>> Currently, no there is not, if you're using the LV2UI_Idle_Interface
> >>>>> to redraw your UI?
> >>>>>
> >>>>>      It could be helpful to now this for analyze plugs.
> >>>>>
> >>>>> I'll agree, there are many use cases where intended framerate of UI
> >>>>> would be useful.
> >>> +1
> >>>
> >>> as a side-note: I recently patched jalv.gtk. With jack2 its default
> >>> plugin<>UI Atom message rate is 2Hz! Hence no matter how fast the UI
> >>> runs that's a worse bottleneck.
> >>>
> > Well, I see I've ask the question wrong, I mean indeed the communication
> > rate from plugin to UI.
> 
> Hi Hermann, Hi LV2devs,
> 
> They are really the same.
> 
> It does not make sense to update the UI more frequently than it can
> receive/send messages. - The only exception are display animations which
> operate independently on the current data.
> 
> So screen "update-rate" should equal "message update-rate" and plugins
> that do want to do /fancy/ things should create their own threaded event
> loop (and get their own connection to the x-server to avoid xlib/xcb
> threading issues -- not a problem on win or OSX).
> 
> Do you agree?

No.  Expose events, among other things, cause redraws.

Plugin UIs creating threads sucks, and only causes more problems.  I see
no reason why anything should do that, fancy or not, and if there is
one, it should be fixed.  That is, if the idle interface isn't good
enough for something "fancy", then it should be.

The way I see it, no matter what the UI code needs to draw when told,
and get updates when told, so there is little if any reason to
complicate the spec/API with this sort of thing.

-dr

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.lv2plug.in/pipermail/devel-lv2plug.in/attachments/20130506/6962f577/attachment-0002.pgp>