Confirmed users
586
edits
(→Gotchas: add initial rounding/conversion section) |
|||
| Line 42: | Line 42: | ||
=== Display ports === | === Display ports === | ||
If no display port is set, then the layer may end up in a non-scrollable state, which can potentially confuse the compositor and interfere with propagating the correct page sizes. Therefore a display port must always be set on the document element of the document being drawn. | If no display port is set, then the layer may end up in a non-scrollable state, which can potentially confuse the compositor and interfere with propagating the correct page sizes. Therefore a display port must always be set on the document element of the document being drawn. | ||
=== Rounding and conversions === | |||
Gecko does layout calculations in twips (1 twip == 1/60 of a CSS pixel). This is mostly irrelevant except for the fact that these are not floats. Drawing code in Gecko uses mostly floats; the zoom factor/resolution is a float. In order to make sure values line up and aren't off by a pixel here and there, all of these need to be taken into consideration when moving values around, rounding them as needed. | |||
* Scroll offsets in Gecko (e.g. window.scrollTo parameters) are always in integers in CSS pixels. Java keeps them as floats in device pixels. The compositor gets this value from Gecko in integers but uses floats for compositing, and so does a lossless conversion. Browser.js must perform a lossy conversion from floating-point device pixels to integer CSS pixels when handing scroll offsets to gecko. Java code and the compositor may use floats. | |||
* View size is always an integer in device pixels. All code that needs to keep this value should keep it as such. | |||
* 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). | |||
* Page sizes in Gecko (e.g. document.body.scrollWidth) are always in integers in CSS pixels. When drawing, Gecko multiplies them by the resolution and rounds them *up* to the nearest device pixel. This is a lossy conversion; the compositor gets these integer device pixel values and passes them on to Java. Therefore Java must be aware that page sizes it gets from the compositor have already undergone a lossy conversion. Java keeps page sizes as floats in device pixels. | |||
* 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. | |||
== Related bugs for more information == | == Related bugs for more information == | ||