! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
DPI problems


Description Yves-Alexis Perez editbugs 2008-09-10 08:27:32 CEST
Ok, I'll try to summarize here.

Using packages on http://mocha.foo-projects.org/~stephan/alpha/ I have DPI problems.

I have a SXGA+ (1400×1050) 14" screen, so my native DPI settings is 125.

If I let the default (use -1 in Xft/DPI property), I have various problems:

- gtk fonts are much tinyer than with “default” DPI in 4.4
- some fonts are not readable at all (in gecko, on xfce.org websites, see http://molly.corsac.net/~corsac/xfce/ and on apache folder listing)

If I run xfconf-query -c xsettings -p Xft/DPI -s 125, I end up with “48” in the “appearance settings” window, and fonts seem to look ok, at least in gtk

If I set 125 in “Appearance Settings” window, gtk font are *huge*.

So there is at least two problems (currently, but I can't say the correct svn revision I'm talking about :) ):

- non consistent settings between xfconf-query/xsettings.xml and the Appearance Settings window
- problems with some fonts (gecko but some others too I guess)

Plus the “scaling” stuff which look weird to me: why one needs to scale anything?

Comment 1 Yves-Alexis Perez editbugs 2008-09-10 12:52:20 CEST
(In reply to comment #0)

> - non consistent settings between xfconf-query/xsettings.xml and the Appearance
> Settings window

This *could* be related to non-consistend xfconf/xfce4-settings package. I'll retry tonight to rebuild both of them with latest packages on mocha.
Comment 2 Yves-Alexis Perez editbugs 2008-10-31 10:36:39 CET
FTR the GNOME bug is at http://bugzilla.gnome.org/show_bug.cgi?id=551634
Comment 3 David Mohr 2008-11-15 19:19:05 CET
We had a little debug session on irc about the font size problems.

Gecko workaround (from mr_pouit):
- In firefox, go to about:config and set layout.css.dpi to -1 (0 is th default)
- In devhelp, put the same setting in ~/.gnome2/devhelp/mozilla/Devhelp/prefs.js

Someone on #gtk+ suggested to jeromeg:
Put a breakpoint in gdk_pango_context_get_for_screen(), 
see what dpi is set there. That will tell you whether your issue 
is with Pango/Cairo or with XSettings/GTK+

and he also said "There's no halving. "0.5 + " is not "0.5 *"
And he basically said that they would not spend time debugging this...

I set a breakpoint for gdk_pango_context_get_for_screen() and launched devhelp. If I don't set my dpi, I get a resolution of -1, and the dpi value I put in the settings manager otherwise.

gdk_pango_context_get_for_screen() calls pango_cairo_context_set_resolution () with the dpi value. The docs say: "A 0 or negative value means to use the resolution from the font map"

So everything sounds ok, but nonetheless I get fonts with size 0 when my dpi is set to -1.

Interestingly I and mr_pouit just have this problem with gecko apps, while Corsac gets very differently sized fonts also in thunar and pidgin. If he doesn't set the dpi value, then his fonts become very small. See:

I wrote a little test app which checks what resolution gtk thinks is set:
Comment 4 David Mohr 2008-11-16 06:55:02 CET
Adding a little debugging output to gtk, I noticed that in gdk/x11/gdkxftdefaults.c, _gdk_x11_get_xft_setting () is never called with name having prefix "gtk-xft-". So init_xft_settings () is actually never executed, which could explain why it works when a specific dpi value is set.
Comment 5 David Mohr 2008-11-16 07:04:57 CET
(In reply to comment #4)
> Adding a little debugging output to gtk, I noticed that in
> gdk/x11/gdkxftdefaults.c, _gdk_x11_get_xft_setting () is never called with name
> having prefix "gtk-xft-". So init_xft_settings () is actually never executed,
> which could explain why it works when a specific dpi value is set.

For clarification, in 4.6 the init_xft_settings is _never_ executed, no matter if a custom dpi value is set or not.

I also tested:
In 4.4 with system default dpi settings, there is very early on a call to _gdk_x11_get_xft_setting with name=gtk-xft-dpi . I'm assuming the same happens when a custom dpi value is set (but I haven't tested it).

Why is this different from 4.6?
Comment 6 Yves-Alexis Perez editbugs 2009-01-25 21:03:38 CET
Ok, this bug is really nasty, nobody really know what happens, nor here nor on the GTK size. I don't really know how to debug this, so if nobody knows either or can point me to the right direction, it'll be in 4.6.0.

If it is the case, we will need to address this in the release notes, README or something like that, so users with high DPI display don't cry, saying Xfce 4.6 is crap.

(but it'd be better if we could find out what, in the end, causes the problem :/ )

I think it's a 4.6 blocker in either way.
Comment 7 Brian J. Tarricone (not reading bugmail) 2009-01-26 09:38:34 CET
No, we're not blocking 4.6 for this.

But perhaps we should add something evil to xfsettingsd to force Xft/DPI to the 'correct' value based on monitor size for the case that the setting is -1.  Stephan, what do you think?
Comment 8 Stephan Arts editbugs 2009-02-02 22:49:30 CET
*** Bug 4869 has been marked as a duplicate of this bug. ***
Comment 9 Yves-Alexis Perez editbugs 2009-02-09 10:12:22 CET
Ok, atm (rc1) when the “default” is selected, 96 is selected. I think it'd be better to try autodetection of X value and use that if possible. If not, fallback to 96. (and anyway display the value used, greyed, so that user know which DPI is effectively used).

It really seems that -1 is not a valid value in Xsettings, but until GTK+ guys answer us, we're stuck on this :/
Comment 10 Stephan Arts editbugs 2009-02-12 18:49:44 CET
When DPI == -1, Pango uses fontconfig to retrieve the DPI settings.

That this does not work right, is clear... But I don't know if this problem should be solved in Pango or fontconfig. (eg, use X11 instead of fontconfig, or let fontconfig return the correct DPI settings)

Either way, we should not hack around this in xfsettingsd and let the problem be solved where it is should be. Fontconfig and/or pango.

I will keep this bug around to remind me of the issue, but it won't be one which should be fixed in xfce code.
Comment 11 Olivier Fourdan editbugs 2009-02-17 12:56:39 CET
Created attachment 2175 
Proposed patch

The tricky part is obviously if you have a multiscreen layout, which
can screw up DPI calculation entirely,

But then, the idea of having one single DPI for the whole screen that
can be made up of different monitors with different DPI each is wrong
in the first place.

To avoid the problem, the patch takes the smallest DPI value in X and
Y. That will break if you have 2x2 multiscreen layout, but hey, we are
talking about sane defaults here, not fixing the issue for all and any
situation (this is why the setting is a settings, so ppl can adjust
for the corner cases!)
Comment 12 Yves-Alexis Perez editbugs 2009-02-17 13:00:36 CET
Wow, thanks
If it applies against rc1 I'm testing that tonight and report back asap.
Comment 13 Stephan Arts editbugs 2009-02-18 13:01:10 CET
I tested the patch, but made the following adjustments to make it work a little better (imo):

- Add a minimum DPI of '50' to the .glade file and a 'default' of 96.
- set the spinbutton value to 96 when the checkbox is toggled to active, this makes sure the DPI settings won't default to an unreadable 50. (or -1 when that was the old xfconf value, making 0 the first value that works when increasing the value)

What do you think? It is not perfect, but it makes the dialog better usable.
Comment 14 Yves-Alexis Perez editbugs 2009-02-22 12:55:52 CET
Ok, now that the patch has been committed, I guess we could close this one?
Comment 15 Stephan Arts editbugs 2009-02-23 08:52:52 CET
Sure :-)

Bug #4374

Reported by:
Yves-Alexis Perez
Reported on: 2008-09-10
Last modified on: 2009-07-14
Duplicates (1):
  • 4869 Firefox 3 not rendering any text


Stephan Arts
CC List:
3 users



Proposed patch (2.07 KB, patch)
2009-02-17 12:56 CET , Olivier Fourdan
no flags

Additional information