Re: [PATCH RFC] dt-bindings: display: document display panel occlusions

["Piotr Masłowski" <piotr@maslowski.xyz>]

On Tue Oct 10, 2023 at 10:36 PM CEST, Caleb Connolly wrote:

>> So why am I writing all of this? Well, the problem I see is that any
>> shape-based approach will likely suffer from both accuracy and
>> complexity issues. Describing curves is hard and processing them is
>> not something that should be included in e.g. whatever handles VTs.
>
> My proposal here doesn't require processing curves or doing any
> complicated calculations. If you know that the display has a 30px radius
> on all corners, you can adjust the VT to not use the top 30px of the
> screen and it will start exactly where the radius stops.

Just a nitpick, but on a round smartwatch this approach will give you
a $width × 0px famebuffer ;D

>
> If you know that there is a (potentially very curvy) notch at the top of
> the screen, you can just iterate over the arcs, add their radius to
> their Y coordinate and take the maximum. This will always give you at
> least the height of the notch (you'd probably want to check that their
> angle is vaguely downward, but again this is trivial fast integer math).

Yeah, I was talking about curves in general. Your proposal is on the
low-complexity side thankfully.


>> - gathering the data is very straightforward – just light the relevant
>>   pixels one-by-one and check if you see them
>> - pixel-perfect accuracy is the default
>
> I think it would be fairly straightforward to do this for curve data
> too. You just bump the radius up/down until it looks right, or "good enough"

Well, different people will have different standards and what might be
good enough for some will annoy others. I'm not saying that we need to
be perfect at all cost, but if there's a relatively easy way to cut down
on inconsistency, it might be worth taking.

Additionally, having a very clear-cut quality indicator could remove a
whole class of bikeshedding options. (speaking of the devil xD)


The problem I have with curves is, the more 'correct' you make them, the
more convoluted they become. Like take for example the corners. Rounded
corners are circular right? But what if someone makes them 'squircular'?
Well, they are usually quite small anyway so maybe it will work out.

But then what about a smartwatch with big, squircle-shaped display? Bam,
now you need to complicate how corners are handled.

But also: are rounded coners typically circular? Just now I've thrown a
OnePlus 6 (thank you so much for the great mainline support btw!) onto a
flatbed scanner. While a circle fits decently well there it's not really
a perfect fit, so maybe they went with a different curve after all.

That being said, imperfection isn't my main issue with curves. It's all
the non-discreteness they bring to the table. As in, you now need to care
about approximations, rounding, imprecise measurements and so on.


> I think the unfortunate truth is that approximating notches and rounded
> corners exclusively with regular arcs at the cost of pixel accuracy is
> just such a no-brainer. Pixel masks would be pixel accurate, but there
> is no benefit compared to a slightly underfit curve.

Frankly, I don't see any significant cost here. It's very easy to gather
and rather easy to process.

Let me think about it… The most common operations I see people actually
doing with this data would be:

* letterboxing – easy with both curves and masks
* ensuring padding | margins for icons on the screen – with curves you
  can use a formula, but won't it be easier to just count pixels anyway?
* routing a spline along the border – like if you want to have some
  periodic pattern drawn there, it's probably a bit easier to do with
  curves
* drawing something at a constant distance from the border – with curves
  you can again use exact formulas. But isn't that an overkill really?
  I'd think most people will go for something like a morphological
  dilation instead

>
> Any program which wanted to make use of the curve information would have
> to run a whole curve fitting algorithm, whereas there simply aren't any
> programs which need to know about display occlusions to a pixel-accurate
> level. For padding a status bar you do a single trig equation, for
> avoiding the notch in fullscreen you would query the DRM subsystem which
> presumably would export the dimensions of a letterboxed "usable size".

What could the curve information be needed for though?
The more I think about it, the less value I see in it really. Like, if
you're adjusting the screen contents, pixels _are_ the smallest unit you
need to concern yourself with. The only thing that comes up to my mind
is if you were to animate the cutout shape somewhere else, zoomed in.
And thats already a quite contrived scenario.

Is there actually any use case that instead of ending up with pixels
either way, would be better served by a (possibly inaccurate) curve?
(future me here: that spline-along-the-border from earlier I guess)

--
Cheers,
Piotr Masłowski