Opened 8 years ago

Closed 6 years ago

#4244 closed defect (fixed)

Font/images are small on the XO display

Reported by: dnarvaez Owned by: manuq
Priority: Unspecified by Maintainer Milestone: Unspecified
Component: Browse Version: Unspecified
Severity: Unspecified Keywords:
Cc: Distribution/OS: Unspecified
Bug Status: Unconfirmed

Description

The XO display is very high dpi, so images and fonts from web pages are very small.

I had a look to how hulahop was handling this and it seems pretty similar to what window.devicePixelRatio provides these days. webkitgtk doesn't provide a way to set it to a custom value, so I'm trying out the following patch (takes a while to build especially inside a vm, so I don't have results to report yet).

The hulahop factor was around 1.4.

--- webkitgtk-1.10.1/Source/WebKit/gtk/webkit/webkitwebview.cpp.orig 2012-11-18 15:26:53.468318685 -0500
+++ webkitgtk-1.10.1/Source/WebKit/gtk/webkit/webkitwebview.cpp 2012-11-18 15:25:50.637418055 -0500
@@ -3616,6 +3616,7 @@

pageClients.inspectorClient = new WebKit::InspectorClient(webView);


priv->corePage = new Page(pageClients);

+ priv->corePage->setDeviceScaleFactor(2);

#if ENABLE(GEOLOCATION)

if (DumpRenderTreeSupportGtk::dumpRenderTreeModeEnabled()) {

Attachments (4)

Screenshot of _Google_.png (45.6 KB) - added by erikos 8 years ago.
screenshot after applying the patch
scale.patch (3.5 KB) - added by dnarvaez 8 years ago.
scale-fast.patch (4.2 KB) - added by dnarvaez 8 years ago.
Fix the scrolling fast path
scale1024x768.patch (3.5 KB) - added by dnarvaez 8 years ago.

Download all attachments as: .zip

Change History (20)

comment:1 Changed 8 years ago by erikos

Thanks Daniel for that. I have added a build that includes the patch: http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=1256161

comment:2 Changed 8 years ago by erikos

Hmm, building did fail, but does not look like it has something to do with the patch: http://arm.koji.fedoraproject.org/koji/getfile?taskID=1256162&name=build.log&offset=-4000

comment:3 Changed 8 years ago by dnarvaez

Yeah, don't think it's related. Maybe something new landed in rawhide (like a compiler) and broke the build.

comment:4 Changed 8 years ago by dnarvaez

I take that back it's my patch

Source/WebKit/gtk/webkit/webkitwebview.cpp:3619:20: error: request for member 's
etDeviceScaleFactor' in 'priv->_WebKitWebViewPrivate::corePage', which is of poi
nter type 'WebCore::Page*' (maybe you meant to use '->' ?)

Trying to build the damned thing locally and provide a working patch.

comment:5 Changed 8 years ago by erikos

Changed 8 years ago by erikos

screenshot after applying the patch

comment:6 Changed 8 years ago by erikos

Building a new one with the factor set to 1.4: http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=1256694

Test case from Daniel: http://sugarlabs.org/~dnarvaez/test.html

comment:7 Changed 8 years ago by dnarvaez

In ScrollViewGtk.cpp ScrollView::visibleContentRect

return IntRect(IntPoint(m_scrollOffset.width(), m_scrollOffset.height()),

IntSize(allocation.width, allocation.height));

If I update this to take the ratio in account (/ 2), the initial rendering of the testcase looks correct. Though scrolling is broken. Maybe more stuff to convert... Need to look more into it.

Changed 8 years ago by dnarvaez

comment:8 Changed 8 years ago by dsd

If I remember right, Browse already makes the fonts and images bigger than normal via normal webkitgtk API. You can also increase the size of both text and images with the zoom functionality on the toolbar. Maybe we just need to make things bigger by default with the controls we already have?

If a webkitgtk-level change is needed, the patch will need to be crafted in a way suitable for upstream. I know at the moment it is just more of an experiment.

comment:9 Changed 8 years ago by dnarvaez

I'm not aware of current webkitgtk API that can scale images up. And if you try to do it you will screw up all the layouts. About the fonts, you can probably set a default and minimum size, which helps a bit but I don't think solves the problem on many (maybe most) websites. And again it breaks layouts. Zoom requires user intervention and requires scrolling around, so I don't think it's a good solution either.

What you want to do on a high dpi screen is so to layout at a lower resolution and then zoom it up. We was doing something similar with the mozilla based web browser (though not exactly the same I think), so I suspect if we don't fix this it will be felt as a regression.

About submitting upstream, I'm first trying to figure out how to make this work... if I get there adding API for it shouldn't be hard.

Changed 8 years ago by dnarvaez

Fix the scrolling fast path

comment:10 Changed 8 years ago by dnarvaez

I attached a patch that fixes the fast path. There are some artifacts while scrolling but it's probably just approximation that needs tweaking.

We need to test and decide if we want to go down this path. If so I can write a proper patch.

Changed 8 years ago by dnarvaez

comment:13 Changed 8 years ago by dnarvaez

Simon, could you please build an rpm with the scale1024x768 patch?

I tested the rpm with the scale.patch, it works as expected, fonts are readable, layout is fine, though most websites shows an horizontal scrollbar. It looks like these days most desktop websites are designed for a minimum of 1024x768. So the patch tries a factor of 1.171875, which gives exactly a 1024x768 screen, horizontal scrollbars will go away but I'm not sure how readable the text will be. It's a 17% increment which should help, but it will probably be not be enough.

I think the alternatives are:

  • Hope web sites improves on smaller devices :) Mostly joking but who knows with all the smaller tablets on the market...
  • Zoom to fit. Though I'm not sure I like that when used in laptop "mode", it sort of requires touch.
  • Horizontal scrollbars :/

comment:14 Changed 8 years ago by erikos

comment:15 Changed 8 years ago by dnarvaez

Installed the rpm and as expected layout is fine but some sites are too small to read (guardian.co.uk and cnn.com for example). I think we should compare two xo side by side (with and without the patch) to see how much of an improvement it is. I don't have two xos with me at the moment though.

comment:16 Changed 6 years ago by quozl

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

Reviewed on OLPC OS 13.2.4, and it seems fine now, closing.

Note: See TracTickets for help on using tickets.