GUI elements taking on odd ratios when running i3 at high resolution

[MarcScott]

Using i3 WM at a resolution of 3840x2160. Screen shot at full screen:

Screen shot of floating window

[davidhoness]

I wonder if we need to make that a vector graphic as opposed to a raster?

[waveform80]

Actually it is a vector graphic in the source code, but the application uses a fixed size PNG rendering of the SVG. The main reason for making it fixed size is that old chestnut: performance. It's possible to make it a vector, but that then means re-rendering two SVGs (with transparency) on every resize and performing arbitrary resizing of the pixel buffer on every frame update.

So ... yes, it's possible, but either you special-case the vector rendering for fast machines only (Pi 3B might handle it - SVG rendering is seriously expensive) or you put up with a fixed size bitmap.

[davidhoness]

Yep, fair enough. I think performance trumps this, I wonder if rescaling the bitmap might work - I know it would look horrid though.

[waveform80]

The only resizing that I could get to work fast enough for 25fps on the little platforms was nearest neighbour - so, yeah, really horrid (the reason it doesn't look horrid on the output is that after blowing up the pixels we then overlay a semi-transparent PNG over the top to give them a bit of separation, but that's just fixed size pre-rendered and the compositing's handled by GDK so it's pretty fast).

Hmm, actually now you've got me wondering ... what if we rendered it at an excessively large size (using pre-rendered PNGs) and then down-sized with nearest neighbour. Might not be too bad ... I might give that a whirl a bit later (actually it'll probably have to be next week - got a bit too much on today and the weekend).

[waveform80]

Okay, this took rather more work than expected but I've managed it. Down-sizing is still too expensive, but I shifted things around so firstly the only re-sizing it does for each frame is of the pixel display itself; all other re-sizing is done on widget re-allocation only (i.e. we recalculate and cache down-scaled versions of the board image and grid overlay only when the window gets resized or the screen image widget is rotated).

It eats a bit more memory as a result (caches aren't free after all) but it's still within bounds on an A+ and still runs acceptably fast (with a few more tricks like using a secondary lookup table for the final RGB888 conversion I don't think there's any difference in runtime speed to old static-sized version). I'll push this in a mo, but for anyone that wants to try it: you'll need to install python3-gi-cairo (or python-gi-cairo) as an additional dependency.

[waveform80]

There we go, it's in #15 which is the resize-pixels branch if anyone wants to play with it.