[userbinator]

I like the fact that it's drawing the edges as vectors, just like how Windows itself renders classic style:

https://github.com/Baddaboo/ClassicKit/blob/master/Component...

IMHO much better than the trend of making every single UI element a huge bitmap image (in multiple resolutions), such that a simple app contains dozens of images of buttons and the like which consume more space than an entire Win95 installation...

[derefr]

I’m curious whether vector controls result in less or more GPU texture-memory usage, once you take into account that you need to render them as textures in order to get the compositor to work efficiently on them.

Raster images, after all, are usually loaded into VRAM by a library that converts them to some native packed texture format that are especially low-memory to hold and low-time-cost to render. Do baker vectors end up in the same format, or in the less efficient format used for expected-to-update pixel buffers (i.e. the format used for the renderings of compositable layers)?

[pcwalton]

It's pretty much the same either way, because vector images are always rasterized on CPU before being uploaded to GPU in popular OS stacks.

This may change with GPU rasterization of vectors (disclaimer: that's what I work on). I don't know of any major OS vendor that's actually publicly planning to ship this anytime soon though.

[derefr]

I mean, sure, they’re rasterized—but are they rasterized to the same native texture format as bitmaps are? I know that for assets in games, the “read-only” assets loaded from disk come with rasterization metadata (or are already transcoded to the native texture format, depending on architecture) such that you get more efficient VRAM consumption at the expense of loading time (this being why games can take so long to load a scene when GPUs have even more PCI-e lanes than NVMe memory does.)

Whereas I’d expect that texture-elements rendered during a scene, which might potentially stick around for only a few frames, would load to the GPU “uncompressed”, loading faster (less driver delay despite the increased size) but then taking more cycles of each texture-unit to process on each frame, thus taxing the GPU more.

I definitely know this was true back in the 90s in game consoles—data streamed from disk was optimized for the GPU; while compositing in data held as a raw pixel field in VRAM (because it was e.g. a minimap texture you were redrawing or somesuch) left much less GPU available for anything else to use.

[pcwalton]

I'm not aware of any mainstream UI toolkits that use texture compression for anything. Those compression formats are lossy, and UIs usually want to be pixel perfect.

[tinus_hn]

High DPI displays require pretty enormous icons to look good. And you can of course also cache the results of rendering a vector image at exactly the size you need.