Resizeable UI

[p0nce]

• [x] change semantics of reflow, it now is called when setting position, and is only concern with psitionning children.
• [x] make it so that fixed size legacy plugins support variations of UI size if they happen (window listener can demand any kind of size, the better available one is picked, and is black-letterboxed).
• [x] position call reflow and the various setDirty
• [x] renderBuffer has different size from GUIGraphics size (one is seen by the window, the other is internal to the plugin)
• [x] default reflow is changed to do nothing
• [x] Win32Window is created resizeable if supported size is resizeable => no need
• [x] Implement ability to fit output to surface (with crop and black borders), inside GUIGraphics
• [x] request resize widget
• [x] Check if Lanczos3 is better than the OS resizing => it is noticeably sharper, with more ringing too. Perhaps Lanczos 2 more appropriate?
• [x] Declarative way to have resizing information (DPI awareness can be decorrelated). => yes, DPI is a different concern, resizing must be done first. #536 for Windows DPI support, which is hardest. => now logical sizeing info held by GUIGraphics field _sizeConstraints
• [x] Integrate Ethan's PR piece by piece
  • [x] VST request resize (with UIWindowResizer). Hosts (Orion) may require it. IPlug2 doesn't do this, but JUCE does.
  • [x] LV2 => REAPER + Linux doesn't resize parent window, is there a LV2 API for that?
  • [x] Cocoa
  • [x] X11
  • [x] VST3
  • [x] AAX (EDIT: but needs testing on macOS once Cocoa is done)
  • [x] AU
  • [x] resizing Win32
  • [x] GUIGraphics can output in a subrect of given rect, account for offsets and scale when giving rectangles... The objective: GUIGraphics can deal with any input size from the WM.
  • [x] reflowing examples on resize
• [x] Implement #541
• [x] ClipIt resizeable
• [x] Too much memory used by a large ClipIt (~120mb), is it the resizer?
• [x] support UIImageKnob resizing
• [x] UIImageKnob and UIFilmStripKnob should have a resizing that consider each sub-image independently, to avoid leaking and coordinates problems. Currently, there is a slight offset while turning such a resized knob. It should also take less space.
• [x] resizer.d should have a linear mode that go faster and uses less memory, and probably a lanczos2 option too.
• [x] resizer.d should have a mode that is blurry. Lanczos2 or lanczos3 are really bad for resizing depth values, because small amount of ringing provokes comparatively large change in output with the PBR algorithms.
• [x] It should be possible to have a UIELement whose _position is outside the UI. box2i.scaleWithFactor should use rounding then.
• [x] Not sure if PBR rendering scales properly. It is sure that one pass has fixed shadow length, but there is also the question of normals => #546
• [x] Studio One + VST2. Requesting resize, then resizing the client window isn't enought to get Studio One to resize the parent window of the plugin.
• [x] of Course, Cubase does not support their own audioMasterSizeWindow. It would be too simple.
• [x] Similar issue in Ardour + LV2 + Windows.
• [x] Mandriva + X11 + VST2 + REAPER => unusable resize

[p0nce]

In AU sometimes getting the view frame yield surprising results, currently disabled. This will be something to fix before considering resizeable UI.

[abaga129]

I would like to work on this one next. It would be very beneficial for Convergence. Do you foresee any major complications besides the AU view frame issue?

[p0nce]

This is how I think it should work, some of the work was put in place years ago already:

• Any UI widget can call bool _client.hostCommand().requestResize(width, height); from dplug.client.client.IHostCommand to request a resize. This is implementation-specific depending on VST2 / VST3 / AU / LV2 / AAX.

After that, when and if the host does resize the parent window:

• the IWindowListener receives an onResized event in guigraphics.d, which it passes on the GUI root by calling reflow. Override reflow to position all your widgets along-side the UI. Implementing this call is implementation-specific depending on X11 / Cocoa / Win32.
• Seems implemented for X11
• Seems implemented for Win32
• as you said, not done for Cocoa

