<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jun 23, 2011, at 11:46 AM, Levi Weintraub wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="font-family: Times; font-size: medium; "><div style="background-color: transparent; margin-top: 0px; margin-left: 0px; margin-bottom: 0px; margin-right: 0px; "><span id="internal-source-marker_0.6566142209339887" style="font-size: 11pt; font-family: Arial; color: rgb(0, 0, 0); background-color: transparent; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap; ">We’ve been getting an increasing number of complaints lately about the zooming support in webkit and how hard it is to correctly support zooming in complex web applications.</span><br>

<span style="font-size: 11pt; font-family: Arial; color: rgb(0, 0, 0); background-color: transparent; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap; "></span><br>

<span style="font-size: 11pt; font-family: Arial; color: rgb(0, 0, 0); background-color: transparent; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap; ">To address this we plan to convert the rendering tree to float to allow for better zooming and scaling support. Furthermore this could be expanded to support sub-pixel layout and positioning which in turn would allow higher precision layout when zoomed. We’re the only rendering engine that hasn’t yet made this change.</span><br>

<span style="font-size: 11pt; font-family: Arial; color: rgb(0, 0, 0); background-color: transparent; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap; "></span><br>

<span style="font-size: 11pt; font-family: Arial; color: rgb(0, 0, 0); background-color: transparent; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap; ">Changing rendering (and hit testing) to use floats does not necessarily mean that we need to expose floats through the dom api, however if we are to support sub-pixel layout (i.e. style=”left: 12.3px”) this would be required. Specifically we’d need to change the offsetLeft/Top/Width/Height properties to return floating point values [2]. </span><br>

<span style="font-size: 11pt; font-family: Arial; color: rgb(0, 0, 0); background-color: transparent; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap; "></span><br>

<span style="font-size: 11pt; font-family: Arial; color: rgb(0, 0, 0); background-color: transparent; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap; ">We tried two strategies for building a proof of concept, one of which involved accumulating error when laying out with an applied zoom, and the other was a wholesale swap of integers for floats in the layout engine. Ultimately, we discovered that our hopes of the former being a less-invasive solution were lost when the patch grew to the size of the more-invasive latter, and we decided to focus our efforts there.</span><br>

<span style="font-size: 11pt; font-family: Arial; color: rgb(0, 0, 0); background-color: transparent; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap; "></span><br>

<span style="font-size: 11pt; font-family: Arial; color: rgb(0, 0, 0); background-color: transparent; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap; ">In the span of 10 days, we built a working prototype that passes over 90% of our layout tests and renders most webpages correctly, including our original zooming test cases. There are still numerous rounding errors, but tracking these down and fixing them is beyond the scope of our proof of concept. We’ve uploaded the resulting patch on the meta bug [1] tracking our work. It’s been tested on the Mac and QT ports.</span><br>

<span style="font-size: 11pt; font-family: Arial; color: rgb(0, 0, 0); background-color: transparent; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap; "></span><br>

<span style="font-size: 11pt; font-family: Arial; color: rgb(0, 0, 0); background-color: transparent; font-style: normal; font-variant: normal; text-decoration: none; vertical-align: baseline; white-space: pre-wrap; ">To make this transition as painless as possible (read: to avoid landing one massive patch), we plan on first moving our current int values to an abstraction that will begin as a typedef to int and its progeny IntRect, IntPoint, and IntSize. We’ll also implement requisite rounding functionality behind a USE(FLOAT_OFFSETS) [or other name, pending discussion] flag. These steps are transitional only, and this abstraction and USE flag will both be removed once we successfully make the jump from int->float.</span><br></div></span></blockquote><div><br></div><div>While compact, the 32-bit float type has poor precision and doesn’t match some platforms’ graphics layers’ underlying floating-point type (such as CGFloat in 64-bit OS X). As long as you are using a typedef, it might be better to make the render tree floating-point type easily configurable, so that different ports can use (or at least experiment with) different types.</div></div></body></html>