Closed Bug 524919 Opened 15 years ago Closed 14 years ago

Qt build of Firefox or Fennec does not respect my screen's DPI

Categories

(Core :: Graphics, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: bringbackbsd, Assigned: bringbackbsd)

Details

Attachments

(1 file, 2 obsolete files)

Whenever I run the Qt port of Firefox on my desktop or the Qt port of Fennec on my mobile device my specified screen DPI is not respected.  It is a more visible problem on the mobile device since the DPI is several times larger than for my desktop.

An easy way to see the problem is to build the Qt port and run it in a surrogate X server.  I use Xephyr, and with that I can specify my own DPI.
Flags: wanted-fennec1.0?
Attached patch A possible fix (obsolete) — Splinter Review
A possible fix, where the DPI is read from a QWidget.  Since QWidget derives from QPaintDevice the DPI values can be assumed from that.
Attachment #408808 - Flags: review?(mark.finkle)
Attached patch A more sensible fix (obsolete) — Splinter Review
This fix makes a distinction between GetDPI() and GetPlatformDPI(), and also reads the size information from the root window and not a widget.
Attachment #408808 - Attachment is obsolete: true
Attachment #414047 - Flags: review?(mark.finkle)
Attachment #408808 - Flags: review?(mark.finkle)
Comment on attachment 414047 [details] [diff] [review]
A more sensible fix

I recently landed bug 530931, which removed the "true" DPI usage and reverted back to "do what the platform tells us" approach. In that patch we:

* Removed PlatfromDPI as a separate method
* Made DPI just read from the platform and use the single value for system fonts and graphics

>diff --git a/gfx/thebes/public/gfxQtPlatform.h b/gfx/thebes/public

>     static PRInt32 GetPlatformDPI() {

GetPlatformDPI is gone now

> protected:
>+    static PRInt32 sPlatformDPI;

Also removed

>diff --git a/gfx/thebes/src/gfxQtPlatform.cpp b/gfx/thebes

>+PRInt32 gfxQtPlatform::sPlatformDPI = -1;

Gone

>+gfxQtPlatform::InitDisplayCaps()
>+{
>+    QDesktopWidget* rootWindow = qApp->desktop();
>+    // a more correct way to determine the screen's DPI is to use
>+    // sDPI = rootWindow->physicalDpiY();

You should actually use this approach now :(
(and yes, keep InitDisplayCaps)
Attachment #414047 - Flags: review?(mark.finkle) → review-
I opted for using logicalDpiY() instead of physicalDpiY() since it looks like it is intended for font sizing and nothing to do with the real screen pixel density.  This is analogous to gdk_screen_get_resolution(screen) in the GTK port in that it uses the value given by Xft.dpi.
Attachment #418990 - Flags: review?(mark.finkle)
Attachment #418990 - Flags: review?(mark.finkle) → review+
Assignee: nobody → bringbackbsd
Is it too late to ask for this to be applied to 1.9.2 too?
Flags: wanted-fennec1.0? → wanted1.9.2?
Comment on attachment 418990 [details] [diff] [review]
This is to calculate the font DPI, and nothing for the screen DPI

Requesting review from a gfx owner/peer, as mfinkle isn't one, according to http://www.mozilla.org/about/owners.html#graphics.
Attachment #418990 - Flags: superreview?(vladimir)
Keywords: checkin-needed
I have 2 monitor attached to my system. The main display has 1920x1200 px and 132 dpi. The second 1280x1024 px and 96 dpi.
If launch firefox on the first screen all is OK the screen dpi is correctly recognized.
On the second display, the dpi value is taken from screen 0 and not from screen 1. As well xrandr as xwininfo return correct value if I tell for which screen I want the value. The DISPLAY variable is set correctly :0.0 for the first screen and :0.1 for the second. The behaviour for getting the screen resolution seem not to be OK. On systems which are able to return the dimension of the screen or the dpi FF shall get the correct infos.
(In reply to comment #7)
Yep, that's a known problem.  I'm still trying to figure out what to do about that :o)
I think the Mac (OS X) implementation checks to see what monitor owns the the window. If the window is partially on a monitor - the monitor with the most part of the window "wins"
Attachment #418990 - Flags: superreview?(vladimir) → superreview+
Keywords: checkin-needed
(In reply to comment #7)
There are the following possibilities:
The dpi is taken fom the gconf database, this is wrong the dpi value is a system globale and the physical dpi will not match if the second monitor has different value.
Reading the value from Xft.dpiwill not be OK this is not a per screen value.
A query to X as or xdpyinfo return the correct value for example:
$ xdpyinfo  | grep reso
  resolution:    131x132 dots per inch
  resolution:    95x96 dots per inch

Some people may want a different behaviour, this can be a configuration option.
This patch doesn't apply anymore.
Keywords: checkin-needed
Attachment #414047 - Attachment is obsolete: true
Minor reject fixed:
http://hg.mozilla.org/mozilla-central/rev/ed9d9711eb8f
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.