Re: DPI in intel modesetting driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Le Jeu 4 janvier 2007 16:17, Adam Jackson a écrit :

> You are conflating two different things.
>
> The "DPI" setting used by Gnome for font sizing is a lie.  It has no
> actual relation to dots per inch of monitor.  The naming is unfortunate,
> but every time I ask Gnome people about it, the answer is "oh but people
> expect it to be called DPI", which is crap, but oh well.
>
> It is, in effect, a scale factor passed to Freetype when rendering.

That would be great if it was true ; unfortunately that's not a scaling
factor but an absolute value, so you get widely different effects
depending on the physical pixel density of the screen.

This is made clear by the following facts :

- no GNOME setup app allows setting Xorg displaysize when it's detected
wrong, GNOME dpi is used as an override. If they were actually separate in
GNOME people mind they would need separate setting

- OLPC has to dynamically adjust GNOME dpi when screen mode switches (but
the scaling preferences of the user didn't change!)

- as you noted most screens currently on the market actually have a
physical dpi value close to the GNOME default *when used at the ideal
resolution* - GNOME forces 96 independently of the actual screen
resolution, which sort of hides the problem if the user is lucky enough to
have a ~96dpi screen.

- users spend their time tweaking GNOME dpi when changing hardware, even
though their font scaling preferences didn't change. This is a disaster
for nfs homes.

The "scaling factor" is the excuse GNOME people have found to avoid fixing
this. "it's not a real value" => "we don't have to compute it correctly"

(its root is in the W3C virtual pixel=angle of view idea. But if you want
to pretend you're using virtual pixels, you have to use them both for text
and images. We all know GNOME uses actual hardware pixels not angles of
view for image sizing)

All the feedback I got on the subject before GNOME switched to denial mode
was that the "dpi" setting was initially developped as a bandaid because :
- xorg displaysize detection is not flawless (esp. then), and was
resulting in problems for anaconda, firstboot and gdm (before xorg setup
apps are run)
- fixing it at the xorg level requires writing xorg.conf as root, writing
a gconf key as normal user was easier
- when running at suboptimal resolution effective physical dpi is too low
to allow correct text rendering
- font hinting is optimized for 96dpi, so if you have a close-to-96
hardware dpi pretending to be 96 helps a little

Someone then noted setting the wrong dpi value in this gconf key had a
scaling side-effect and the bandaid was promoted to inspired feature.
Despite  the fact it falls appart as soon as the user has a screen with >
100dpi physical density (OLPC...), commutes between screens with different
densities (nfs homes, OLPC), uses a mix of GNOME (that use this setting)
and non-GNOME (that use xorg dpi) apps, etc

Renaming the GNOME key won't fix anything

-- 
Nicolas Mailhot

-- 
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux