[webkit-dev] Switching away from integers for layout

[Eric Seidel]

I know you made some consideration of "fixed point" vs. "float point"
in your investigation.  I suspect that decision is orthogonal to work
of plumbing more precise types through the engine... but I am still
curious to know if there was a decision if fixed point or float point
might be the eventual unit type for the layout engine?

Have you done any investigation as to what sorts of rounding code will
be needed?  How many places we'll have to round?  It seems to me the
harder part in getting this right is not the (largely mechanical)
plumbing of Float (or whatever "precise") types everywhere, but rather
deciding which places to round.

Do you have some fancy screen shots to share? :)

I know you did some investigation as to possible perf affect of this
change.  Could you share those results too?  (Either here or in a
bug.)

-eric

On Thu, Jun 23, 2011 at 11:46 AM, Levi Weintraub <leviw at chromium.org> wrote:
> 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.
>
> 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.
>
> 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].
>
> 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.
>
> 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.
>
> 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.
>
> --
> Levi & Emil
>
> 1: https://bugs.webkit.org/show_bug.cgi?id=60318 - Meta bug, has proof of
> concept patch and a couple of test cases.
> 2: https://bugs.webkit.org/show_bug.cgi?id=54018 - Convert offset* to float.
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>