Closed Bug 426788 Opened 17 years ago Closed 15 years ago

When DPI set to 144, User interface is scretched very much. and html document is rendered very large.

Categories

(Core :: Graphics, defect, P2)

Product:
Core
Component:
Graphics
Platform:
x86
Windows XP
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
status1.9.2 --- beta1-fixed
status1.9.1 --- ?

People

(Reporter: ganadist, Assigned: mayhemer)

References

(
URL
)

Details

(Whiteboard: [read comments 9, 19, and 23 first])

Attachments

(1 file, 2 obsolete files)

v2.1 [Checkin comment 65] [Checkin comment 67]
(deleted), patch
roc
: review+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; ko; rv:1.9b5) Gecko/2008032620 Firefox/3.0b5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; ko; rv:1.9b5) Gecko/2008032620 Firefox/3.0b5

I'm using very large screen (52" TV), so I was changed DPI in display property, cause all text was rendered very tiny.

I was changed from 96 dpi to 144 dpi, and text size in most program is propered.

But, User interface in firefox was very growed up.



Reproducible: Always

Steps to Reproduce:
1. Open Display property and go to details, and change DPI to 144 (150%)
2. Reboot and Run firefox
3. Load any url and compare with IE



Please see this url.

http://ftp.mizi.com/~ganadist/ff3.png

http://ftp.mizi.com/~ganadist/ie7.png

Both screenshots are in same display setting.
dupe of bug 424375?
It seems similar, but bug 424375 is about html page only, not user interface.

I'll try with nightly build.
I tried with nightly build(08.04.06 trunk win32), but it always be crashed. so I can't check it.
Can this still be reproduced with a current nightly?

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/
I checked nightly build (Gecko/2008050906), and it seems to be resolved.

Thank you.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Resolution: FIXED → WORKSFORME
It reproduced in Firefox 3.0 rc2
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Firefox 3.0 RC2

I faced the same problem VISTA 150% DPI.
All menubar, toolbar, statusbar, htmlwebpage show very extreme big.

Now I move back to RC1.
Flags: blocking-firefox3?
See bug 394103, bug 434157, and bug 424822.
Component: OS Integration → GFX: Thebes
Flags: blocking-firefox3?
Product: Firefox → Core
QA Contact: os.integration → thebes
I have checked 3.0 RC2 and 3.0 RC3 and problem is visible in my PC too.
So bad, I have checked 3.0 RC3 problem still happen. 555 
still happens in 3.0
So sad... developer don't use 144dpi no one confirm this bug..
The scaling is supposed to happen, but only at 192dpi now. Are you really seeing this still with 144dpi? In 3.0 final?

