many_buttons enhancements

[ickshonpe]

Objective

many_buttons enhancements:

• use argh to manage the commandline arguments like the other stress tests
• add an option to set the number of buttons
• add a grid layout option
• centre the grid properly
• use viewport coords for the layout's style constraints
• replace use of absolute positioning

includes the changes from #9636

Displaying an image isn't actually about stress testing image rendering. Without a second texture (the first is used by the text) the entire grid will be drawn in a single batch. The extra texture used by the image forces the renderer to break up the batches at every button displaying an image, where it has to switch between the font atlas texture and the image texture.

Solution

---

Changelog

many_buttons stress test example enhancements:

• uses argh to the manage the commandline arguments.
• New commandline args:
  • --help display info & list all commandline options
  • --buttons set the number of buttons.
  • --image-freq set the frequency of buttons displaying images
  • --grid use a grid layout
• style constraints are specified in viewport coords insead of percentage values
• margins and nested bundles are used to construct the layout, instead of absolute positioning
• the button grid centered in the window, the empty gap along the bottom and right is removed
• an image is drawn as the background to every Nth button where N is set using the --image-freq commandline option.

[alice-i-cecile]

The CLI interface looks nice :) And the enhancements will be useful for more precise benchmarking without exploding our set of stress tests.

[rparrett]

Some thoughts:

• Any particular reason to not be using the default window size here? The online examples page just looks nicer when everything is the same aspect ratio.
• What about using Display::Grid? Seems like the natural way to lay out a big ol' grid but I guess that changes the characteristics of the test a bit. edit: I see you added a grid option while I was reviewing.
• Basing border size and gaps between buttons on button dimensions effectively erases the borders/gaps with large amounts of buttons.

Here's a branch with Display::Grid and static borders / gutters / gaps if you want to experiment with it.

[ickshonpe]

Some thoughts:

• Any particular reason to not be using the default window size here? The online examples page just looks nicer when everything is the same aspect ratio.

Not really, with a square window you get square buttons but it doesn't matter. I hadn't considered the examples page, I'll change it to the default.

[ickshonpe]

Some thoughts:

• Any particular reason to not be using the default window size here? The online examples page just looks nicer when everything is the same aspect ratio.
• What about using Display::Grid? Seems like the natural way to lay out a big ol' grid but I guess that changes the characteristics of the test a bit. edit: I see you added a grid option while I was reviewing.
• Basing border size and gaps between buttons on button dimensions effectively erases the borders/gaps with large amounts of buttons.

Here's a branch with Display::Grid and static borders / gutters / gaps if you want to experiment with it.

Won't this do the opposite, will the buttons disappear with a lot of buttons?
The margins are slightly different between the grid and flex modes too, it'd be nice to fix that as well.
I guess I don't want to worry too much about the visual aspects and styling in this PR though and as it's primarily a benchmark it doesn't matter how it looks in the end.

Maybe it would be better to merge this as it is? The changes here (if not ideal) are a big improvement on main. Then you could create a second PR as I'm sure you know more about the grid layout model than me etc.

[rparrett]

Won't this do the opposite, will the buttons disappear with a lot of buttons?

Yeah, that's fair, especially at the particular sizes I chose.

I guess I don't want to worry too much about the visual aspects and styling in this PR though and as it's primarily a benchmark it doesn't matter how it looks in the end.

I had some vague notion that rendering zero-pixel-width geometry might have different performance characteristics but I doubt that is how it works or that it matters if it is. (and even at 100k buttons the borders are at least ~0.1 pixels)

Maybe it would be better to merge this as it is?

Not a blocker for me.

[rparrett]

The margins are slightly different between the grid and flex modes too, it'd be nice to fix that as well.

It might add some additional utility if those modes were producing identical output, but I am not completely convinced that's even possible. Might require a greater flexbox wizard than me.