The method that becomes important is reflow, a virtual method from UIElement in which all lines touching .position of widgets should go. UIElement.reflow is completely overriden by the background widgets, so the default implementation in UIElement should be empty.

I don't think we'll support live resize (the window is resizeable, reflow while resizing the window), sounds more complicated.

[abaga129]

There is more to this than I had considered. I was thinking that resizing would only be from the windowing side of things. I was only considering the case where the plug-in window could be "stretched" to fit the window when it was resized (from the host). In my mind, we would be able to use bi-linear interpolation to draw to the new window size. I'm going to have to put much more thought into this clearly.

[p0nce]

Actually the two solutions are possible and are independent.

I think both type of resizing are needed in the end.

One is about IGraphics having a changing size. (the one I described)

One is about the Windows having a different size than the IGraphics object. Useful for HiDPI(?) and iPad. It's not that easy since rect invalidation is already messy on Windows and currently the code convert IGraphics unit into Window unit without care.

Both can be implemented independently but in both we also need a way to resize an image first (probably could be another subpackage). I think Voxengo has an image resizing library.

[p0nce]

Trying to clarify the situation we want to be in.

EDIT : NOT ACCURATE AT ALL

[p0nce]

Important concept:

• the UI window has a physical pixel size (logical pixel size x DPI)
• the host and plugin clients deals with Logical pixel size
• The UI delas with User pixel size, GUIGraphics does the conversion

[p0nce]

There is a problem right now:

• that onResize is called inside WM_PAINT, followed by onDraw. Resizing needs a full redraw (black borders, moving _userArea). When we draw after a resizing y a widget, recomputeDirtyAreas hasn't been called again, so the getDirtyRectangle doesn't correspond either. Better to put onResize call inside WM_TIMER?

[p0nce]

For proper invalidation, onResized must be put outside WM_PAINT. (EDIT: OK)

Here are the messages seen when creating a plugin window sequence:

Inside CreateWindowEx:
129 WM_NCCREATE
131 WM_NCCALCSIZE
1 WM_CREATE
5 WM_SIZE
3 WM_MOVE
24 WM_SHOWWINDOW
70 WM_WINDOWPOSCHANGING
133 WM_NCPAINT
20 WM_ERASEBKGND
71 WM_WINDOWPOSCHANGED
// following messages are after CreateWindowEx, so you can access the Win32Window
641 WM_IME_SETCONTEXT
7 WM_SETFOCUS
8 WM_KILLFOCUS
641 WM_IME_SETCONTEXT
642 WM_IME_NOTIFY
3 WM_MOVE
15 WM_PAINT

[p0nce]

• [x] macOS + AU tests with CocoaWindow patch.
• [x] Logic => no problem
• [x] Live 10 => no problem
• [x] REAPER => host window parent doesn't resize properly (it is bridged for some reason !? no such problem in VST) => a REAPER problem, not ours
• [x] Studio One => crashes at exit, wrong placements in VST and AU after the plugin is reduced in size vs before. Crash at exit is unrelated to Dplug plugins. => try to align _userArea on topleft if view size changes? => doesn't change shit, margin is host-generated => VST3? => no problem => seems like a Studio One problem...
• [x] Protools + AAX => no problem with 11.0.8+

[p0nce]

I'm happy to say that plugin resizing is now supported! That was the oldest ticket alive. Support in 11.0.8+

[p0nce]

Remaining known issues:

• small resizing issues with Cubase + Windows + VST2 (host window doesn't resize and Cubase doesn't accept sizeWindow... hard to resize the parent window too with Win32)
• small resizing issues with Studio One + VST2 or AU + Mac (host window may be off if plugin has been made smaller at one point)
• REAPER + Mac + AU bridges the AU, and then doesn't resize the host window properly

[redthing1]

Is there a code example?

[p0nce]

Distort and ClipIt now have a resizing widget in the bottom-right corner. They are the reference examples to copy.

[p0nce]

Didn't see any issue with Cubase 12 + Win 11 + VST2 or VST3