Closed Bug 394103 Opened 17 years ago Closed 16 years ago

All elements are HUGE (when doing dpi autodetect?)

Categories

(Core :: Graphics, defect, P2)

Product:
Core
Component:
Graphics
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.9

People

(Reporter: jdub, Assigned: asac)

References

Details

Attachments

(6 files)

Comparison of aspect between FF2, FF3 and a normal Gnome Window
296.39 KB, image/jpeg
Details
option 1: don't scale images
1.86 KB, patch
Details | Diff | Splinter Review
option 2: scale for 192+ dpi
1.30 KB, patch
roc
: review+
roc
: superreview+
mtschrep
: approval1.9+
Details | Diff | Splinter Review
Huge form elements in print preview
75.75 KB, image/png
Details
Still the same bug on Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008041004 Minefield/3.0pre
84.10 KB, image/png
Details
Text misalignment on FF3 (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008041004 Minefield/3.0pre)
105.46 KB, image/jpeg
Details 
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a8pre) Gecko/2007082404 Minefield/3.0a8pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a8pre) Gecko/2007082404 Minefield/3.0a8pre

Almost all elements (text, images, forms, chrome, but not chrome labels) are massive in this nightly. It's the first one I have tested. Here are some screenshots, taken with a fresh profile:

http://www.gnome.org/~jdub/2007/minefield-create-profile.png
http://www.gnome.org/~jdub/2007/minefield-first-run.png

