Ticket #889 (closed defect: fixed)

Opened 7 years ago

Last modified 7 years ago

Firefox

Reported by: mburns Owned by: dcbw
Priority: normal Milestone: BTest-4
Component: sugar Version:
Keywords: sugar-love Cc:
Action Needed: Verified: no
Deployments affected: Blocked By:
Blocking:

Description

The Web Browser activity seems to render images awkwardly (overly small), likely as a result of the OLPC's very high DPI. The gecko engine does not seem to get the proper value for the system's logical resolution, and may be defaulting to 996 [1]. Changing this setting to recognize the screen's 200 dots per inch capabilities should resolve this issue.

[1] http://kb.mozillazine.org/Layout.css.dpi

Change History

Changed 7 years ago by marco

Have you tried on the latest image?

Changed 7 years ago by jg

  • priority changed from low to normal
  • milestone changed from Untriaged to BTest-3

To be more specific, Marco just added a new version of the web browser which scales to the screen, by updating to recently landed version of the Gecko rendering engine.

We'd be very interested if there are still problems in this area, as we know it has been a serious issue. So please experiment with current builds of sugar. h

Changed 7 years ago by joaoboscoapf

Things are big now. Actually, for a 800x600 site (fixed size) it is too big.

It is also very slow ...

Changed 7 years ago by joaoboscoapf

Another thing: It is not possible to reproduce the behavior of Xulrunner 1.8 by changing the value of "layout.css.dpi". This could be nice since the rendering of the new browser is much slower than the old one.

Changed 7 years ago by AlbertCahalan

Let the user change to 600x450 or 400x300 via the Sugar, causing the X server to do simple integer scaling. That should be very fast. (just duplicate/triplicate lines and columns) Web pages are somewhat less likely to break with a different screen size than if you go changing fonts and images alone. (JavaScript and flash would need scaling, etc. -- just do the whole screen)

As an extra benefit, it would help more than just the web browser. Getting apps to run in low resolution is often much easier than getting them to look right-sized via the "proper" way, and anyway there often won't be enough CPU power to drive the full 1200x900 at a decent speed.

Changed 7 years ago by marco

  • status changed from new to closed
  • resolution set to fixed

We are now setting a 134 dpi.

Changed 7 years ago by jg

  • status changed from closed to reopened
  • type changed from enhancement to defect
  • resolution deleted

Why do you think this is fixed?

Note that DPI settings are pretty strange in general, and have effects that are not obvious. For example, GTK by default presumes 96DPI, and does so for good reason (Windows does it this way all the time, and web pages are engineered with that resolution in mind).

In at least one other bug, I remember seeing complains about google maps; until that one is really nailed, I'd like this one left open.

Changed 7 years ago by marco

The GTK dpi settings is completely different from the mozilla one. In mozilla it applies to all the units used in the web pages. Setting the DPI to 96 would make all the text unreadable.

I'm sure there are several issues with the current implementation but having this bug open is by no means useful. We need bugs about specific problems, for example the one about google maps.

Changed 7 years ago by marco

  • status changed from reopened to closed
  • verified unset
  • resolution set to fixed
Note: See TracTickets for help on using tickets.