Confirmed users
586
edits
Fennec/NativeUI/Viewport: Difference between revisions
Jump to navigation
Jump to search
→Rounding and conversions
(→Rules) |
|||
| Line 48: | Line 48: | ||
=== Rounding and conversions === | === 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 and converting floats to twips is lossy. 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. | 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 and converting floats to twips is lossy. 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. See https://bugzilla.mozilla.org/show_bug.cgi?id=737510#c10 for an example of the hairiness this results in. | ||
* Scroll offsets and page sizes in Gecko are always integer values 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. Java keeps them as floats in device pixels. Therefore Java must be aware that page sizes it gets from the compositor have already undergone a lossy conversion and may not line up properly with internally-stored values. | * Scroll offsets and page sizes in Gecko are always integer values 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. Java keeps them as floats in device pixels. Therefore Java must be aware that page sizes it gets from the compositor have already undergone a lossy conversion and may not line up properly with internally-stored values. | ||
* View size is always an integer in device pixels. All code that needs to keep this value should keep it as such. | * View size is always an integer in device pixels. All code that needs to keep this value should keep it as such. | ||