All animations except for the progress bar should be disabled during export.

[Sawuare]

Examples: • note playing indicators. • automated parameters (knobs, faders, etc.). • time-line position marker. • mixer channels.

I don't think their animations are useful during export. Disabling them during export will leave more processing power to more important stuff.

[Spekular]

Is there evidence that the power used isn't negligible? I don't entirely disagree with this, but moreso from an aesthetic standpoint in that it looks rather chaotic to have these animations play out in the background when the export window is supposedly in focus.

On Oct 10, 2017 18:27, "Hussam Eddin Alhomsi" notifications@github.com wrote:

Examples: • note playing indicators. [image: image] https://user-images.githubusercontent.com/25503477/31396922-4bcabbcc-aded-11e7-9cb4-7e26c73d1d3d.png [image: image] https://user-images.githubusercontent.com/25503477/31397285-44e9577c-adee-11e7-8f82-9449f64aa4f7.png • automated parameters (knobs, faders, etc.). • time-line position marker. [image: image] https://user-images.githubusercontent.com/25503477/31396958-658de200-aded-11e7-87cb-0692f26a4bd0.png

I don't think their animations are useful during export. Disabling them during export will leave more processing power to more important stuff.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/LMMS/lmms/issues/3870, or mute the thread https://github.com/notifications/unsubscribe-auth/AIgVmtE1FG613ua6UiBs7JcuWaI5Z-Ndks5sq5rmgaJpZM4P0N4o .

[tresf]

Is there evidence that the power used isn't negligible? I don't entirely disagree with this, but moreso from an aesthetic standpoint in that it looks rather chaotic to have these animations play out in the background when the export window is supposedly in focus.

Then you're arguing a moot point. Please don't burden the devs with unnecessary benchmarks, they have enough work to do.

... and for the record, the UI isn't exactly innocent from a performance perspective. 🍺

[musikBear]

Would a completely blanc export-screen + a percentage display, be an option? I also want to mention the delay between apparently finished export, and when the file has been closed: eg render-finished indication

3854

[tresf]

Would a completely blanc export-screen + a percentage display, be an option?

Ideally, we'd lock out the UI and use a notification area. We can also leverage the platform-specific progress area in the dock.

[softrabbit]

I did some benchmarking in ProjectRenderer::run(). Basically the first example from this doc: http://pubs.opengroup.org/onlinepubs/009695399/functions/times.html inserted at the beginning and end. Exhibit A is TobyDox-Psycho, available in your LMMS source tree, rendered with the windows like they come out of the box, i.e. the cursor scrolls out and there is only the master channel in the mixer. B is a project of mine with 10 mixer channels and the song editor zoomed out to show everything (= cursor keeps scrolling, was the thought).

Each render was done in a freshly started LMMS instance, wav format, x1 oversampling, 44100 Hz, sincfastest, 16 bits deep. Average of 3 runs unless otherwise noted. Times are in ticks (probably 100/s), but that doesn't matter, as it's the differences that matter.

Real time	User	System	U+S %	File
2925	5660	505	100%	A, cli
3243	6904	1546	137%	A, gui
5134	11563	800	100%	B, cli
7236	17030	2864	161%	B, gui
7216	16623	2871	158%	B, gui, mixer hidden (1 run)
6977	16371	2771	155%	B, gui, all editors hidden (1 run)

The numbers on repeated runs were consistent enough that I didn't bother for those last two.

This should give an idea on how much the entire GUI adds, and if disabling animations is comparable to hiding all editors (last line), I'm not sure it's worth it. Some more experimentation is needed to know for sure.

[Spekular]

Quick check of how much slower "B, gui" is when compared to "B, gui, all editors hidden (1 run)" percentage-wise, so anyone else curious doesn't have to take out their calculator.

Real Time: 7236/6977 = ~103.7% => ~3.7% slower

System Time: 2864/2771 = ~103.4% => ~3.4% slower

On Oct 11, 2017 23:13, "Raine M. Ekman" notifications@github.com wrote:

I did some benchmarking in ProjectRenderer::run(). Basically the first example from this doc: http://pubs.opengroup.org/onlinepubs/009695399/ functions/times.html inserted at the beginning and end. Exhibit A is TobyDox-Psycho, available in your LMMS source tree, rendered with the windows like they come out of the box, i.e. the cursor scrolls out and there is only the master channel in the mixer. B is a project of mine with 10 mixer channels and the song editor zoomed out to show everything (= cursor keeps scrolling, was the thought).

Each render was done in a freshly started LMMS instance, wav format, x1 oversampling, 44100 Hz, sincfastest, 16 bits deep. Average of 3 runs unless otherwise noted. Times are in ticks (probably 100/s), but that doesn't matter, as it's the differences that matter. Real time User System U+S % File 2925 5660 505 100% A, cli 3243 6904 1546 137% A, gui 5134 11563 800 100% B, cli 7236 17030 2864 161% B, gui 7216 16623 2871 158% B, gui, mixer hidden (1 run) 6977 16371 2771 155% B, gui, all editors hidden (1 run)

The numbers on repeated runs were consistent enough that I didn't bother for those last two.

This should give an idea on how much the entire GUI adds, and if disabling animations is comparable to hiding all editors (last line), I'm not sure it's worth it.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/LMMS/lmms/issues/3870#issuecomment-335950159, or mute the thread https://github.com/notifications/unsubscribe-auth/AIgVmvaWQ-lthLSsKXi5A1BQ82a7gg_Uks5srS9egaJpZM4P0N4o .

[tresf]

if disabling animations is comparable to hiding all editors

Wouldn't it theoretically be closer to CLI? Hiding editors may reduce paint sequences, but the UI is still having functions and slots called.

[softrabbit]

Wouldn't it theoretically be closer to CLI? Hiding editors may reduce paint sequences, but the UI is still having functions and slots called.

Could be. Depends on how much heavy lifting happens in those functions and slots, guess the reality is somewhere between those numbers.

I'm a bit surprised that the impact of hiding editors is that small, really. Probably another thing in need of some care and attention...

[softrabbit]

I made some quick changes: stopped emitting the periodicupdate signal in MainWindow::timerEvent, which turned off the mixer VU meters and the position counter updating. Then added a fast exit to SongEditor::updatePosition and TimeLineWidget::updatePosition to stop the playhead from moving in the song editor. Next up was not emitting newNote in InstrumentTrack::processOutEvent which stopped the track buttons blinking.

All animation that's left now is the pianos in the piano roll editor and instrument window, and automated knobs moving, and I'm roughly down to the "all editors hidden" level from my earlier benchmark. Don't know if I'll go further on this road.

[michaelgregorius]

Until some weeks ago I would have agreed to disable the animations during export because it seems rather strange as in: "Hey, you already know that you are in export mode so why do you bother to update the GUI?"

However, some weeks ago I have bought Bitwig and it also animates everything during export. So it seems that they also implement the export with a file device that is not bound to realtime with everything still bound to the GUI.

In a way it's also the simplest implementation because to disable animations for an "export mode" you'd have to add extra code that might also degrade over time, i.e. new features are implemented and it is forgotten to disable their animation during export.

[musikBear]

you'd have to add extra code that might also degrade over time

Yes, it would have to be a test up against the pro and the con, as in a swat-analysis, but there are SO much else that is more important -imo