Mir client API does not support non-square pixels

[Daniel van Vugt]

Mir client API does not support non-square pixels.

Non-square pixels do exist at least in modes like 640x400 which is historically CRT aspect 4:3. But also in a more modern sense if we were to ever do something really fancy like fullscreen subpixel rendering then the same issue might occur there too.

What we need is separate X and Y DPI values. Not just one (diagonal) DPI value:

int mir_surface_output_event_get_dpi(MirSurfaceOutputEvent const* ev);
int mir_surface_get_dpi(MirSurface* surface);

[Chris Halse Rogers (raof)]

The client API has all the information required to do this now - the ID of the output their surface is on, the current display mode, the current display orientation, and the physical size of the outputs.

(In hindsight, I think having the DPI in the SurfaceOutputEvent is a minor mistake - the value that clients should care about is scale - which they can't calculate themselves - not DPI, which they can. And don't use, because they're using scale ☺)

My expectation is that exactly zero clients would use the proposed API, and any client that did is not blocked on us providing this API.

[Daniel van Vugt (vanvugt)]

It's partly a matter of convenience and efficiency. If Mir can simply tell you rendering parameters like scale, subpixel order and DPI via a simple mechanism like SurfaceOutputEvent then that's preferable to the less simple alternative of enumerating physical displays in the client/toolkit.

More generally though, these values should be abstractable in future in that a client is not forced to optimize for a single physical output but rather optimize across a number of outputs.

If output A is HBGR and B is HRGB then a surface spanning both should probably choose greyscale/none subpixel ordering regardless of what output the surface is mostly on, because otherwise it will look so ugly on one of them that people will report rendering bugs.

If output C is 120Hz and D is 60Hz then the correct decision for a surface spanning both is to use 120Hz, regardless of what output the surface covers more of.

If output E is 4K but output F is only FHD then design have said for cloning they want a 4K image scaled down to FHD for F. A surface on this display now has 2 or more physical outputs' attributes to optimize for.

These are important decisions to visual quality we can solve trivially by using MirSurfaceOutputEvent with policy decided in the server. Alternatively we could let toolkits choose their own policy but that's:
  (a) More work - repeated per toolkit; and
  (b) Not yet possible since MirSurfaceOutputEvent incorrectly identifies just one physical output to optimize for whereas it needs to be returning a list of outputs that are used.

I did say this was a low priority enhancement, but it's certainly not invalid.

[Michał Sawicz (saviq)]

Syncing task from Mir.