Opened 10 years ago

Closed 10 years ago

Last modified 20 months ago

#889 closed defect (fixed)


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


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.


Change History (10)

comment:1 Changed 10 years ago by marco

Have you tried on the latest image?

comment:2 Changed 10 years ago by jg

  • Milestone changed from Untriaged to BTest-3
  • Priority changed from low to normal

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.

comment:3 Changed 10 years ago by joaoboscoapf

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

It is also very slow ...

comment:4 Changed 10 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.

comment:5 Changed 10 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.

comment:6 Changed 10 years ago by marco

  • Resolution set to fixed
  • Status changed from new to closed

We are now setting a 134 dpi.

comment:7 Changed 10 years ago by jg

  • Resolution fixed deleted
  • Status changed from closed to reopened
  • Type changed from enhancement to defect

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.

comment:8 Changed 10 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.

comment:9 Changed 10 years ago by marco

  • Resolution set to fixed
  • Status changed from reopened to closed
  • Verified unset

comment:10 Changed 20 months ago by Quozl

  • Milestone BTest-4 deleted

Milestone BTest-4 deleted

Note: See TracTickets for help on using tickets.