[split] Resizing the main window speed - horizontal vs vertical

[johne53]

I just discovered that adjusting the Mixer's height (when in Playback mode) produces some very serious graphical problems, compared to adjusting its width. Adjusting the width can be slightly 'clunky' but when I adjust the Mixer's height, all hell breaks loose! The Editor window pretty much grinds to a halt and my DSP reading rises sharply (getting quite close to the zone where I'd expect to hear audio glitches).

Just wondering if this happens on the other platforms too..?

[Ben@Harrison]

@john:

I've split this into a different thread because it seems a different topic.

The difference in resizing behavior is:
horizontal resize: the horizontal scrolling panes "open" or "close", with no layout changes required.
vertical resize: the gtk packing algorithm is engaged to recalculate every widget's size.

Resizing the main window is very slow (on all platforms) and that's something that always bothered me. But in practice you do this perhaps 1 or 2 times daily. It is of pedantic interest, but not a practical problem when mixing.

The reason for the slowness is that Mixbus is translated in multiple languages, and it is resizing buttons on-the-fly to fit your text in the allotted area(s). Personally I am not a fan of this behavior; I'd rather the button sizes stayed constant (to fit English text) and the text was cropped to fit in it, when necessary. But that decision predated my involvement in the project.

It might be possible to optimize the "resizing" behavior. But since it is a relatively rare operation, it's never made the top of our priority list.

Best,
-Ben

[johne53]

Hi Ben. Is there an argument for not allowing the mixer to resize when in Playback mode? (or at least not allowing the vertical height to get resized?)

[Ben@Harrison]

no, I don't think so. The DSP is still running realtime, whether you are playing-back or not.