Proposal: Increase OSD resolution about msp-osd

[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.