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

[Piotr Masłowski]

On Wed Oct 11, 2023 at 1:35 AM CEST, Caleb Connolly wrote:
> On 10/10/2023 23:53, Piotr Masłowski wrote:

> They don't need to be correct, you don't need to complicate it, you just
> need a value that plays nice. When it comes down to it you're much more
> likely to be constrained by UI layout limitations by not being able to
> model the precise corner curves of your device. The difference between a
> circular and elliptical arc is negligible in all real world use cases.

Well, with a large, weirdly-shaped display the curve will have to pass
through more-or-less the right pixels for things like a-couple-px-thick
frame to look right. I would expect e.g. a smartwatch UI to sometimes
want to draw a constant-width frame along the screen border. Using a
significantly different curve there will break that, so you would need
to let them be similarly arbitrary to notches.


>> 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.
>
> My point is that actually you don't. Other than for animated visual
> effects (where an undersized curve would absolutely be acceptable) I
> can't conceive of a situation where plain triangles wouldn't be
> suitable, again slightly undersized of course.

Well, what I meant is not that you "have to care or it won't look good",
but rather "that's an unnecessary degree of freedom" and I'm sure pepole
will spend non-insignificant amounts of time caring about it. Both while
gathering the data and while processing it.

But you're right that it won't matter for typical corners – they are
simply too small to make any difference here.


>> Frankly, I don't see any significant cost here. It's very easy to gather
>> and rather easy to process.
>
> Unless I'm mistaken, it would mean that for "odd" shapes like rounded
> corners, the number of values you need to record would be directly
> proportional to the number of rows. You can do some optimisations, but
> that worst case is really not great. Especially when the arc
> approximation requires a single value and covers all the same usecases
> as well or better.

You mean the devicetrees getting bloated? The blobs are already dozens
of KiB in size. As for the sources, I don't have any real experience
with them so I'm not sure what would be the best way of representing
masks. Worst-case, they can be treated as raw bitmaps. But since the
features will consist of typically one (or just a few) contiguous blobs
they can be efficiently represented using for example chain codes.


> You'd probably want your status bar icons to be equi-distant from the
> top and side, at least that's what my Android phone does. But hey, maybe
> you don't, we can't bikeshed UX design all day but I'd think a simple
> radius is gonna be easier to deal with than a pixel mask in most cases
> (especially considering that most UI frameworks don't work in the pixel
> space anyway because of scaling).

Good point!
(Though don't they need to still align stuff to the pixel grid to avoid
needless antialiasing?)

Hmm, but known radius only helps you with the corners. For the notch,
you would need a complex (and shape-shifting) equation, so you might as
well figure out the constant-distance based on a mask I guess.


> GNOME doesn't even use real pixels, macOS doesn't use real pixels. When
> scaling comes into play the advantage is lost either way.

Fractional scaling is a worthwile cause, but I don't think my argument
really changes much when you're working with scaled pixels instead of
real ones.

>>
>> 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)
>
> I feel like the burden of proof still lies with you here. I feel much
> more comfortable with a handful of easy to reason about and explain
> values (that can be easily reviewed by maintainers) over a blob of data
> that grows with the resolution of your display.

How are these reviewable without testing them on a device though? True
that with corners a maintainer can make sure the values make some sense.
But for notches they can only try visualizing the data to see if it more
or less looks right. And that's equally true for pixel masks. Drawing
the shape by hand would be less tedious for a curve I guess.


Thanks for going over these things with me. It has definitely clarified
many points and gave me a better understanding overall. I guess we won't
convince each other that easily, so maybe let's see what others think.
(but if you want to discuss it further, I'm all ears)


And now that I think about it, maybe it's chain codes that could be the
best of both worlds? They operate on pixels and so remain exact, but
also are basically curves – just very simple ones. I'll have to think
this through.

--
Cheers,
Piotr Masłowski