HiDPI Resources

miqrogroove - 10-24-2026 at 06:58 PM

Here is my first attempt at making a button compatible with the Davis theme at 2x resolution.

The text color looks wrong, but I think I got the button gradient to nearly match the original.

flushedpancake - 10-25-2026 at 07:45 AM

Looks nice.

You can also recreate it in pure CSS, take a look. (AI telling me all these CSS properties I literally never knew about wth) :3

Attachment: davis button 2.htm (2kB)
This file has been downloaded 22 times

miqrogroove - 10-25-2026 at 01:10 PM

That's interesting. I will try both ways and compare.

HTML buttons have the obvious advantage of integrating with the translation system, while creating major challenges for compatibility with old themes.

flushedpancake - 10-26-2026 at 06:32 AM

Also means you can customise them a bit more flexibly IMO, e.g. if you wanted to add an additional effect when hovering over or clicking it. But yeah, the translation thing was the main part, given there's themes on this very website that have some of their buttons in Spanish lol (kubuntu-kde4 being one of them if I recall rightly)

Maybe, as a stopgap solution, add compatibility flags in the theme options for older themes until you're confident the functionality is worth completely removing from the codebase? Given you've been changing a lot of things, implementing lots of new stuff that might break or alter older styles, it might be worth doing a rundown while not letting old cruft bog down progress

For what it's worth, the BBCode toolbar buttons could also be handled using HTML/CSS buttons too. This also means they'd be far easier to extend later on.

miqrogroove - 10-26-2026 at 03:43 PM

Everything I changed so far is backward compatible. I've been careful about that.

Compatibility flags / feature support registration is a pattern that I kind of hate. It forces new themes to opt in to hard-to-find settings while maintaining a worse experience by default. There should be ways to avoid this. The button filenames were hard-coded in scripts until now, so we could simply check existence of reply.gif, for example, and when the theme is saved or imported then we set the flag automatically. That's just one idea.

Another idea: This type of button styling is theme-specific, so we could require opt in via a separate CSS resource like buttons.css, and if the theme provides that file we use that to set the flag automatically.

Third idea: Some folks might prefer to use image files for a custom theme. I think that's a strong reason to implement 2x image support even if we allow CSS buttons.

flushedpancake - 10-27-2026 at 06:55 AM

Quote: Originally posted by miqrogroove

Compatibility flags / feature support registration is a pattern that I kind of hate. It forces new themes to opt in to hard-to-find settings while maintaining a worse experience by default. There should be ways to avoid this. The button filenames were hard-coded in scripts until now, so we could simply check existence of reply.gif, for example, and when the theme is saved or imported then we set the flag automatically. That's just one idea.

Okay, yeah, this is probably the best way going forward.

I think in terms of the actual image check, we should filter it to check against several different file types (webp -> svg -> png -> gif being my preferred hierarchy top-down here). If none of these files exist, generate the button with raw HTML. For non-button entities that use images, the same thing can apply, except we could use fontawesome or something. GIF, naturally, was a choice that was mostly mandated due to Internet Explorer 6 lacking alpha transparency PNG support back in the day and IE6's subsequent pervasiveness until Windows XP went EOL.

I'd also recommend implementing something that can allow image-based buttons to be multi-language too, some sort of subdirectory scheme and subsequent directory checking. However, the main concern there is that the current translation system doesn't define both country/region and language codes, which might pose a problem with regional dialects, and falling back for these languages would prove even more difficult than necessary IMO. (Spanish, Portuguese and Chinese are probably the biggest examples of this I can think of.) -- perhaps the translation system, rather than the theme system, should be responsible for falling back to the nearest neighbour language installed on the board (which could actually greatly help with keeping translation files smaller for regional dialects, since they can then just inherit from an existing language)

Caching certain theme data locally every now and again (mostly just the actual contents of the theme folder) might be a good idea if such an implementation is going to go forward. Constantly re-iterating the check around these things all the time would just result in the server load going through the roof, and we want to keep things optimal

miqrogroove - 10-27-2026 at 02:09 PM

This is an interesting topic because XMB currently has no server-side caching whatsoever. We need to use MySQL storage for best compatibility, and at the same time we could add support for APCu whenever it's available. Then we would have the possibility of retrieving filenames from memory, while less frequent items such as the full stylesheet can be retrieved from the database.

This is also super useful for the settings table and the forums table, because those are queried for every request. These would require special treatment in Windows due to the way APCu works.

flushedpancake - 10-27-2026 at 03:24 PM

Combined with some fancy .htaccess header caching rules for ordinarily-unchanging, static elements like CSS/theme images, I imagine it could make page load times for both the server and the client even more efficient than they already are.

The search function and individual thread pages would also greatly benefit from query/result caching for what it's worth. I think I mentioned improving the actual results of the search before: try searching "the" in there, it's a complete... well, you get the idea.

Naturally, an option to purge the cache data would have to be added in the Admin Options.

miqrogroove - 10-28-2026 at 12:20 AM

These are my 7 favorite replacement fonts so far.

Most of these are 16 pt bold type with smoothing enabled. No kerning adjustments have been applied yet, so there's a chance of making them more narrow to match the original, but that's a choice.

miqrogroove - 10-28-2026 at 03:16 AM

How about this version?

Microsoft Sans Serif, kerning set to -25

miqrogroove - 10-28-2026 at 03:37 AM

This is Segoe UI, kerning -25. The character spacing is more consistent and it feels heavier than the original font.

miqrogroove - 10-28-2026 at 04:10 AM

For extra fun, here is Microsoft YahHei, 15 pt, kerning -30. All I can say is, it came with Windows, so I tried it.

flushedpancake - 10-28-2026 at 09:54 AM

That last one looks nice actually... Apparently for Latin characters, Microsoft YahHei uses a customised version of Segoe UI lol