Also, please read bug 394103. It's long, but it will give you an idea of why things are the way they are.
(In reply to comment #15)
> The scaling is supposed to happen, but only at 192dpi now.
>
That was changed between Beta 5 and RC1 in response to a Linux bug...

> Are you really
> seeing this still with 144dpi? In 3.0 final?
> 
...and was changed back for Windows and Mac between RC1 and RC2

> Also, please read bug 394103.
> 
And bug 434157 and bug 424822
Whiteboard: [see comment 9]
When release 3.0 final to public, peoples will come to this bug.
I hope someone (3rd party) will make a patch for us.

I have fonts 150% bigger (144dpi) for a 1680x1050 px.
Scaled user interface is a problem, not big, a little unconfortable: icons blur, eats display area.
But scaled web pages make me think about switching back to IE :(
For example with Joomla! docs UI scales every time i click on the tree class.
It seems that when i scale "Ctrl" + "+" 4 times the browser keeps track of this but Joomla! Framework docs is an AJAX application.
People complained when the scaling was not happening, and people are complaining now that the scaling is happening.  Bug 424822 would really help here by letting people have more control over that.  FWIW, this behavior here is consistent Beta 5.  Also, if you set your dpi to anything less than 144, you should be fine scaling-wise...
Status: UNCONFIRMED → NEW
Ever confirmed: true
On my system the scaling is not correct. I use 145dpi. So everything should be about 51% larger than on 96dpi. Instead everything is 100% larger. An image 500px wide becomes 1000px wide.

Confirmed on Windows XP Tablet PC Edition, Display Setting (in windows) of 145dpi. Firefox 3.0 (no RC).
^
^
layout.css.dpi not in windows.
From several threads in the FX support newsgroups:
- I and several others have confirmed the problem.
- It happens with (at least) XP SP3 and Vista SP1.
- It was introduced by some change that was made between 3RC1 and RC2.
- A setting of 149% (143 dpi) works fine, and is thus a pretty good workaround.
- Changing layout.css.dpi to 1 is a disaster: makes RX unusable and requires a manual edit of prefs.js to undo.
URL: http://support.mozilla.com/en-US/kb/T...
Whiteboard: [see comment 9] → [read comments 9, 19, and 23 first]
> A setting of 149% (143 dpi) works fine.
> and is thus a pretty good workaround.

Very good Idea. Thank!!!!
With Windows xp pro sp3 display dpi set to 150% (144dpi) the firefox 3 normal and safe mode display of icons and web pages is huge and grossly out of proportion to those delivered by firefox 2, IE 7 and any other application with 144 dpi set. 
As Firefox 3 seems to break at a dpi of 144, you can change the dpi within the program (instead of in Windows) to a dpi of 143.  Goto about:config and add a integer value called 'layout.css.dpi' and set it to 143.  Fixes both the stuffed GUI and website rendering issues.
(In reply to comment #28)
> As Firefox 3 seems to break at a dpi of 144, you can change the dpi within the
> program (instead of in Windows) to a dpi of 143.  Goto about:config and add a
> integer value called 'layout.css.dpi' and set it to 143.  Fixes both the
> stuffed GUI and website rendering issues.

It's the good solution ! Thank you very much !!!
Carrying over a blocking nomination from a duplicate. Not sure if this must be fixed for 3.1, but it needs to be on the graphics radar (or the bugs listed in comment #9 which propose a fix for the underlying issue do, anyway)
Flags: blocking1.9.1?
We may be trying too hard to do the correct thing here, which apparently is not what users expect.  Don't want to touch it for 1.9.1, but we should figure it out for 1.9.2.
Flags: blocking1.9.2+
Flags: blocking1.9.1?
Flags: blocking1.9.1-
Blocks: 433664
I too had the same problem on Firefox 3.0.5 on Windows XP SP3 (with a Windows DPI setting of 150%) as described here, and adding "layout.css.dpi" via about:config and setting it to either 1 or 96 makes the screen appear readable.  

I suspect that part of the problem is that when Windows' display settings say "150% of normal size (144 dpi)" they actually just mean that everything on screen is scaled to 150% of what it would otherwise have been - and it appears that FF 3 then applies that 150% again when reading the setting.  The "144dpi" bit just means 1.5 * 96.

Being able to scale the whole user interface is actually a really useful feature that I wish many other applications had, but having to do so via layout.css.dpi isn't a friendly way to do it - especially when the key isn't present by default in Windows FF installations.

Is it described anywhere what the rules that are applied to a user-supplied layout.css.dpi value actually are?  It seems odd that setting it to "1" has the same effect as "96", and (as described above but not tested by me) that 143 has such a different effect to 144.  Presumably there's some sanity-checking of user-entered values but it would be nice to know what these were.

So:
o Not applying the 150% on Windows would fix the reported "too big" problem.
o Being able to easily scale the whole UI without having to add the key would be nice (and also a workaround to the "too big" problem)

Just my 2p - apologies if what I've said (or what I've asked for) is duplicated elsewhere.
I was wrong - setting it to "1" does not have the same effect as "96".  On some pages (such as those from the Nagios network monitor - search for "Service Overview For All Host Groups" to find some) "1" makes text unreadably small, whereas on others (this bugzilla page) it doesn't.

I did find:
http://kb.mozillazine.org/Layout.css.dpi
but it seems inaccurate (it says "This preference has no effect in Windows").
I suggest that dpi should never be used for scaling of the UI as it does not correctly represent what the user is trying to change. I experienced problems related to this about 5 years ago in Mozilla on Linux when we were displaying web browser on CRT TVs.  800x600 on a 24inch TV (4:3) which works out to be about 42dpi.
The reporter of this bug said the tv is 52" (assuming HDTV 16:9 1920×1080) which again calculates to be about 42dpi.

By increasing the dpi as the reporter has, seems to be the reverse of what I would expect. I assume this is because viewing distance is not taken into consideration. Instead a 'perceived dpi' is used rather than the dpi of the screen.

I am therefore thinking that dpi should be avoided and instead just offer a default scaling for the UI.  I love the latest zoom functionality on the browser content and I assume the same could be applied to the chrome?

The other option (which is what we did 5 years ago) is to use an alternative chrome designed for big screen TVs. Perhaps this could be included by default as more people are connecting their PC to their big TVs these days.
No offense, but i think this is due to a misunderstanding what dpi actually means.

If i set my notebook's dpi to 145dpi, then because things like Adobe reader then has an almost-correct 100&-view. (i.e. a 21cm wide pdf in 100% view will be 21cm if i'd take a real ruler and put it against my screen).

and this is also what i'm trying to achieve when viewing web-pages. I want pages, which are (as an example) created for 1000px width to display as ~51% larger -> around 1500px wide.

Which then would be around the same visible size as 96dpi on my 24" Monitor at home. In the end dpi is exactly that: its dots per inch (more accurately pixels per inch) - it's a constant used to derive a real-world measurement (inches) from a virtual measurement (pixels).

So coming back to the last comment:
> I suggest that dpi should never be used for scaling 
> of the UI as it does not correctly represent what 
> the user is trying to change.

This is a very bad idea. Dpi is a physical constant of a display. In my case my display has a very high dpi and i DO want my UI-elements to scale. If it's important to people to have tiny UI but large content-display, then give them a checkbox in settings "dont scale UI according to dpi setting" people who set their dpi physically correct whill know what that means. Also: only offer it to those which do not have the standard-value set. So you don't confuse anyone.
No offense taken.
I understand that with a high dpi display (like yours) you would want your items to scale, but the reporter is using a low dpi display (TV) and also wanting the items to scale larger.

The reporter is trying to take a 42dpi display and scale it up to 144dpi.. in a way that is a 350% increase but this is about right since you are sitting 3-5 meters from your screen.

How wide should a 21cm width pdf in 100% view be when viewed on a large tv?  If the dpi is set correctly to the dpi of the tv then it should also be actually 21cm but of course then it is impossible to read from the sofa.

Sorry if I'm getting this bug off track but I am also trying to say that relying just on the system dpi setting does not necessarily do what the user wants it to do.
It sounds to me that this bug wouldn't affect users like the previous commenter with high res screens because you are wanting everything to scale (UI and content) which was my point. Large TV screen users expect something different to happen so I can't think of an alternative but to have the user able to set the scaling for each independently.
I am totally with you on this one:
Having a Zooming-Factor is a good idea (for both content and UI)! I just meant to point out, that it should not be achieved via (mis-)use of the dpi-setting.

Even though both do the same thing (scaling the representation), they are very different from each other.

So why not have two numbers dpi and zoom_factor - one of which can be easily set with a slider in settings.

The difference would also be in CSS: if i design something to be 1cm (instead of saying it's 25px) then i want this value to be affected by the dpi-setting, thus being rendered 1cm on any (correctly set) screen. If the user, however, applies 350% zooming (for example for the TV) then this will render as 3.5 cm.

This would be (from my point of view, at least), be the ideal scenario.
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2a1pre) Gecko/20090127 Minefield/3.2a1pre

I have screen resolution 1920 x 1200 and when I set 144 DPI I still need to use page zoom. After zooming in 3x the page text doesn't have by far the same quality as Internet Explorer 8.
144 DPI doesn't seem to do much here, only the text on the toolbars, tabs and in menus is increased; the icons (favicons, toolbar and statusbar icons) are still tiny.
(In reply to comment #42)
> After zooming in 3x the page text doesn't have by far the same
> quality as Internet Explorer 8.

Please ignore this part of comment 42 because the comparison wasn't right, this may be due to some minimum font-size specified which can give indeed ugly zoom results.
For controls, setting dpi effects UI icons scaling only by factor of 2, 3 etc. NOT by fractions like 1.5 (one and one half).

For HTML rendered content we apparently do absolutely the same.

We probably round in a wrong way the relative value for scaling on some place of the code (I'm not expert to it).
Attached patch v1 (obsolete) (deleted) — — Splinter Review 
I'd say it's regression from bug 177805. See https://bugzilla.mozilla.org/attachment.cgi?id=254518&action=diff#mozilla/gfx/src/thebes/nsThebesDeviceContext.cpp_sec1 where we count (dpi + 48) / 96 as a factor to divide unit per CSS pixel. It rounds to 1,2,3,4 etc.

This should fix it. My local test confirm it.

Question is, if this won't break printing.
Assignee: nobody → honzab.moz
Status: NEW → ASSIGNED
Attachment #394867 - Flags: review?(roc)
(In reply to comment #48)
> Question is, if this won't break printing.

Someone should check bug 177805 comment 121.
This is a pretty huge change in behaviour. In fact I think it's going to cause problems because it means that anyone whose dpi is not *exactly* 96 is going to start getting all their images scaled in UI and Web content, and that's a really big performance hit.
In other words, the behaviour in bug 177805 was deliberate and any change has broad implications and should be discussed somewhere like mozilla.dev.platform. I'll start a thread there.
FWIW, I'm having an issue where the UI scales properly based on my Gnome Font DPI settings, but web content is not scaled at all.  Web content is rendered at 96 dpi which is extremely difficult to see on my 15.4-inch diagonal WUXGA+ (1920x1200) laptop display.  Setting layout.css.dpi to the next bump up (>192) causes everything to be way too large.

I'm finding myself in a "goldilocks" situation where I want to be able to disable the multiple-of-96 equation and just use the dpi value I specify.  Then I'll have a dpi value that is "just right" for my computer.

I've logged bug 512522 for my issue since it's slightly different.
My proposal to solve the whole dpi issue would be a two-steps process:

1) For the short term:
bug 426788 is affecting Windows users who have set their dpi setting to 144.

What we could do for solving this specific issue is to use the same formula that is used on GTK for computing mAppUnitsPerDevNotScaledPixel on Windows.
in nsThebesDeviceContext.cpp:

Use this for both Windows and GTK:
PRUint32 roundedDPIScaleFactor = dpi/96;

That means that a user with a dpi setting of 144 will still use a 1 device pixel per css pixel and won't see a UI scaled by 2x (which is too big).

2) For the longer term:

Do something like http://groups.google.com/group/mozilla.dev.platform/msg/080fce3c042ef48d

This has several dependencies:
 - compute the the number of device pixels per CSS as proposed in 1) above.
 - set layout.css.devPixelsPerPx to 1 only for Linux.
 - provide a high DPI theme on Windows (and Mac if they implement RI in the future).
 - Have the app adjust the default fullzoom level to do what's proposed in the link.
 - Have a UI for going to 100% zoom level or for setting 100% level as a default for content (see http://groups.google.com/group/mozilla.dev.usability/browse_thread/thread/90cb8fc382574b90).

There's another small issue on Linux with this proposal: The size of the fonts used in <select> form elements depend on the OS dpi setting, which means they appear bigger than other fonts used in content (see attachment 396511 [details]). In this case, we should deal differently with font size of <select> form elements in content on Linux.
Priority: -- → P2
Attached patch v2 (obsolete) (deleted) — — Splinter Review 
Sylvain, this is version based on your suggestion. It simply fixes this bug, no scaling for small dpi changes (no performance/other issues).
Attachment #394867 - Attachment is obsolete: true
Attachment #403279 - Flags: review?(sylvain.pasche)
Attachment #394867 - Flags: review?(roc)
Comment on attachment 403279 [details] [diff] [review]
v2

Looks good. However the comment above should be updated to mention that we now do a round down instead of a round to nearest.

r=me with that.
Attachment #403279 - Flags: review?(sylvain.pasche) → review+
Same as v2, just the comment updated as suggested.
Attachment #403279 - Attachment is obsolete: true
Attachment #403470 - Flags: review+
Comment on attachment 403470 [details] [diff] [review]
v2.1 [Checkin comment 65] [Checkin comment 67]

http://hg.mozilla.org/mozilla-central/rev/77ff421d613d
Attachment #403470 - Attachment description: v2.1 → v2.1 [Checkin comment 58]
Status: ASSIGNED → RESOLVED
Closed: 17 years ago → 15 years ago
status1.9.1: --- → ?
Resolution: --- → FIXED
Reopened due to build bustage on mac.

http://hg.mozilla.org/mozilla-central/rev/656089bd4c44

Log for reference:
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox-Unittest/1254233064.1254236943.20805.gz&fulltext=1
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Attachment #403470 - Attachment description: v2.1 [Checkin comment 58] → v2.1 [Checkin comment 58][Backout comment 59]
Just a note that the patch passed the try server run on all platforms w/o any
failure. Could the failure after I have landed be some random one?
I wouldn't expect this patch to cause focus problems.
If the failure only happened on one unittest run, then I suggest trying to land it again.
Comment on attachment 403470 [details] [diff] [review]
v2.1 [Checkin comment 65] [Checkin comment 67]

Roc, could you please take a look at this patch again? It seems that failure on mac after landing was just some random one.
Attachment #403470 - Flags: review+ → review?(roc)
Comment on attachment 403470 [details] [diff] [review]
v2.1 [Checkin comment 65] [Checkin comment 67]

I'm sure the failure was random, but you can push to the try servers just to check
Attachment #403470 - Flags: review?(roc) → review+
(In reply to comment #63)
> but you can push to the try servers just to check
I already did, see comment 60. it completely passed.
Status: REOPENED → ASSIGNED
Comment on attachment 403470 [details] [diff] [review]
v2.1 [Checkin comment 65] [Checkin comment 67]

http://hg.mozilla.org/mozilla-central/rev/409b7a524085

Re-landed on m-c
Attachment #403470 - Attachment description: v2.1 [Checkin comment 58][Backout comment 59] → v2.1 [Checkin comment 65]
Status: ASSIGNED → RESOLVED
Closed: 15 years ago → 15 years ago
Resolution: --- → FIXED
In the future, could you please make your commit messages describe the fix?  Instead of:

  Bug 426788 - When DPI set to 144, User interface is scretched very much. and html document is rendered very large, r=roc

it would have been better to write:

  Bug 426788 - Determine number of device pixels per CSS pixel by rounding DPI/96 down rather than to nearest integer.  r=roc
Comment on attachment 403470 [details] [diff] [review]
v2.1 [Checkin comment 65] [Checkin comment 67]

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/88dde0088a21
Attachment #403470 - Attachment description: v2.1 [Checkin comment 65] → v2.1 [Checkin comment 65] [Checkin comment 67]
status1.9.2: --- → beta1-fixed
I've just encountered the same problem (large interface fonts, large icons, large web pages) in Firefox 22 (currently beta) on Windows XP with “large fonts (125%, 120dpi)” in its display settings.

(“Help”→“Restart with Add-ons Disabled…” was not helpful, so that's not an addon effect.)

I had to hit “Ctrl” and “−” on each web page twice to return them to normal. I eventually grew tired of it and downgraded to Firefox 21 (current release) as a remedy.
This "fix" was effectively turned to support High-DPI display. Set "layout.css.devPixelsPerPx" value to 1.0 via about:config.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: