GUI is double scaled in Windows Cubase

[sadguitarius]

Hi @Tremus, this mirrors our Discord conversation from a while ago. I'm seeing the GUI open with twice the appropriate scale in Windows 11 Cubase. Even if I resize the window and then close it, it will reopen with twice the scale it previously had when I closed it. Here's my last comment from the Discord thread for reference:

I have a dumb but effective workaround that's handling all the edge cases I've thrown at it so far. If the host is DPI-unaware, leave the scaling as is. If DPI-aware, set the default scaling to the display scaling setting in Windows (handling hosts like Reason that don't implement scaling at all), but keep a record of whether cplug_setScaleFactor has been called yet so on the first scaling call from the host (if the host implements scaling), reset the scale to 1.0 since some hosts (Cubase for one) make assumptions about the current window dimensions based on what scale the program thinks the plugin GUI is. So if you were already scaled to 2x and Cubase sets the scale, it may wrongly resize the window because it thought you were at starting at 1x scale. That's my understanding at least. Anyway, it works well and would only require minimal changes to the CPLUG windowing extensions

This fix was based on the CPLUG windowing library from before it was refactored, and I haven't yet updated it to run on the current commit, but the basic idea shouldn't change (and should carry over to sokol gfx fine as well). Does this make sense?

Otherwise, I'm loving the slickness of how you've gone about this! And I'd been thinking about a way to involve sokol as well, so great job all around!

[Tremus]

Hey @sadguitarius. Unfortunately I can't reproduce this growing GUI size problem with Scream on Windows 11, inside Cubase 14, when using display scale settings of 100% and 150%.

What exactly were the steps you took when you had this problem? Perhaps I'm missing something.

I just had a play with Reason 13.5 Windows 11. Reasons interface appears to mostly support scaling. What I see happening is that if you launch Reason with 150% scaling already applied, Reasons interface and everything all runs at 150%. Unfortunately, they do not call cplug_setScaleFactor() at all. Scream still appears to load with the correct scaling applied due to us querying Windows APIs ourselves during window creation.

Scream/src/platform_win.c

Line 40 in 191dee3

float system_get_content_scale() { return (float)GetDpiForSystem() / (float)USER_DEFAULT_SCREEN_DPI; }

Scream/src/gui.c

Lines 355 to 371 in 191dee3

	void* pw_create_gui(void* _plugin, void* _pw)
	{
	CPLUG_LOG_ASSERT(_plugin);
	CPLUG_LOG_ASSERT(_pw);
	LinkedArena* arena = linked_arena_create(1024 * 64);
	GUI* gui = linked_arena_alloc(arena, sizeof(*gui));
	gui->arena = arena;
	gui->pw = _pw;
	Plugin* p = _plugin;
	gui->plugin = p;
	p->gui = gui;
	extern float system_get_content_scale();
	gui->layout.content_scale = system_get_content_scale();

Reason 13.5 also doesn't appear to support changing the display scale while the program is running. Changing the scale makes Reasons interface blurry. Popular synth plugins Vital, Surge (both built using JUCE), and Serum 2 (VSTGUI?) don't appear to support changing display scaling on the fly inside Reason. It might not be worth it to try and be the first to tackle a hacky workaround. The simplest solution for Reason users is to close Reason, change the scale, then reopen Reason

[Tremus]

BTW that change was made around the time we last had this had this convo, so thanks for bringing this up. I did my best to polish all that stuff up

c9d828b

[sadguitarius]

Oh ok, I'm using a scale factor of 200% so that may be why you're not seeing this happen. All I'm doing is instantiating the plugin, opening the UI, resizing it, closing it, and observing that the size doubles on reopening it. There's something specific in the way Cubase handles resizing and scaling in that it wants to be in charge, even if the plugin handles scaling fine on its own. I did get this working on my old branch, but I haven't finished trying it out on Scream yet. I had to take a long break from coding, so I'm still refreshing my memory on this.

What did help me before was to enable all logging so that I could see exactly when the host and the plugin were requesting/performing resizing and scaling. These were happening in pretty different orders for different hosts, and in some cases (Reason) steps were being skipped completely. And I came to the same conclusion as you that Reason does best when you just feed it the system scale factor and leave it at that. Cubase is kind of the opposite, where you kind of have to let the host be the arbiter of what the source of truth is (or at least let it think it is or it will come back and bite you). I know you're aware of most of this already, but I remember there being an a-ha moment for Cubase specifically when I really started looking at this stuff.

Incidentally, Reason appears to be working ok!

[sadguitarius]

Ok here are some changes that enable things to work properly on my system (make sure you also pull my CPLUG submodule branch). Noteworthy changes are that the windowing library handles all scaling and the plugin GUI struct only stores normalized width and height that are then checked against the reference scale factor when needed. This may not be necessary, but at least for me this made it easier to think about what was happening with the various callback checks.

The window defaults to the scale factor supplied by the OS for the native window (satisfying Reason), and then defers to the host when it receives a scaling request. The first scaling request from the host resets the GUI scale to 1.0 so that Cubase isn't confused. I'm still not sure why Cubase is behaving properly for you, but I do think this method catches the specific weirdness between different DAWs as far as I can tell.

[Tremus]

I'm using a scale factor of 200% so that may be why you're not seeing this happen. All I'm doing is instantiating the plugin, opening the UI, resizing it, closing it, and observing that the size doubles on reopening it.

Sorry if I follow these steps I can't reproduce the problem even when using 200% scaling.

The first scaling request from the host resets the GUI scale to 1.0 so that Cubase isn't confused

Yep I'm seeing this same behaviour too in Cubase. Dunno if this is their bug or a hack to fix other buggy plugins?

What's the resolution of the monitor you're testing this on? Is it something 4k or greater? It could be possible Scream does something silly, scaling to really large min width/height on really large monitors inside PW_INFO_CONSTRAIN_SIZE. We already know Cubase does silly things like sending us bad content scales of 1, immediately followed by the real size of 2

Scream/src/gui.c

Lines 527 to 536 in 191dee3

	else if (info->type == PW_INFO_CONSTRAIN_SIZE)
	{
	GUI* gui = info->constrain_size.gui;
	uint32_t width = info->constrain_size.width;
	uint32_t height = info->constrain_size.height;
	float content_scale = xm_maxf(1, gui->layout.content_scale);
	uint32_t min_width = (uint32_t)(GUI_MIN_WIDTH * content_scale);
	uint32_t min_height = (uint32_t)(GUI_MIN_HEIGHT * content_scale);

[sadguitarius]

The first scaling request from the host resets the GUI scale to 1.0 so that Cubase isn't confused

Yep I'm seeing this same behaviour too in Cubase. Dunno if this is their bug or a hack to fix other buggy plugins?

What I mean is that in my proposed solution I also reset the scale to 1.0 first so that Cubase's assumption about the initial scaling being set to 1.0 is correct. But this has to be done only when the request to re-scale is received by the host, or it will mess up hosts like Reason that don't supply any of this information. But yeah I would call this a Cubase bug. I tried to keep all of this nonsense internal to the CPLUG windowing extension so that consumers of the library wouldn't have to worry about any of this.

What's the resolution of the monitor you're testing this on? Is it something 4k or greater? It could be possible Scream does something silly, scaling to really large min width/height on really large monitors inside PW_INFO_CONSTRAIN_SIZE. We already know Cubase does silly things like sending us bad content scales of 1, immediately followed by the real size of 2

3840 x 2160, nothing unusual. I have 2 other PCs I can check on. One has an AMD GPU, one Nvidia, and one just internal AMD graphics, so that should pick up any strangeness on the GPU end of things. Otherwise, I can't think of anything I'm doing that's unconventional like registry hacks or anything like that.