The recent updates to IGraphics which allow non-integer scale factors (i.e. changing the scale variables from int to float) have the side effect that the plugin UI gets automatically scaled if the user’s DPI is not equal to the default DPI of 96. The resizing occurs obligatorily during OnDisplayTimer, but it didn’t manifest itself before, since the DPI ratio of 120/96 on my machine was rounded down to 1., which was my intended scale factor.
I think this issue is known, since there’s a “TODO” comment above the relevant line, but I was wondering if there are any member variables of IGraphics that I can adjust in order to only trigger rescaling under certain circumstances (e.g. if the user manually enables it in in the plugin interface). For the moment, I’ve just sequestered the lines in an if (false) statement.
I don’t quite understand. Are you saying that before this change your UI was the correct size on your screen, where you have scaling set to 125% ? In that case I think you need to divide your PLUG_WIDTH and PLUG_HEIGHT by 1.25 and any pixel based coordinates similarly. You might be able to supply 0.8f as the fifth argument to MakeGraphics() as an alternative.
Prior to the new commits, the UI was (as far as I could tell) scaled 100%, whereas now it’s scaled 125%, even though the scale in MakeGraphics is 1.0, as evaluated by GetScaleForScreen. It’s possible that GetScaleForScreen was previously returning 0.8, but I never checked since everything looked normal.
Scaling down the default size would certainly return it to its initial dimensions, but I would expect the “default” scaling (if you don’t change anything from the examples) to give draw the plugin with exactly the same number of pixels (on the screen) as specified by the height and width macros. I’m using a bitmap background, and at a scale factor of 1.0, the plugin is exactly the same size as the background image when scaled to 100% in Photoshop.
Am I misunderstanding the intended default behavior?
I’ve checked this with my EndlessSeries plugin which has a bitmap background and it’s working as expected. If you want to send me an example in private to better explain the problem please do.
@olilarkin I sent you an email via your website last week with more details about this (apologies if that’s not the best mode of contact). No rush if you just haven’t gotten to that yet; I’ve dealt with the issue in any case.
Changing the UI dimensions completely screwed up the layout, but calling the resize function after setting the layout worked like a charm - and it would be easy to adapt that call to different DPI’s. So I don’t think there are any issues with the automatic scaling processes, as they just work differently than I would have expected. However, I do think that the bitmap scaling function which rounds mScreenScale up to the nearest integer (as I mentioned in my email) is a bug. It only occurs in the VST3 build (or at least not in the standalone app), and I can’t see any reason why rescaling a bitmap control should require rescaling the UI, much less to an integer value. I commented out that line and everything is displayed as normal.
I can post the example images that I sent you here, if you’d like, in case anyone else has noticed this issue.
Can you update us on this (including making sure you are trying the latest build?
If you can clearly demonstrate the problem we will fix it as it does sound like something might be wrong here. The best way to report issues is via Github as we can track them there, and people other than Oli might see them also. Thanks!
Sure, I’ll have to find the time to undo my bodges and test the latest commits, but I’ll hopefully get around to that in the next couple days and open an issue on Github if the problem still occurs.