Confirmed users
586
edits
Fennec/NativeUI/Viewport: Difference between revisions
Jump to navigation
Jump to search
→Rounding and conversions
(→Rules) |
|||
| Line 51: | Line 51: | ||
* Zoom is always a float value. All code that needs to keep this value should keep it as such. browser.js passes this value to Gecko using a call to setResolution(float). | * Zoom is always a float value. All code that needs to keep this value should keep it as such. browser.js passes this value to Gecko using a call to setResolution(float). | ||
* Gecko itself tracks the display port in twips; the display port enters Gecko via the setDisplayPortForElement function which takes floating-point CSS pixel values. These values are converted directly to twips without intermediate rounding; therefore the display port in Gecko may include sub-pixel regions. Java keeps display port margins in floats in device pixels, and must be aware that a slightly-lossy conversion is happening on those values in Gecko. | * Gecko itself tracks the display port in twips; the display port enters Gecko via the setDisplayPortForElement function which takes floating-point CSS pixel values. These values are converted directly to twips without intermediate rounding; therefore the display port in Gecko may include sub-pixel regions. Java keeps display port margins in floats in device pixels, and must be aware that a slightly-lossy conversion is happening on those values in Gecko. | ||
* When we calculate the painted area, we must take into account any lossy conversions that have happened on the coordinates that originated in Java. Specifically, say the Java code starts with (x,y)=(0.0,6.0) at a zoom level of 4.0; browser.js ends up calling window.scrollTo(0.0,1.5) which Gecko internally tracks as (0, 1). When Gecko paints, it will paint such that the CSS pixel (0,1) occupies the top-left 4x4 device pixels. When the widget code asks browser.js for the current Gecko viewport, browser.js will take (0,1) and multiply it by 4.0, giving (0.0, 4.0) and hand it to Java as the top-left corner of the painted area. This, while correct, is off by 2 pixels from what the original Java value was, and can be a source of error if not accounted for. | |||
== Related bugs for more information == | == Related bugs for more information == | ||