Naw, well, we were aware that vector graphics would solve the problem, but far too much processor power to do it and still like that. Also, I just made an image of the buttons in MMD you were talking about and was going to upload it. LOL. But yeah you get it.
Probably, but I believe at the time XMPlay was specifically about audio quality, speed and size with everything else being a secondary concern. We aren't hurting for for memory or speed much anymore of course but I quite like that XMPlay hasn't increased in size/usage exponentially like everything else seems to have.
It's more than a little ironic to me that I was very much against adding skinning to XMPlay in the first place back then. 
How do you guys do new skins so they scale better? Are there any modern skins that scale well?
Not really, the skins all use more or less the same mechanics as back then so they are static images without the ability to scale, there are skins that have been made for higher resolutions or come in multiple sizes (like Neutron for example) but many old extremely tiny skins would need to be revised a bit to fit common resolutions today.
Despite all that, the skinning method really is quite straight forward for most part and if there isn't one that fits your requirements you may find modifying an existing skin or even porting one from another player to be easier than you think.
I tried producing a script that would generate a skin at the "size" of my choice, and I got as far as a "proof of concept". i.e I could run the script and it produced a working skin, but I embedded all the data in the script, and the rules about the requirements for different elements in the UI are implicit. And I wrote it in vbScript, using the activeX interface to ImageMagick to produce the images. with netpbm to produce the mask BMPs in the required format.
I wanted a very simple skin, and tried to minimise the choices, but it still requires quite a lot of data to describe a skin.
Although I struggled with the scripting given my (lack of) ability, rather than try to improve the existing mess, I'd try to design a skin description that provides (or points to) all the information required.
The basic design is rows of "icons" packed from the left or right. My first thought was to use the ttf files of Google material icons (or the MS equivalent), but that didn't play well with ImageMagick, and is very hard to adjust. So I used the svg versions of the icons, and extracted the drawing instructions which are in effect in ImageMagick mvg format. The drawing instructions are adjusted to a basic 24x24 grid. That means the icons are monochrome, but I can change the foreground and background colour as I like, and scaling is simple to add. So I can queue drawing instrucions for the icons on the visible image and an appropriate matching boxes on the mask. And write alterntive icons in the appropriate size for the button and other bitmaps according to the requirements for that action.
Text boxes and sliders are currently fitted in in an entirely ad-hoc way. The title box and the position slider take all the unused space on their rows.
And so on. And it looks like the attached, which is very different to most skins.
So, I think that it could be possible to produce a skin description that would be scalable, with a script to perform the mechanics of skin generation.
One interim thought: Could XMplay read the screen dpi (usually, 96, 120, 144, 168 or 192) and load a skin with corresponding scale? e.g. if my skin choice is "NewandShiny", load it from NewandShiny.xmpskin unless dpi isn't 96 but 144, and there is a skin NewandShiny-144.xmpskin
Mike
