libvisual: Improve lv-tool a bit

[hartwork]

Inspired by #150

[kaixiong]

Can you explain why you decided to switch the default actor to lv_gltest? My preference is to not require OpenGL for a default.

Upping the frame rate cap to 60Hz is a nice thought. Are there any plugins that are frame rate dependent?

[hartwork]

Can you explain why you decided to switch the default actor to lv_gltest?

@kaixiong my main motivation was that I like lv_gltest a lot — I think it looks really nice — while lv_analyzer feels more like a debugging tool or an actor demo, in its current state.

My preference is to not require OpenGL for a default.

I was wondering the same. What could happen with a GL actor for a default worst case?

Upping the frame rate cap to 60Hz is a nice thought. Are there any plugins that are frame rate dependent?

Actor lv_gltest is — even after pull request #153 —, probably others too. Anything that doesn't use a timer in its render method (or its call tree), I suppose. From a quick look my guess is most of them are.

[kaixiong]

@kaixiong my main motivation was that I like lv_gltest a lot — I think it looks really nice — while lv_analyzer feels more like a debugging tool or an actor demo, in its current state.

My preference is to not require OpenGL for a default.

I was wondering the same. What could happen with a GL actor for a default worst case?

@hartwork
To be honest, I struggle to think of any environment where you might run lv-tool without OpenGL, despite having OpenGL plugins built and deployed there. Would love to hear some feedback from other people on this point but there probably isn't much coming our way until the change is released.

One solution to this is check for OpenGL support and default to either lv_analyzer or lv_gltest accordingly. However, I am feeling too lazy to attempt that!

Upping the frame rate cap to 60Hz is a nice thought. Are there any plugins that are frame rate dependent?

Actor lv_gltest is — even after pull request #153 —, probably others too. Anything that doesn't use a timer in its render method (or its call tree), I suppose. From a quick look my guess is most of them are.

Makes sense. I just did a random tour of the plugins with a 60Hz cap and the visualizations looked okay (didn't go nuts).

There are roughly two reasons for this:

• The visualization is based on audio input that comes in at a fixed rate, independent of frame rates
• Software visualizations do not scale very well on my large monitor (running at 3440x1440 @ 100Hz), so they struggle to hit the FPS limit of even 30. I run a Ryzen 7 3800X.

I imagine the frame dependent portions are where the visualization applies some transformation per frame e.g. rotating the camera view, applying motion blur, etc. Some of these transforms e.g. convolutions aren't easily parameterizable by time (or time deltas) and will probably require locked frame rates. But this is a discussion for another time.

[kaixiong]

@hartwork To be honest, I struggle to think of any environment where you might run lv-tool without OpenGL, despite having OpenGL plugins built and deployed there.

I might have just answered my own question. What happens when OpenGL plugins aren't built? They are currently optional.

[hartwork]

@kaixiong I have made it depend on the availability of OpenGL now (and rebased onto latest master). What do you think? I think the chance of users going "wow!" when they first run lv-tool is a lot higher this way.

[kaixiong]

@kaixiong I have made it depend on the availability of OpenGL now (and rebased onto latest master). What do you think? I think the chance of users going "wow!" when they first run lv-tool is a lot higher this way.

I just remembered that a hard-coded default will fail one way or the other since every plugin build is optional. lv-analyzer can be missing too.

What we will eventually need is for lv-tool to also prioritise certain plugins for default after discovery. For now, this pull request is good to go.

[hartwork]

@kaixiong good point! 👍

[hartwork]

What we will eventually need is for lv-tool to also prioritise certain plugins for default after discovery. For now, this pull request is good to go.

For anyone finding this discussion later, see pull requests #178 for in master and #150 for 0.4.x for a dynamic default.