On Feb 21, 2012, at 10:13 AM, Levi Weintraub wrote: Hi Dirk,
Inline: On Sat, Feb 18, 2012 at 9:44 PM, Dirk Schulze <dschu...@adobe.com<mailto:dschu...@adobe.com>> wrote: Hi Emil and Levi, I have a question to sub pixels from the SVG point of view. Right now a lot of content on renderers and also in RenderStyle uses LayoutPoint, LayoutSize, LayoutRect, Length… and so on. How would LayoutUnit deal with SVG's "float system"? Your Wiki says that SVG's float system stays unchanged. I assume that you mean that the source code of the SVG implementation will stay float based and not move to LayoutUnit. Is that correct? Currently, when SVG code queries the Render Tree it receives results as integers or floats. The only change we're making is to replace those integers with a subpixel unit. Things that were floats before will remain so (including all SVG layout), and we'll only increase precision in other places. I understand that. But if you look at RenderStyle::applyTransform() it takes LayoutSize. There are more examples like that. SVG could use some of these functions as well. That is why I hoped that LayoutSize and co could get more generic. Taking floats or integers and translating them to the needs of the addressor. But I understand the use case you are addressing. But this means we still have to use new functions to address the precision that is needed for SVG. Another question: It looks like Length.h/cpp switch to float values internally in your branch. Will that go to trunk as well? That would help us a lot on SVG. Currently I try to implement transform-origin for SVG. The function Length::calcFloatValue should take a float to calculate a length value on SVG elements. I just notice that some tests started to fail after that change. I couldn't verify the differences (lack of time). When will these changes land? Will the complete branch land as a package, or in smaller chunks? How long does it take to land these parts (I am primarily interested in the change of Length :))? Greetings, Dirk So my question is, if we use code of renderers or RenderStyle that would work on LayoutUnits, would we still be confronted with rounding to fixed point units? Or can LayoutUnit deal floats than? In SVG we would still like to have float based results, not rounded to fixed point, even if it is better than integer. This would be interesting for supporting 'transform-origin' and other CSS features in SVG. Maybe it is just a misunderstanding from me. Thanks for any clarification. LayoutUnits will not be floats, but we are not replacing things that were floats with LayoutUnits. LayoutUnits will be integers that represent 1/60th of a pixel, and you'll be able to convert floats to and from LayoutUnits when needed. There should not be any additional rounding in SVG or anywhere else than there is now. -Emil and Levi Greetings, Dirk _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org<mailto: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