layout.css.dpi is set to -1, and my X server reports ~180dpi (which is correct, given my 24" 1920x1200 screen). Here's xdpyinfo, if it's useful:

http://www.gnome.org/~jdub/2007/minefield-xdpyinfo.txt

Reproducible: Always
Oh, just tested: I set layout.css.dpi to 96, and everything looks normal. :-)
180dpi sounds way off; I think your screen is closer to 96dpi.  (If I'm calculating right, the screen is about 20"x13", and 1920/20 is 96 dpi.)  You should fix your x config to return the correct dpi.

The scaling is intentional; we might have to turn it off if too many people have misconfigured computers, though... although this is the first case I've heard of dpi accidentally configured to be too high.
Just saw someone on IRC using debian that hit this bug
Status: UNCONFIRMED → NEW
Ever confirmed: true
Ryan and I have both hit this at one point or another.
We might need to turn off dpi autodetection for Linux and set it to 96dpi if that is what fixes this issue.
Flags: blocking-firefox3?
Of course if we don't fix it our end then it pressures distributions to fix X to Do The Right Thing, which might be more desirable...
There are high dpi screens (for example 330mm x 207mm 1650x1080) which will have really tiny UI if dpi is forced to 96; AFAIK, gnome and gtk also honor the dpi setting, and it seems that lately gdm no longer passes -dpi 96 to X (I have a screen that advertize wrong size and I needed to set its size in Xorg after a recent update to avoid a "75 dpi" setting in all gnome)
My screen is 147dpi:
  dimensions:    1920x1200 pixels (331x207 millimeters)
  resolution:    147x147 dots per inch

But I still preffer setting dpi 96!!!
- On my case (3.0b3-pre) the size is multiplied by 4x in each direction (instead of 2x 147/2=73 ~= 96 dpi)
- The icons look ugly. If you want to *really* support high dpi screens a new set of icons with hight resolution should be created.
- The rest of gnome windows are different size. If you need higher size in a high dpi screen you should just search for the proper "big" GTK theme and increase the size of text in GTK. That's the way to go, not just zooming the interface.
- Page zoom is something that could be useful, but I still prefer setting manually 96 dpi (I bought this screen to have more screen state). This should be choosable by the user. Perhaps an alert for the first use:
You screen has very high resolution and the pages will be shown tiny (XX% the normal size on other screens). You can enable a default page zoom adequate to you screen in the preferences settings.
Why isn't the setting in gnome settings honored? Being forced to set the DPI in several places is not very good design...
Mikael: Everybody should obey the dpi setting of X. Until recently, on my distro, gdm forced X to advertize 96dpi (via command line, it is possible to do it also via xorg.conf). Now it seems to calculate it using the advertized real size of the screen (in millimeters).

Guille: Your system should advertize the correct DPI; if it's wrong it's like when you skew your temp meters because they show a low temp, instead of turning up the heat. A correct DPI is needed if you want to get the correct zoom factor in print preview, or more simply to get 10pt fonts that really span 10pt (the point is an absolute metric like inches, not relative to pixels). You can still tell X that it should ignore whatever sizes are advertised by your hardware and set dpi to 96, if you really want so, but it basically amounts to redefining the inch or the centimeter on your screen. I you want a smaller UI and smaller system fonts, you should change the corresponding setting; nowadays, with the advent of vector graphics and themes, the UI gracefully follows (or should).

Still, there may be bugs in Firefox that make it not correctly obey to dpi, and those need to be solved; note that on a 147dpi, the UI shouldn't be scaled by 2, but by 1.5. If we do a x4, we're awfully off-track.
What would be also cool is to make the default HTML font size be dependent on the default UI font size, since people who set their UI font to tiny probably want tiny fonts on the web, and people who enlarge their UI font probably do so because they need bigger fonts, and they'll need bigger fonts on the web too. I'll check if a bug exists for this suggestion.
Hello guys, I understand that there is somewhere a bug in X/Gnome/Ubuntu, etc, but I don't think it's mature to do a it's-your-fault war. In the end, only the users will be affected. I consider this a major problem, it took me about 1h30 to get to this page and the browser is close to unusable (I can still use the old version though, which is what I did).

I do respect you work, it's a great browser, but forcing people to lose time when it's not their fault it's not a nice thing. At least you could show a message when the DPI settings are above the usual ones with an URL that contains more details/fixes. Meanwhile you could push people from X/Gnome/Ubuntu/etc to fix their problem and move this feature to the next release.

By the way, zooming with the same aspect ratio to both text and images is a really cool feature, I hope it can be done through the menu too.

Thanks for reading and for making a really cool browser.
The dpi setting of my screen is correctly set. The screen is high-dpi, but the interface is ugly in comparison to other gnome windows. FF3 should follow the gnome theme for text size, icons, etc. The zooming of the pages could be right for people with visual problems, but should be selectable. Usually you buy a high dpi screen on laptops, and you want more screen space, not things made bigger.
_FrnchFrgg_: My dpi is correctly set to 147 dpi.

The main problem here is that the interface is also scaled. Perhaps because it uses XUL, and XUL the normal gecko drawing. The interface is now following the Gtk theme set, and the fonts used by other windows. If the user needs big text/big icons that will be accomplised by the GTK theme, and firefox should not scale the theme. (See my previous atachment to see the comparison between the FF3 window and a default Gnome Window).

The page zoom as I said could be desirable. Fonts and images could become very small specially dpis continues increasing. But I think should be an option for the user, at least right now that the factor is less than 2. As I said a warning like this to the user on the first use could be the best solution IMHO:

"Your screen has very high resolution and the pages will be shown tiny in comparison with other screens (XX% the normal size). You can enable a default page zoom adequate to your screen and taste in the preferences settings."

At 147 dpi I can easily see the ugly scaling on graphics, and most people will also notice it and perceive as bad quality rendering of Firefox.

150dpi is the visibility frontier for users. If you have a 300dpi screen scale 2x would be really nice. Text will be smooth&readable and graphics will be scaled but not perceived as "blurred", because base resolution of 150dpi is easy on the eyes. But asuming 96dpi as the base resolution makes graphics look jerky to my eyes. A 4x zoom on a 300 dpi will look awful.
Valentin: I'm not saying "it's gtk's fault", I'm just saying that the solution of "hardcoding to 96dpi" is wrong. We should nevertheless fix this bug.

Guile: If your screen is correctly set to 147dpi, and gnome/gtk obeys it (which it should, IIRC), then you've set the system font to a smaller one ? Personally I find that 10pt is too big and I set my font to 8pt. And I'd like the font to stay roughly the same size (in pt) even with a 400dpi display. Perhaps I'll want to make more use of the screen estate, then I'll set my font to a lower size.
The pb is really visible on Windows, where a lot of people buy "medium-high" dpi screens and because Windows hardcodes the dpi to 96 (you can tell it to go to 120, but it's not automatic nor easy to find, and it breaks things), they finally resort to using a lower resolution, even on LCDs.
The situation is far better on X, let's not break that (especially if this means not doing the same thing as the rest of gtk).
For (non vector) graphics, IIRC it was decided that the scale would be an integer (at least till we use trilinear scaling or similar), and that this integer would be scaled down, so on a 147 dpi screen, it should still be 1 (so icons wouldn't be zoomed). On 300dpi screens, bitmaps would be scaled by 3. Perhaps the base could be taken at a higher res, as you suggest, but you should keep in mind that your visibility frontier is dependent on the viewer, and that a lot of sites still use images for fancy text. OK, we have full zoom now that can take care of those users.

I also think that zooming the theme (the widgets) isn't that great; I thought it wouldn't be since logically the native UI renders in device pixels, not CSS pixels. I think there's a bug here, but I'll need to ask gurus on that.
OK, so first pb is that the integer scale is nearest-rounded, not rounded down. That means that on a 143dpi screen, no scaling of bitmap images occurs, but on 144 there's a x2 scaling. Perhaps the scaling should be initiated higher.

Second pb is that the tango icon theme is in svg format for high sizes, thus scalable, and it seems that Firefox doesn't take advantage of that. Perhaps it is difficult; it should probably be another bug

Last pb is HTML text size: First, pixel font sizes get the same scaling behaviour as images, that is the scaling is brutally initiated at 144 dpi, that means that text size is doubled for you instead of just x1.5, and secondly, HTML default size isn't dependent on default UI font size, which would do the right thing for people like you since you already set your system font to a smaller one (that last part is bug 412669).
_FrnchFrgg_:
(In reply to comment #22)
> OK, so first pb is that the integer scale is nearest-rounded, not rounded down.
> That means that on a 143dpi screen, no scaling of bitmap images occurs, but on
> 144 there's a x2 scaling. Perhaps the scaling should be initiated higher.

Sure! I think 125-150 dpi as base resolution would be ok. If you have double of that, apply x2 scaling.

Right now my "dots" with scaling are 147/2 = 73.50 dpi. Way too big.

> Second pb is that the tango icon theme is in svg format for high sizes, thus
> scalable, and it seems that Firefox doesn't take advantage of that. Perhaps it
> is difficult; it should probably be another bug

The icons should be the same size of gnome desktop. Right now FF3 is using the same font as gnome, but scalled bitmaps. The theme used and appearance of GNOME should be followed. I think this is a problem of the gecko, that is scalling all bitmaps because the dpi setting instead of scalling only on the pages, not the Mozilla interface.

> Last pb is HTML text size: First, pixel font sizes get the same scaling
> behaviour as images, that is the scaling is brutally initiated at 144 dpi, that
> means that text size is doubled for you instead of just x1.5, and secondly,
> HTML default size isn't dependent on default UI font size, which would do the
> right thing for people like you since you already set your system font to a
> smaller one (that last part is bug 412669).

True, but I understand that if you scale images x2 and text x1.5 you will break the appearance of many webpages. All measures (tables, divs...) will be scaled x2 to fit the images, but the text will be small in comparison. I think either you add the support to scale images by non-integer (adding bilinear scaling), or text should be scaled the same proportion as the images, tables, divs...
(In reply to comment #23)
> Sure! I think 125-150 dpi as base resolution would be ok. If you have double of
> that, apply x2 scaling.
> Right now my "dots" with scaling are 147/2 = 73.50 dpi. Way too big.

Calculate the pixel scaling by rounding down instead of to nearest integer should take care of the problem for most of us ; people with >192dpi probably want scaling, since it'll make their icon pixels as big as current standard of 96dpi.
 
> The icons should be the same size of gnome desktop. Right now FF3 is using the
> same font as gnome, but scalled bitmaps. The theme used and appearance of GNOME
> should be followed. I think this is a problem of the gecko, that is scalling
> all bitmaps because the dpi setting instead of scalling only on the pages, not
> the Mozilla interface.

Perhaps we should always have CSS pixels = device pixels on non-zoomed XUL, or only for chrome (more difficult ?). pt and co (thus text) would still scale correctly, as it is done currently.
On the long term, though, we'll need to scale images, and hopefully use SVG for icons ; GTK will also need to do that when >200dpi screens are widespread (think OLPC screen technology, for instance)

> True, but I understand that if you scale images x2 and text x1.5 you will break
> the appearance of many webpages. All measures (tables, divs...) will be scaled
> x2 to fit the images, but the text will be small in comparison. I think either
> you add the support to scale images by non-integer (adding bilinear scaling),
> or text should be scaled the same proportion as the images, tables, divs...
> 

Note that only the "px" unit (CSS pixels) uses an integer scaling factor. "pt", "cm", and other absolute units are linearily scaled ; if your dpi is correctly scaled, then a div of 1cm will really span 1cm. The fact that currently the default HTML font size is in pixels prevent most sites (including google) to scale linearily (pixel-sized sites, which are sadly widespread always will have the pb, at least until we scale images by non integer factor); the best would be to make the default HTML font size be dependent on UI font size, as already said.
This does not block the final release of Firefox 3.
Flags: blocking-firefox3? → blocking-firefox3-
Ubuntu's update last night (for Hardy Heron, the next LTS version) pushed out FF3 so the dpi issue now has greater visibility.  Is there a decision as to whether this will be fixed in FF or in gtk...or somewhere else?  If it doesn't block release of FF3, then it would need to have a fix somewhere else, if Hardy Heron isn't going to launch with widespread dpi issues in FF, right?
asac says he may be able to take this.
Component: OS Integration → GFX: Thebes
Flags: blocking-firefox3-
Product: Firefox → Core
QA Contact: os.integration → thebes
Version: unspecified → Trunk
Ubuntu is getting lots of reports of this in their forums and such. asac thinks he knows what is happening, so I'd really like to get this fixed for Firefox 3.
Flags: blocking1.9?
Status: NEW → ASSIGNED
Vlad/Pav: can you take a quick look at this and see if it's our end or GTK's end, and determine if we should block? I'd minused it based on it not happening to everyone on Linux, but comment 28 concerns me a little ...
Assignee: nobody → asac
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
Note that comment 24 outlines some of the problems and a possible "quick'n'dirty" solution.
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
This happens for users with dpi >= 144, because of how nsThebesDeviceContext::SetDPI() in nsThebesDeviceContext.cpp calculates mAppUnitsPerDevNotScaledPixel ... 

mAppUnitsPerDevNotScaledPixel = PR_MAX(1, AppUnitsPerCSSPixel() /
                                PR_MAX(1, (dpi + 48) / 96));

(http://lxr.mozilla.org/seamonkey/source/gfx/src/thebes/nsThebesDeviceContext.cpp#233)

This means that starting with dpi 144 all images will get scaled by 2.

a potential fix would just use:

mAppUnitsPerDevNotScaledPixel = PR_MAX(1, AppUnitsPerCSSPixel());

but i am not sure if there are other implications. I will bake this in ubuntu for a day or two to get initial feedback from those that are affected ...


(In reply to comment #24)
> (In reply to comment #23)
> > Sure! I think 125-150 dpi as base resolution would be ok. If you have double of
> > that, apply x2 scaling.
> > Right now my "dots" with scaling are 147/2 = 73.50 dpi. Way too big.
> 
> Calculate the pixel scaling by rounding down instead of to nearest integer
> should take care of the problem for most of us ; people with >192dpi probably
> want scaling, since it'll make their icon pixels as big as current standard of
> 96dpi.
> 

I agree that if we want to scale, we want to start with 192dpi; but i am
not sure if we really want images to be scaled at all? Scaled images would look coarse grained, wouldn't they?

I will attach patches for both cases.

Here we have two problems:

1) The icons of the interface are scaled. This should not happen. Firefox interface should follow the same aspect as other gnome apps. If user needs bigger icons, will select an appropriate icon theme in gnome.

2) We are scaling too soon. We should only scale when screens are 192+ dpi (or even more).

Answering your question, if real resolution (ie screen-resolution*scaling factor) is small enough the scaled images won't be a problem. The grain won't be seen and the size will be much better. If real resolution is just 72 dpi, it's too low. Photographic resolution starts at 120dpi (when each pixel is true-color). At 72 dpi I can clearly see each pixel, so a scaling will be horrible. But if you have a 240dpi screen, showing images at 2x (real resolution of 120dpi) will be much nicer that showing really small images.

So my suggestion will be:
floor(screen_dpi / 120)

If any user see thing too small for his taste he could always use zoom. Perhaps the alert I suggested still applies:
-----------------------
You screen has very high resolution and the pages will be shown tiny (XX% the
normal size on other screens). You can enable a default page zoom adequate to
you screen and taste in the preferences settings.
-----------------------
I don't think we can differentiate between 1) and 2) easily; I have to look though.

In case we cannot, would you vote for not auto-scaling at all? or still apply the 120dpi rule you outlined above?

I will vote no autoscale at all.

If page is too small you can always scale with Control +/-. In beta 3 zoom is real scale, scales images, text and other measures so it will be preferable not autoscaling.
Why don't we always scale depending on the dpi? If you have 97, don't scale (or scale to 100%, whatever you like most), if you have 192, scale 200%, if you have 147, scale 150%, and all the values in between. Screens with an resolution of 110 dpi (if those exists), will get scaled somewhere in between...
(In reply to comment #39)
> Why don't we always scale depending on the dpi? If you have 97, don't scale (or
> scale to 100%, whatever you like most), if you have 192, scale 200%, if you
> have 147, scale 150%, and all the values in between. Screens with an resolution
> of 110 dpi (if those exists), will get scaled somewhere in between...

Because:
a) the icons on the Firefox interface are right now being scaled, not only the page. That's not right and breaks appearance compared with the rest of gnome apps.
b) non-integer scaling is much difficult, takes a lot of cpu and looks worse. Graphics will look blurry. Try opening a gif image and scale it in gimp by 1.5x. Show at 100% scale and tell be what you like more.
c) At 96dpi you can distinguish each pixels easily. Thus on images scaled x2 you will notice the blocks and other artifacts. Photographic quality starts at least at 120 dpi (when each pixel is true-color, printers needs more to get the same) and I still peffer 140dpi. A 2x image on a 96dpi x 2 screen will look jaggy. 2x image on a 120dpi x 2 will look nicer, as pixels are small enough for the eyes to not noticing too much the scaling.
d) We now have real page scaling in FF3 beta 3, so you can let the user decide the scaling he wants. If he prefer bigger size or per-pixel sharpness.
Flags: wanted1.9.0.x+
Flags: tracking1.9+
Flags: blocking1.9-
There is another problem with this scaling - it breaks some images.

I have the Image zoom extension installed (which might be a part of this) and many (but not all) images are showing up as black rectangles.

As I reduce the size of an image (via Image zoom), the real image content starts to come into view from the bottom right of the image, as though there were an offset to the image that is also incorrectly being scaled. When the image is reduced to what would be the correct size, it will be completely centered in the rectangle and look correct.

Additional data: The "black box" problem occurs when an image is larger than the box allocated for it in the HTML (and thus the image has to be scaled down).

Thus, if I have an image that is 500x500, and it is being placed into an IMG tag with sidte="250" height="250", then the scaling doesn't happen, and I get the black box.

If I force my display DPI to less than 144 (e.g. by using xrandr --dpy=140) then the problem with such images goes away.

More data: http://www.herdthinners.com is a good test case for me - zooming the comic shows the "black box" issue very well.

I cannot tell if it is because the image is a GIF, or because the site is rendering in quirks mode rather than standards mode.

And this is WITH my DPI forced to be 120 DPI, so changing this is only masking the problem, not fixing it.

ALSO, it seems that sites where the width of the body is constrained to less than the window width are screwed up, in that content from other tabs is "bleeding through" into the areas where there is no content present.

Even more data:

http://www.whiteponyproductions.com/comicstrips/ctc/present.htm

This shows the "background bleeding through" issue for me.

please test this (as well as option B) and let me know whats better and whats still broken for you.
if you have a screen with dpi > 192 please verify this patch to see if the images still look coarse grained.
btw, if you are running ubuntu hardy you can test firefox-3.0 with the xulrunner-1.9 package for |option 1| from my PPA

 https://edge.launchpad.net/~asac/+archive

I rather like the new scaling engine.

I always had problems regarding font sizes on my 15,4" LCD with

$ xdpyinfo | grep dimensions
  dimensions:    1680x1050 pixels (331x212 millimeters)
$ xdpyinfo | grep resolution
  resolution:    129x126 dots per inch

But the way pages are resized with the new engine is really nice.
Now most of the videos (youtube, ...) embedded in all blogs and
everywhere don't look like animated stamps :-) anymore.

With layout.css.dpi -1 and System dpi 128, font-size 10 (standard),
the fonts are way too small (picture1), page zoom helps
although it still sometimes messes up the layout (picture2 (Strg+Wheelup-2clicks))
(but it's a lot better than it used to be).
http://img356.imageshack.us/my.php?image=googleya7.png
http://img356.imageshack.us/my.php?image=google2dn9.png

The thing is - that the UI gets "overproportionally" (huge) resized.
(would make a screenshot, but I can't get the right settings back to standard)

I have high hopes for FF 3 - with FF2 I was thinking about buying a different
laptop.

If I can be of any help, don't hesitate to ask.
(In reply to comment #49)
> btw, if you are running ubuntu hardy you can test firefox-3.0 with the
> xulrunner-1.9 package for |option 1| from my PPA
> 
>  https://edge.launchpad.net/~asac/+archive
> 

Using this package fixes the default x2 scalling problem as I already said. The only issue is still big fonts on epiphany.

(to comment #50): This bug is about default scaling with high dpi screens. For other scaling issues open a new bug.
I have the same problem on my windows machine (XP SP1) using a 1280X1024 screen setting and 144DPI. It's intentionaly set this way and working fine so far since  the early phoenix era. Scaling could be offered as an option but i can't see why it should be forced by default(In reply to comment #2)
> 180dpi sounds way off; I think your screen is closer to 96dpi.  (If I'm
> calculating right, the screen is about 20"x13", and 1920/20 is 96 dpi.)  You
> should fix your x config to return the correct dpi.
> 
> The scaling is intentional; we might have to turn it off if too many people
> have misconfigured computers, though... although this is the first case I've
> heard of dpi accidentally configured to be too high.
> 


Patch #2 is acceptable.

I think it might be a good idea to have a pref for this actually. Then various platforms/distributions, or extensions, can control it. Say "layout.css.devPixelsPerPx", which can be either a positive integer (1,2,3,...) or -1 to get a default behaviour, either the current behaviour or the current behaviour modified by patch #2.

I don't know what's up with the "black box" problem mentioned in comments 42 and 43. It's just a plain bug of its own, so please file that as a separate bug with testcase and instructions to reproduce, instructions that probably include "set layout.css.dpi to XYZ...". And CC me and mark it blocking?, thanks.

(In reply to comment #36)
> 1) The icons of the interface are scaled. This should not happen. Firefox
> interface should follow the same aspect as other gnome apps. If user needs
> bigger icons, will select an appropriate icon theme in gnome.

This isn't enough since other UI elements may need scaling. GNOME is going to need a general facility for scaling the UI but currently it doesn't have one AFAIK. We do. Should we cripple ours to maintain consistency with GNOME? Tough call, but if we do the pref thing then at least distros can make that call for themselves.

Although the truth is that we're kind of crippled too since our native theme code sizes certain native widgets using native metrics regardless of scaling we're doing.

> 2) We are scaling too soon. We should only scale when screens are 192+ dpi (or
> even more).

I buy that argument to some extent, which is why I think patch #2 is fine. And at 200dpi you're getting to the point where arguments about platform consistency are not compelling when the browser UI and Web pages are just too small to use effectively. (Although as I just mentioned some of the widgets are still going to be too small :-(.)
Comment on attachment 308395 [details] [diff] [review]
option 2: scale for 192+ dpi


I am not sure if we really want an int pref to tweak the scaling. Maybe use a boolean like "disable_dpi_scaling" instead?
Attachment #308395 - Flags: review?(roc)
Comment on attachment 308395 [details] [diff] [review]
option 2: scale for 192+ dpi

I think an int pref would actually be nice since distributors for specific devices, or extensions providing UI, might want to set it to an explicit scale.
Attachment #308395 - Flags: superreview+
Attachment #308395 - Flags: review?(roc)
Attachment #308395 - Flags: review+
Attachment #308395 - Flags: approval1.9?
(In reply to comment #53)
> (In reply to comment #36)
> > 1) The icons of the interface are scaled. This should not happen. Firefox
> > interface should follow the same aspect as other gnome apps. If user needs
> > bigger icons, will select an appropriate icon theme in gnome.
> 
> This isn't enough since other UI elements may need scaling. GNOME is going to
> need a general facility for scaling the UI but currently it doesn't have one
> AFAIK. We do. Should we cripple ours to maintain consistency with GNOME? Tough
> call, but if we do the pref thing then at least distros can make that call for
> themselves.
> 
> Although the truth is that we're kind of crippled too since our native theme
> code sizes certain native widgets using native metrics regardless of scaling
> we're doing.

If the gnome interface is too small you can increase font size (this makes buttons scale to contain the text) and/or use a big icons (You can set sizes of icons in the gtkrc: with the line: 'gtk-icon-sizes="panel-menu=16,16:gtk-menu=16,16:panel=16,16:gtk-large-toolbar=16,16:gtk-small-toolbar=16,16"')

What mozilla could not do is to scale the icons that other gnome apps are using unscaled, because it will look different from the rest of apps.
Blocks: 424822
ok, i created #424822 to track roc's suggestion in comment #53 to introduce a pref to manually tweak the scaling behaviour.
A. Firefox should respect X dpi autodetection

B. When X autodetection is broken it needs to be fixed at the X level, and adding application-level workarounds only makes the situation an infixable mess

C. However Firefox should also use the font sizes the user set on its desktop (this is bug #414427). The user configures one-time at the desktop level if he likes small or big fonts, etc. Under Linux encoding-specific font substitution is handled system-wide by fontconfig and the long list of Firefox font preferences is quite user-hostile.

For bitmap images there is no perfect solution. Either you scale according to dpi, and you conserve a web-designer safe text/image ratio (but you accept scaling artifacts even when the scaling was not 100% indispensable) or you scale non-linearly, and accept the formatting artifacts due to text using another scaling method.

Either way not scaling text according to X dpi is IMHO deeply unacceptable as text quality is the primary requirement of a browser (except for yourtube-only freaks)
Blocks: 378927
As a data point, this is one of the most reported bugs in the Fedora 9 Beta, and is a frequent report for the RHEL 5.2 Beta.
Requesting blocking again based on comment #59 and other reports I've personally seen.
Flags: blocking1.9- → blocking1.9?
1-Might it be practical to implement limiting scaled CSS px applicability to viewport content? If it's doable it ought to keep current theming working.
and/or
2-Why not reduce the disparity between device px and css px by using a stepped scale? e.g.
(84, 88, 92,) 96, 100, 104, 108, 112, 116, 120, etc., or
(80, 88,) 96, 104, 112, 120, 128, etc., or
(84,) 96, 108, 120, 132, 144, etc., or
96, 120, 144, 168, 192, etc.

I've noticed that most pt sized vector fonts seem happiest stepping at even multiples of 12, but I've never looked at steps of 16.
I had the same problem on Windows XP Pro/2003 Server with 150% DPI setting (Display properties/Advanced/General/Display/DPI Setting/Custom setting/150%) with FF3b4. 

It makes Firefox 3 unusable on Windows for me as icons and fonts are too huge. 

Also, layout.css.dpi is not settable on Windows in about:config (perhaps because it has no effect on win32 due to DPI autodetection).
Attachment #308395 - Flags: approval1.9? → approval1.9+
Keywords: checkin-needed
Checking in gfx/src/thebes/nsThebesDeviceContext.cpp;
/cvsroot/mozilla/gfx/src/thebes/nsThebesDeviceContext.cpp,v  <--  nsThebesDeviceContext.cpp
new revision: 1.74; previous revision: 1.73
done
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9
note: desktops can set their font dpi independently from the screen dpi (e.g. in gnome through /schemas/desktop/gnome/font_rendering#dpi).

For instance, ubuntu defaults to 96 because of X driver bugs. In the long run we might want to discuss if we want to use that dpi setting (if set) as input for our calculations here.
Verified FIXED with a fresh install of Fedora Core 7 on:

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008040304 Minefield/3.0pre

(Was seeing this myself in 1280x800.)
Status: RESOLVED → VERIFIED
also verified fixed with Fedora 8 and Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9pre) Gecko/2008040313 Minefield/3.0pre ID:2008040313 (Debug Build)
I'm still seeing huge form elements in print preview; not sure if that's because of this bug or not.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008040304 Minefield/3.0pre
Verified FIXED at Windows XP SP2

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008040305 Minefield/3.0pre
I see that this has been verified fixed.  3.0b5 still possesses this flaw, which is the latest beta available.
It was fixed after cut off of 3.0b5 and verified with nightly builds.
Ahh, OK.  Is there going to be another beta release that I can test?
I'm running the latest nightly builded snapshot (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008041004 Minefield/3.0pre) and i have still the same problem.

I'm still seeing problems, too.  I'll attach an image of misaligned text.
xdpyinfo shows:
  dimensions:    2048x768 pixels (493x185 millimeters)
  resolution:    106x105 dots per inch

That's at least close enough to the real size (i haven't measure it). Its a multiple monitor setup on my Laptop (12" Display + 17" external TFT).

BTW: Please see my initially opened bug report:

https://bugzilla.mozilla.org/show_bug.cgi?id=428024

My problem happens only when i start X with one monitor and enable the second one with xrandr. That's reproducible every time.
(In reply to comment #78)
> xdpyinfo shows:
>   dimensions:    2048x768 pixels (493x185 millimeters)
>   resolution:    106x105 dots per inch

> My problem happens only when i start X with one monitor and enable the second
> one with xrandr. That's reproducible every time.

You need to check xdpyinfo when the problem occurs. Some drivers are known to miscalculate DPI when xrandr is used, and firefox can't be blamed for quirking when Xorg feeds it garbage information (ie you're probably hitting an Xorg bug. Get it fixed Xorg side)

I'v investigated that a little bit more. Seams that, at least now (don't know whether that's the same as with the versions before, it happens there but i don't know if only in this case), i can reproduce it every time that way:

Steps to reproduce:
1. Start X with only my laptop-display attached, external monitor's vga cable is not plugged in. xdpyinfo shows:

  dimensions:    1024x768 pixels (246x185 millimeters)
  resolution:    106x105 dots per inch

2. Start firefox
3. Plug the external monitor in
4. Run xrandr --output VGA --left-of LVDS --mode 1024x768 -> the desktop gets extended, xdpyinfo shows:

  dimensions:    2048x768 pixels (493x185 millimeters)
  resolution:    106x105 dots per inch

5. Open a new firefox window -> the bug occures

There are other combination where the bug does _NOT_ occurs:

Starting/restarting (stop+start) firefox after changing the desktop size with xrandr -> everything is fine

and

Have the external monitor plugged in upon starting X (it will get to clone mode without xrandr). In that case xdpyinfo shows:

  dimensions:    1024x768 pixels (269x201 millimeters)
  resolution:    97x97 dots per inch


After extending the desktop with the same xrandr command, xdpyinfo shows:

  dimensions:    2048x768 pixels (536x201 millimeters)
  resolution:    97x97 dots per inch

...and everything works fine..

So it seams to happens only if there is no second monitor attached on starting X...
The comment here no longer reflects reality, since we're not finding the nearest multiple of 96 any more.  Dunno if anyone cares about that?

Vlad believes that we should #ifdef MOZ_WIDGET_GTK2 around this and return other platforms to their behaviour from before this change, to remedy bug 434157.  I have no reason to disagree.
OOPS! this one was fixed with RC1 and now it's back with the RC2!!!
(on WIN XP SP1 with a 150% DPI setting)
(In reply to comment #83)
> OOPS! this one was fixed with RC1 and now it's back with the RC2!!!
> (on WIN XP SP1 with a 150% DPI setting)

See bug 434157.
I still consider this a bug since firefox had no such problem in the past. everything works fine on my linux machine but everything is scaled up on my windows machine. Mozilla/5.0 (Windows; U; Windows NT 5.1; el; rv:1.9) Gecko/2008052906 Firefox/3.0
This bug resurfaced in Firefox 3.0 under WIN XP SP2 with a 150% DPI setting.
Resolved in Forefox 3 RC1, this bug persisted in Firefox 3.0, 3.0.1, and 3.1 Alpha on Windows XP SP2 with 150% DPI setting.
I'm also seeing this bug on Windows XP SP3 in 3.0.1 and 3.1a2, with 147 DPI (153%).
But if I set layout.css.dpi to 143 or less, everything is normal sized, so it's still finding the nearest multiple of 96.
It worked for me with layout.css.dpi set to 1 in FF 3.0.1. The trick was to right click in the preferences and add new Integer value if layout.css.dpi is not there.
Flags: wanted1.9.0.x+
Just curious, what's the status of this bug? With newer versions of Windows exposing the font scaling setting more prominently to the user, this bug might see more visibility, and it's silly to consider manually overriding laout.css.dpi to be a proper fix.
Please file a new bug for Windows. This patch was fixed as originally reported.
Blocks: 513439
No longer blocks: 513439
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: