From 52958546b410557c1b7abb46560fb7f2cd219d6f Mon Sep 17 00:00:00 2001 From: Mike Reed Date: Mon, 19 Oct 2009 10:50:14 -0400 Subject: [PATCH] return default 1.0 for scaleFactor(), since android doesn't record at the same res as it draws --- .../android/WebCoreSupport/ChromeClientAndroid.cpp | 24 ++++++++++++++++++++-- 1 file changed, 22 insertions(+), 2 deletions(-) diff --git a/WebKit/android/WebCoreSupport/ChromeClientAndroid.cpp b/WebKit/android/WebCoreSupport/ChromeClientAndroid.cpp index dd608b6fe..015f9a0a2 100644 --- a/WebKit/android/WebCoreSupport/ChromeClientAndroid.cpp +++ b/WebKit/android/WebCoreSupport/ChromeClientAndroid.cpp @@ -81,8 +81,28 @@ FloatRect ChromeClientAndroid::pageRect() { notImplemented(); return FloatRect() float ChromeClientAndroid::scaleFactor() { - ASSERT(m_webFrame); - return m_webFrame->density(); + /* Conceptually, we should return the density of the device's screen, + except that we don't really model webkit's notion of drawing. Webkit + expects the drawing context's matrix (plus scale-factor) to reflect the + actually transformation to the pixels, and thus it uses scaleFactor to + perform some pre-rounding in a few places (e.g. HTMLCanvasElement). + + ASSERT(m_webFrame); + return m_webFrame->density(); + + However, in Android we capture the drawing into a displayList, and then + replay that list at various scale factors (sometimes zoomed out, other + times zoomed in for "normal" reading, yet other times at arbitrary + zoom values based on the user's choice). In all of these cases, we do + not re-record the displayList, hence it is usually harmful to perform + any pre-rounding, since we just don't know the actual drawing resolution + at record time. + + Given Android's device-independent drawing model, we always return 1.0 + for this function, and we implement roundToDevicePixels() to be a no-op + so that we don't introduce pre-rounding artifacts during record. + */ + return 1.0f; } void ChromeClientAndroid::focus() { -- 2.11.0