[webkit-dev] Subpixel Layout Update

[Levi Weintraub]

On Wed, Feb 22, 2012 at 6:15 PM, Dirk Schulze <dschulze at adobe.com> wrote:

>
> 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 <dschulze at 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 :))?
>

We do plan to land the Length change in trunk. We've been working on
landing as much of our patch as possible in chunks to insert the necessary
changes needed for when we switch the data type behind LayoutUnit. The
Length change will likely be one of the last changes we make in this
effort. If this is important to you, please consider helping to review our
patches :)

-Levi



>
> 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 at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120223/37f296f1/attachment.html>