My best recommendation is grid all the way. When I was using stack panel I too fell into the pixel trap. Now I’m in love with grid. If you want things like perfect padding in-between you can actually create a grid where you have blank cells between your content cells.
See what I did here in the color picker demo 
Babylon.js Gui Editor
Okay, thanks, I’ll def check that out for modeling the grid layout after, but the playground for it actually has the same issue of responding really well to horizontal resizing but not to vertical resizing. That’s another battle for tomorrow thou, thanks again. 
Hey @Blake just wanted to update you! I definitely am able to confirm this is a GUI issue. Even with Javascript as well. 
What seems to be happening is when you make changes once the GUI is already rendered. https://playground.babylonjs.com/#XCPP9Y#9484
Take a look at this demo. The alignment issues happens once you set the root property after the first render (in this case when you click the button) But then when it saves for example in the GUI editor I think something is reset so it corrects itself. Looks like an update issue but now we have all the repros.
Update! Ya I found the root line in the code, updated GitHub for the issue
Hmm, I keep coming back to this line in the Adaptive scaling section of the GUI documentation: “all values expressed in pixels are considered relatively to this resolution and scaled accordingly”, which makes it seem like the controls’ pixel values are converted to percentages for us if the ideal size is set IMO. If so, then it seems like a matter of preference wether to design in pixels or percents, if they’re being converted to percents any way. If I understand it correctly?
For instance, in JS if we the set AdvancedDynamicTexture’s ideal size to the same 1024 by 1024 square that we’re using in the GUI editor, then a control width of 102.4 pixels should be divided by 1024, leading to the same result as if we’d used 10% in the GUI editor instead of 102.4 pixels?
IDK, I might be misreading it thou, or maybe it’s more complicated… 
I think I get what you are saying?
Yes setting to ideal with and height will adjust your values to fit on the screen .An example I will give is this demo I made waay back in the earlier itterations of the editor. https://playground.babylonjs.com/#AJA7KA#8
If you look at it , nearly all the values are actually in pixels so when I brought it to the playground I had to renderAtIdealSize in order for it to look correct. What the system is not doing is taking your pixel value and converting it to a percentage. In fact is it not even changing your value at all as far as the control.left control.width etc. Even when the screen size is changing.
To me, if the pixel values are considered relative to the resolution, that seems to mean that they’re divided by the resolution (and then multiplied by the current, actual resolution). If not that part of the documentation doesn’t seem very clear to me.
I’m still trying different things to achieve a responsive GUI thou, I tried one with buttons that use percents for their width and height, with renderAtIdealSize and I tried with useSmallestIdeal instead too, but like all of the examples that I’ve looked at, it’s still not responding well to both horizontal and vertical resizing.
What is the visual result you are trying to achieve? That can help me understand what might be the best approach for this scenario.
Thanks, what I’m after is, if the window is resized either horizontally or vertically then, for example if it’s made smaller, then the controls’ width, height, position, and font all become smaller by the same factor so that they still fit on the screen and still fit in their containers and still have the same aspect ratio, ideally.
Responding to whichever dimension or dimension ratio is smaller usually works well I think, but I can’t seem to get it to workout well using Babylon GUI… 
So any more ideas to try or examples would be very appreciated.
This is just a related side note, but I think it’d be worth mentioning in the docs the pros and cons and use cases of an HTML/CSS GUI versus Babylon.js 2D GUI versus Babylon.js 3D GUI - sometimes I forget myself
That’s a good point, mostly I just wanted to try out using the new GUI editor on my next project, but will likely fall back on the Bootstrap CSS framework if I can’t get it working or if the responsive gui that I’m after isn’t supported, which I almost did a few times already even, because I can get that responding how I want much more readily, but will def come back to play with GUI editor more either way.
Update, I’ve found that a solution that works well for me is to not set idealWidth or idealHeight. Then on resize I can calculate the scale factor however I want and use it to resize the controls directly.
Doing it this way I end up using percents for everything except for a few outer containers that get resized manually in pixels, that way I don’t have to manually resize all the controls, just a few containers.
Have a demo you wanna show? If you think there are places we can improve on our documentation or offer additional perspectives I’d love to add it. 
The way I’m ending up handling it is to use the sum of the current window width and height divided by the sum of my design width and height (1400 by 700). Then it’s a matter of fine-tuning the minimum allowed ratio for each container (e.g. it’s different for the side toolbar and for the top menu) to get it looking reasonably how I want on various window dimensions.
It’s still a work in progress fine tuning it all, but if I can get it encapsulated into a more general purpose solution, ideally in a class, I’ll post a demo for it.
For the documentation thou, maybe at the end of the section on adaptive scaling there could be a little note/reminder that you can assume control of this by leaving both idealWidth and idealHeight unset and handling the desired resizing of the controls manually. That could maybe be helpful if others get stuck how I was or are wanting more custom resizing strategies and control over it, I think. IDK, it might already be clear enough thou, sometimes I get lost in the weeds LOL. 
That sounds good to me! Would you be able to make a PR for it? The documentation repo is here: BabylonJS/Documentation: Babylon.js’s documentation website (github.com)
@inteja we’d also welcome a writeup from you on the trade offs between different GUI approaches! Maybe it could go on this page: GUI | Babylon.js Documentation (babylonjs.com) Would you be willing to take a crack at it?
We can of course provide feedback for any documentation additions
Hi @DarraghBurke ,
Yes I could update the docs, although my question was a genuine one - sometimes I’m unsure what the pros and cons of each are, except for 3D gui where I know it’s needed for fullscreen and native VR where HTML GUI and Babylon 2D GUI won’t work.
So if anyone has some quick bullet points about the reletive merits of each, I’m happy to flesh out in the docs.
Here’s a start, if people want to add or suggest changes where I’ve got things wrong:
It’s also worth mentioning that these options aren’t mutually exclusive - they can be used together, depending on requirements, for instance:
Any other suggestions?
Here we go, I took a try at adding a little note about manual resizing to the adaptive scaling section.
Sounds good to me! @msDestiny14 could you take a look?
This is a great writeup! I can’t think of anything missing honestly, do you want to open a PR for it? Then maybe we can get a couple other Babylon contributors to take a look
Will be able to do this on the coming weekend.
