Font/images are small on the XO display

[dnarvaez]

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()) {

[erikos]

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

[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

[dnarvaez]

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

[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.

[erikos]

Sorry was my fault, building again: ​http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=1256272

[erikos]

screenshot after applying the patch

[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

[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.

[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.

[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.

[dnarvaez]

Fix the scrolling fast path

[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.

[erikos]

rpm with patch: ​http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=1257472

[erikos]

and building with the fast patch: ​http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=1257714

[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 :/

[erikos]

new rpm with the scale1024x768.patch ​http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=1261468

[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.

[quozl]

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