> I think this would be one or two additional messages. But I'm actually confused by why you would do this because it seems like it would still cause performance issues, if you're now rendering every program two or more times every frame. I think you may want to save this for an "accuracy mode" or something, and normally have it so only the max DPI applies.
Some compositor/toolkit combinations today render at both 1x and 2x, or similar scales, if multi-monitor setups are used.
Now, to improve that situation, you’d need to render at each of the scales of the monitors the window is on right now instead.
To improve performance of that, sending a clip mask from compositor to toolkit to say "hey, only render the left half at 2x, right half at 1x" makes sense, if the toolkit decides to support it, that’d improve performance at no cost.
> or only support parts of it
What if the compositor sends the info about each monitor’s DPI, but doesn’t support the dpi-tagged buffers, instead only supporting viewport-tagged or integer-scale-tagged buffers?
Some compositor/toolkit combinations today render at both 1x and 2x, or similar scales, if multi-monitor setups are used.
Now, to improve that situation, you’d need to render at each of the scales of the monitors the window is on right now instead.
To improve performance of that, sending a clip mask from compositor to toolkit to say "hey, only render the left half at 2x, right half at 1x" makes sense, if the toolkit decides to support it, that’d improve performance at no cost.
> or only support parts of it
What if the compositor sends the info about each monitor’s DPI, but doesn’t support the dpi-tagged buffers, instead only supporting viewport-tagged or integer-scale-tagged buffers?