Proposal: Increase OSD resolution

[DimitarKrastev]

Currently the OSD is too low resolution which looks unpleasent and is also a waste of screen realestate.

Proposed way to increase the resolution:

1. Reduce the FONT_WIDTH (36) FONT_HEIGHT (54) parameters by a given factor (ex by 2) to 18 and 27 respectively.
2. Instead of using OSD character X and Y coordinates as real coordinates for OSD characters use them as indexes where the real coordinate is the X,Y multiplied by the factor we set in step 1.

If we use a factor of 2 this would effectively quadruple the resolution and also double the horizontal text realestate. Where the text would have overlapped in the past it wont because for every character space on the line we will have 2 character space on our end to fit twice as much text per line.

Vertically the same number of lines will remain as we dont have the option to overflow the lines as we have with text.

Caveat: in the Flight Controlled OSD tab when configuring the OSD element position it will be a bit weird as seamingly overlapping elements might not overlap in our display in the goggles, but that is a small price to pay for this improvement. I think DJI originally implemented something similar (if not the same).

[bri3d]

This proposal makes sense, but if my understanding of "twice as much text" is correct, your proposal relies on the FC drawing all "elements" at once, as full strings.

If the FC splits up the drawing of an "element" into multiple draw calls for any reason, the appearance of the element will become garbled in this proposed model. For example, if the FC chooses to draw the battery consumed in one drawing call and the mAh glyph in a second drawing call, the mAh glyph will now be separated from the number.

Or, if the FC condenses the drawing of elements into fewer drawing calls, the whole screen will just appear compressed. iNav does this - now of course, iNav has HD mode, so it isn't an issue for now, but there's nothing to say another FC software won't start doing the same thing.

DJI don't have this problem, because each "element" in DJI land is a telemetry widget that's driven by data, rather than a set of glyphs drawn by the FC, so they can safely position the elements in whatever relative position they want. Really they squandered a lot of potential in the DJI system, they could have made very rich visual elements for each telemetry widget since they are not driven by text at all.

[benlumley]

FakeHD sort of solves this.