Re: [webkit-dev] Switching away from integers for layout
On Fri, Jun 24, 2011 at 7:11 AM, Levi Weintraub wrote: > Emil and I looked into what Firefox did. They did go with a > fixed-point-esque approach where one of their units represents 1/96th of a > pixel. That number should tell you something about when this work was done, > and they were mostly concerned about performance. Back in the mists of time the units were variable and sometimes equal to 1/96 of a pixel. More recently (but still years ago) we changed to 1/60 of a CSS pixel. And we chose fixed-point-esque not just because of performance but also because you keep useful properties such as associativity and commutativity. If you're doing performance tests, make sure you test on ARM systems, which have widely varying floating-point capabilities. Rob -- "If we claim to be without sin, we deceive ourselves and the truth is not in us. If we confess our sins, he is faithful and just and will forgive us our sins and purify us from all unrighteousness. If we claim we have not sinned, we make him out to be a liar and his word is not in us." [1 John 1:8-10] ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Switching away from integers for layout
We spent a lot of time thinking about this and I should have mentioned our thoughts in the original email. My apologies. We're not opposed to fixed-point, but given that the line box tree and SVG both already use floating point, we felt like it made the most sense to validate in our prototype that the rest of the rendering engine could be made to work on that as well. As Eric said and Mitz suggested, the ultimate underlying integral type is actually orthogonal to our next step of plumbing this abstraction through the render tree. Emil and I looked into what Firefox did. They did go with a fixed-point-esque approach where one of their units represents 1/96th of a pixel. That number should tell you something about when this work was done, and they were mostly concerned about performance. Using our floating point prototype, we saw ~1% slow down when laying out 100,000 elements, but we're also rounding far more in our unfinished prototype than we would in the final product. -L On Thu, Jun 23, 2011 at 11:54 AM, Peter Kasting wrote: > On Thu, Jun 23, 2011 at 11:46 AM, Levi Weintraub wrote: > >> 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. >> > > I thought Gecko eschewed floats in favor of some sort of more complex > fixed-point-esque system. Am I mistaken? > > I looked on the metabug to see if Hyatt had made comments, but didn't see > any. Do you have feedback from him yet? > > PK > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Switching away from integers for layout
On Jun 23, 2011, at 11:46 AM, Levi Weintraub 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. 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.___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Switching away from integers for layout
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 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@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Switching away from integers for layout
On Thu, Jun 23, 2011 at 11:46 AM, Levi Weintraub wrote: > 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. > I thought Gecko eschewed floats in favor of some sort of more complex fixed-point-esque system. Am I mistaken? I looked on the metabug to see if Hyatt had made comments, but didn't see any. Do you have feedback from him yet? PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Switching away from integers for layout
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@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
