Why EDID is not trustworthy for DPI
 

On Wed, Oct 05, 2011 at 01:34:43PM -0700, Adam Williamson wrote:

> I'm just saying it would probably pay off to put some thought *now* into
> how to manage things when higher resolution displays become so prevalent
> that they can't be ignored, rather than desperately scrambling to catch
> up when you eventually realize it's happened.

The likely outcome of higher density displays is that default font sizes
will get larger. It's a problem if and only if it's common to use
multiple displays of grossly different density, and fixing that problem
is impossible unless we have a huge number of technical advances that
nobody's even working on right now. It's worth thinking about. It's just
not something that we're anywhere near being able to implement, and as
such it's pretty unrelated to the original observation which is that
trusting EDID right now will just get you burned.

--
Matthew Garrett | mjg59@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Why EDID is not trustworthy for DPI
 

Matthew Garrett <mjg59@srcf.ucam.org> writes:

> We have no technological solution for dealing with the fact that
> applications may move from one DPI to another at runtime, and may even
> be displaying on both displays at once.

>From a technology viewpoint, that is actually theoretically easy to
handle on modern hardware: Render everything as 3D objects and let the
graphics hardware scale as appropriate.

To get it to look pretty you would need fairly high DPI monitors or
fancy scaling algorithms though. I can imagine that sub-pixel rendering
would be quite tricky to get right when DPI changes halfway through a
character.


/Benny

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Why EDID is not trustworthy for DPI
 

On Wed, Oct 05, 2011 at 11:11:38PM +0200, Benny Amorsen wrote:
> Matthew Garrett <mjg59@srcf.ucam.org> writes:
>
> > We have no technological solution for dealing with the fact that
> > applications may move from one DPI to another at runtime, and may even
> > be displaying on both displays at once.
>
> >From a technology viewpoint, that is actually theoretically easy to
> handle on modern hardware: Render everything as 3D objects and let the
> graphics hardware scale as appropriate.

This... works badly. Really. Open gimp and add some text. Now double the
size of the font. Save the image and open it in image viewer, and zoom
out so the text is half the size. It doesn't look the same as your
original text.

Rendering fonts (and even SVGs) well requires you to know the scale that
you're rendering to. More pixels mean you can add more detail. If you
shrink that then the additional detail is still there, getting in the
way of the actually important information. Doing this properly requires
that the original object renderer be part of the scaling process, and
doing that on the fly with reasonable performance just isn't part of our
rendering stack at the moment.

--
Matthew Garrett | mjg59@srcf.ucam.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Why EDID is not trustworthy for DPI
 

On Wed, 2011-10-05 at 23:11 +0200, Benny Amorsen wrote:
> Matthew Garrett <mjg59@srcf.ucam.org> writes:
>
> > We have no technological solution for dealing with the fact that
> > applications may move from one DPI to another at runtime, and may even
> > be displaying on both displays at once.
>
> >From a technology viewpoint, that is actually theoretically easy to
> handle on modern hardware: Render everything as 3D objects and let the
> graphics hardware scale as appropriate.

Your use of the word "theoretically" reveals much. You would almost
certainly be appalled by just how much geometry information is necessary
to render a single glyph. Which is why we - and Windows, and OSX -
don't do that. When you ask for a glyph at a given transformation
matrix, it gets rasterized down to an A8 mask, and we reuse those from
then on. (Okay, it's A8R8G8B8 if you're doing subpixel antialiasing).
That's the only way you get anything like acceptable performance.

If it were easy, we'd already be doing it.

- ajax
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Why EDID is not trustworthy for DPI
 

Dne 5.10.2011 21:56, Simo Sorce napsal(a):
> On Wed, 2011-10-05 at 12:49 -0700, Adam Williamson wrote:
>> On Wed, 2011-10-05 at 15:44 -0400, Simo Sorce wrote:
>>> On Wed, 2011-10-05 at 12:31 -0700, Adam Williamson wrote:
>>>> On Wed, 2011-10-05 at 18:49 +0100, Matthew Garrett wrote:
>>>>
>>>>> So, ok, now you have some belief about the DPI. But which DPI? If you're
>>>>> dual head, you've got two. Unless they match you're screwed - there's no
>>>>> magic way to get applications to reflow text just because you've moved
>>>>> the window between screens, and what would you do with a window that's
>>>>> halfway between? You can argue that this is a corner case and obviously
>>>>> yes it's a corner case but if you can't even pretend to fix the corner
>>>>> case then your solution isn't a solution any more than 96dpi is.
>>>> There's no _magic_ way to fix anything, no. Things get fixed by code
>>>> writers writing code. That would seem to be the obvious thing to do...
>>>>
>>>> Like I replied to ajax, I suspect when the problem of assuming
>>>> everything's 96dpi becomes simply too acute, instead of fixing
>>>> everything really properly so that all displays correct report their
>>>> size and all desktops actually do resolution independence perfectly so
>>>> it doesn't _matter_ if one of your displays is 98dpi and the other is
>>>> 215dpi, everything still looks perfect, the industry will just wind up
>>>> with a slightly more sophisticated bodge where we have a few 'standard'
>>>> resolutions and just figure out which one your displays are closest to.
>>>> But that's still going to require some kind of sensible handling of the
>>>> case where one monitor is roughly 100dpi and the other is roughly
>>>> 200dpi, unless we simply say 'you can't do that, all your displays have
>>>> to be in the same DPI Category'.
>>> Are you saying fonts should change on the fly when I move an app between
>>> 2 monitors that have different DPIs ?
>> If they're sufficiently different in DPI, sure. Or would you really want
>> everything to suddenly become twice as small if you were moving a window
>> from a 100dpi monitor to a 200dpi one?
> Are you also proposing to automatically resize all windows when you move
> them from one display to another ? There lies the road to disaster an
> pain imo.
>
> At least untill all rendering is done with something like svg and not
> with absolute pixel values this is just going to be a very bad
> experience.
>
> Simo.
>

