Hi guys, I am working on a WDL framework to improve GUI resizing. Currently I am working on my WDL fork which is basically WDL-OL + better GUI resizing.
There are a still some things to implement but you can test it now. I am interested in any feature requests, or discussion.
For test build: IPlugExamples/IPlugBetterGUIResize.
NOTE:
- It tries to be as simple as possible for plugin development.
- GUI scaling is automatic.
- There are 3 different types of resizing. See IPlugGUIResize.h
- It works with BITMAPS!
- GUI scale will be shared for all plugin instances.
- Window size will be stored in presets
Current test project uses bitmap oversample mode that will make bitmaps clearer when you scale up.
Original post --------------------------------------------------------------------------------------------
Hi guys,
here is alpha version of better gui resizing. It is still missing a lot of features, but these will be added in the next updates. For now I am interested how does it performs, is resizing too slow? If resizing is really slow than I could insert the code that will disable rescalling bitmaps while resizing and only rescale it when you finish resizing, but disadvantage will be that while resizing you will have black screen, or I could capture GUI at mouse down and rescale that bitmap while resizing, but this will show incorrect text size as text size is specified in ints so it will not scale smoothly. Please report any bug that you spot. I am aware of animated window resizing for AU and I still don't know how to turn it off.
Please test some of your projects that doesn't have vector graphics. Vector graphics support will come soon. For this to work you will need to add some sources to the mac targets.
Look at the picture: https://drive.google.com/file/d/0B1l...ew?usp=sharing
As you can see in IPlugBetterGUIResize example, the only thing you need to change is to load bitmap pointers instead of bitmaps, and to include on gui resize code.
I wish you happy resizing, and don't forget to comment!
1. Animated scrolling for AU.
2. Laggy resizing on windows.
CHANGELOG:
Code:
V1.21
IPlugControls is now updated to support scaling
V1.20
-Added size limits
-Added resizing by draging sides
-Code is now readable
V1.10
-Added so much things. I can't write it all here.
-Most important is that views and window resizing are now implemented.
V1.01
-Added bitmap oversample. Now you can use bitmaps
with higher resolution to have better look when you
resize up.
-Added fast bitmap resizing.
Great work. It's nice to see such an enhancement in the framework. I wonder if it is really a wanted behaviour that the knobs are also resized. So the knobs are getting really small with small window sizes. Better for me would be that knob sizes don't change but some of them are hidden/shown dynamically.
Great work. It's nice to see such an enhancement in the framework. I wonder if it is really a wanted behaviour that the knobs are also resized. So the knobs are getting really small with small window sizes. Better for me would be that knob sizes don't change but some of them are hidden/shown dynamically.
Thumbs up for your work!
Thanks! I am really glad that someone commented on this thread. I was getting feeling that no one cares and that is really demotivating, as I have spent 3 weeks working on this...
The plan is to have GUI that can automatically scale to any size for monitors with high resolution, and to have window that can be resized for many plugin views, for example mini view, normal, advanced etc. (This is what you want)
These features will come in the future (if someone cares...)
More important than the forks is that you are contributing something to the community here, and that's great.
Is it possible that you provide the compiled plug-ins of your example for win/mac to make testing easier? And would be great to have some text elements with different sizes and maybe a fader/switch in your example.
You are doing a great work, and I wonder if I should use it.
I am working [on Mac, OS X 10.9, Xcode 6.2] on a plugin which includes a graphical code editor, with a kind of whiteboard for designing algorithm. In "run" mode, the plugin has a small footprint, but in "edit" mode, I resize its window to show the whiteboard, and I use the IGraphics::Resize method for that.
While this is working to the perfection (well, most of the time), I have two problems :
- the IGraphics::Resize method deletes all controls with: mControls.Empty(true); while there is probably a good reason for that, which I don't yet fully understand, it is really a pain in the neck to manage the state of my 600 controls or so...
- the size of the plugin is fixed in the two modes (810 by 326 pixels, and 1282 by 910) which may not be convenient for all users.
Finally, I do not use bitmaps, but all controls are drawn with basic primitives such as DrawHorizontalLine, DrawVerticalLine, FillIRect, DrawArc, DrawCircle, FillCircle, FillRoundRect, DrawIText, etc.
As I understand, your approach does not imply that the controls are deleted, as with IGraphics::Resize. On the other hand, it does little in helping with my run/edit problem, since it doesn't change the layout of the plugin.
All in all, it seems that I would have a lot of code rewriting. What is your point of view ? Do you suggest that I have a deeper look to your code, or do you think it doesn't address my problem ?
Anyway, in a future design, I certainly will try to use it, since it looks like a very good approach and provides nice features.
You are doing a great work, and I wonder if I should use it.
I am working [on Mac, OS X 10.9, Xcode 6.2] on a plugin which includes a graphical code editor, with a kind of whiteboard for designing algorithm. In "run" mode, the plugin has a small footprint, but in "edit" mode, I resize its window to show the whiteboard, and I use the IGraphics::Resize method for that.
While this is working to the perfection (well, most of the time), I have two problems :
- the IGraphics::Resize method deletes all controls with: mControls.Empty(true); while there is probably a good reason for that, which I don't yet fully understand, it is really a pain in the neck to manage the state of my 600 controls or so...
- the size of the plugin is fixed in the two modes (810 by 326 pixels, and 1282 by 910) which may not be convenient for all users.
Finally, I do not use bitmaps, but all controls are drawn with basic primitives such as DrawHorizontalLine, DrawVerticalLine, FillIRect, DrawArc, DrawCircle, FillCircle, FillRoundRect, DrawIText, etc.
As I understand, your approach does not imply that the controls are deleted, as with IGraphics::Resize. On the other hand, it does little in helping with my run/edit problem, since it doesn't change the layout of the plugin.
All in all, it seems that I would have a lot of code rewriting. What is your point of view ? Do you suggest that I have a deeper look to your code, or do you think it doesn't address my problem ?
Anyway, in a future design, I certainly will try to use it, since it looks like a very good approach and provides nice features.
Jack.
Thanks! Don't use it for now in your projects that you are going to release to the public, because the this is still in alpha phase.
Don't bother too much about my code for now, many more features are comming, so stay tuned.
Don't worry about your project, this will be covered in one of the next updates.
More important than the forks is that you are contributing something to the community here, and that's great.
Is it possible that you provide the compiled plug-ins of your example for win/mac to make testing easier? And would be great to have some text elements with different sizes and maybe a fader/switch in your example.
I will add more elements soon. As for testing I think that it is better to build it your self and explore options that this branch will have. Currently I am mainly interested does this work on AAX because I can not test this...
New features added. Look at the changelog. Now GUI scalling is almost done. Next thing will be to have window resizing (that many of you actually want).
To be clear the GUI resizing will be implemented in 3 steps:
1. Setting view size - With this you will be able to set up for example mini view, advanced view where you will have more knobs etc.
2. Window resizing - This will resize window of different view. For example you could have mini view and on that mini view you will have some spectrum analyzer, now when you resize window you can make spectrum analyzer to be resized but the rest of controls won't be enlarged, and view won't jump to the advanced view.
3. GUI scaling - This will take everything you have done with the view and enlarge it. This is mainly for monitors with higher resolutions (retina etc.)
My main goal with all of these is to make it as automatic as possible, so that we don't have to worry about it when we develop the plugins...
When I have time I am going to study your work and integrate the functionality into WDL-OL. We need better resizing and retina support.
Thanks! Don't bother looking at it in detail yet because there are still a lot of features coming... When I finish implementing all features I will let you know...
I wanted to ask you do you know a way to execute some function after load. For example I want GUI to be resized after load (currently it is always resized at GUI open), and if call resize last in the main constructor this works for vst2 but not vst3... I am little bit stuck there.
Also one of disadvantage is that OnGUIOpen is called from audio thread in vst2 (and maybe other formats), but vst3 is called from GUI thread that I prefer for resizing GUI.
Anyways, I will look at these when I finish implementing all features.
I have been looking at your code, and I have a question about how to implement part of it.
In my plugin, I have different GUI layouts and sizes. I have been able to move all of the controls correctly, but the redrawing is not working. If I have a large layout and switch to a smaller layout, the larger layout is still displayed with the new smaller layout on top. The controls are working on the smaller layout, but I can't figure out how you managed to resize and redraw the GUI without the artifacts from the larger GUI.
I have been looking at your code, and I have a question about how to implement part of it.
In my plugin, I have different GUI layouts and sizes. I have been able to move all of the controls correctly, but the redrawing is not working. If I have a large layout and switch to a smaller layout, the larger layout is still displayed with the new smaller layout on top. The controls are working on the smaller layout, but I can't figure out how you managed to resize and redraw the GUI without the artifacts from the larger GUI.
...and many thanks for your work!
No problem!
So if understand correctly you have your own method for GUI resizing? If so, you are probably deleting controls on resize which my implementation avoids so looking at my code won't help you a lot...
Is it possible for you to share a screenshot/video (privately if you want)? This will help me to see what is actually going on...
Did you tried to call SetAllControlsDirty() after resize?
I just wanted to say that my graphics problem is fixed. Thanks for all the help.
So, your code changes IGraphics::Resize() by removing the following two lines
Code:
ReleaseMouseCapture();
mControls.Empty(true);
Just out of curiosity, what does the ReleaseMouseCapture() do that you needed to take it out?
No problem. Yes these are the changes. I am not deleting controls so mControls.Empty(true); must be deleted and ReleaseMouseCapture(); need to be deleted also because it is releasing mouse every time gui resizes and changing gui size by mouse dragging was not possible because of that.