Actually you should think about it in opposite way. Window will have
always the same size, e.g. 10x10 cm and who cares how many pixel it is?
Have you ever counted? Pixels are so ancient ...

Vit
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Why EDID is not trustworthy for DPI
 

Le Mer 5 octobre 2011 21:44, Simo Sorce a écrit :

> Are you saying fonts should change on the fly when I move an app between
> 2 monitors that have different DPIs ?

Unfortunately, when you get into situations with more than 150% difference in
pixel densities between displays (as we've been creeping towards in the last
decade) that's the only way to display text the user will be able to read.

You can check it now easily, just get a run-of-the-mill full-hd 15" laptop
(not even a tiny netbook), a run-of-the-mill 22" or more screen (nothing
especially uncommon either), create an extended desktop with both screens and
try to set a satisfying font size. I defy you to find a setting that won't
look way too small or way too big on one of the screens. And it won't matter
if the user likes small or big fonts.

--
Nicolas Mailhot

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Why EDID is not trustworthy for DPI
 

Le Mer 5 octobre 2011 21:56, Simo Sorce a écrit :

> At least untill all rendering is done with something like svg and not
> with absolute pixel values this is just going to be a very bad
> experience.

How is rendering ever going to go be done with something like svg when no one
bothers with the elements which have been available in vector formats since
last millenium? You have to start somewhere.

--
Nicolas Mailhot

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Why EDID is not trustworthy for DPI
 

Le Mer 5 octobre 2011 23:35, Matthew Garrett a écrit :

> This... works badly. Really. Open gimp and add some text. Now double the
> size of the font. Save the image and open it in image viewer, and zoom
> out so the text is half the size. It doesn't look the same as your
> original text.
>
> Rendering fonts (and even SVGs) well requires you to know the scale that
> you're rendering to. More pixels mean you can add more detail. If you
> shrink that then the additional detail is still there, getting in the
> way of the actually important information. Doing this properly requires
> that the original object renderer be part of the scaling process, and
> doing that on the fly with reasonable performance just isn't part of our
> rendering stack at the moment.

Which is exactly why forcing 96dpi on displays which have very different pixel
densities *today* is not a good idea at all.

--
Nicolas Mailhot

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Why EDID is not trustworthy for DPI
 

On Thu, 2011-10-06 at 13:06 +0200, Nicolas Mailhot wrote:
> Le Mer 5 octobre 2011 21:44, Simo Sorce a écrit :
>
> > Are you saying fonts should change on the fly when I move an app between
> > 2 monitors that have different DPIs ?
>
> Unfortunately, when you get into situations with more than 150% difference in
> pixel densities between displays (as we've been creeping towards in the last
> decade) that's the only way to display text the user will be able to read.
>
> You can check it now easily, just get a run-of-the-mill full-hd 15" laptop
> (not even a tiny netbook), a run-of-the-mill 22" or more screen (nothing
> especially uncommon either), create an extended desktop with both screens and
> try to set a satisfying font size. I defy you to find a setting that won't
> look way too small or way too big on one of the screens. And it won't matter
> if the user likes small or big fonts.

Nicolas I am aware of the issue, but I am also aware of the technical
difficulties in doing something like that.
It's not possible today and I am not sure it will be in the near future.

So currently the only option is to tell the user that we do not support
multiple displays where pixel density varies by moire than 10% between
them.

I would even go as far as saying that by default gnome should refuse to
let you join together screens of so high difference in density except we
cannot trust the HW info apparently, so all we are left with is a bad
user experience.

Simo.

--
Simo Sorce * Red Hat, Inc * New York

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Why EDID is not trustworthy for DPI
 

On Thu, 2011-10-06 at 13:13 +0200, Nicolas Mailhot wrote:
> Le Mer 5 octobre 2011 23:35, Matthew Garrett a écrit :
>
> > This... works badly. Really. Open gimp and add some text. Now double the
> > size of the font. Save the image and open it in image viewer, and zoom
> > out so the text is half the size. It doesn't look the same as your
> > original text.
> >
> > Rendering fonts (and even SVGs) well requires you to know the scale that
> > you're rendering to. More pixels mean you can add more detail. If you
> > shrink that then the additional detail is still there, getting in the
> > way of the actually important information. Doing this properly requires
> > that the original object renderer be part of the scaling process, and
> > doing that on the fly with reasonable performance just isn't part of our
> > rendering stack at the moment.
>
> Which is exactly why forcing 96dpi on displays which have very different pixel
> densities *today* is not a good idea at all.

Non sequitur.

Simo.

--
Simo Sorce * Red Hat, Inc * New York

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel