[webkit-dev] Adding ENABLE_CONTACTS to WebCore

[김동관]

Hi webkit-dev!  

I wanted to let you know that I plan to add Contacts API support to WebKit.
This API is a new feature that is published by W3C.
The Device APIs Working Group of W3C has just released a Last Call Working 
Draft of its Contacts API:
http://www.w3.org/TR/2011/WD-contacts-api-20110616/

I'm going to commit patch for Contacts API implementation very soon.

This support will be behind the ENABLE_CONTACTS feature define. See:
https://bugs.webkit.org/show_bug.cgi?id=63223

We'll be setting up a buildbot to track then ENABLE_CONTACTS build shortly. We 
expect
this feature to be eventually enabled by all ports.  
Looking forward to your comments.

Thank you.

Donggwan
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Adding CSS3 font feature propreties

[Kenichi Ishibashi]

Hi webkit-dev,

I'm thinking about adding CSS3 font feature properties[1] support to WebKit.
 It allows page authors to control over advanced typographic features.
 Firefox has an experimental implementation and an article[2] shows how
these properties work.  I really would like to add this feature so I'd like
to ask comments and suggestions in advance.

My current plan is starting with adding the font-feature-settings property
(6.12 Low-level font setting control) as -webkit-font-feature-settings,
following a similar approach that Firefox did.  For OpenType fonts, other
properties can be treated as specific cases of the font-feature-settings
property and I think adding this property is good starting point.

One shortcomings of this approach is that it requires OpenType support for
each port.  A port which uses AAT might not be able to support this
property, or we need to add an extra text rendering subsystem which can
handle OpenType features to the port.

If I get started with this plan, I will start implementing css parsing part,
then implement font rendering part on a specific port (Chromium Linux port
is in mind for now) on trial.

I'd also like to put some notes of supporting CSS3 font feature properties
with AAT and CoreText here:
- AAT features are listed at [3].
- While the spec lists the equivalent OpenType feature tag for each
property, it is unclear that what AAT feature setting corresponds with each
property.  An email written by the spec editor[4] lists them partially but
not complehensive.
- [5] describes OpenType support of CoreText (I'm not sure this is correct,
though).

Comments and suggestions are highly appreciated.

[1] http://dev.w3.org/csswg/css3-fonts/#font-rend-props
[2] http://hacks.mozilla.org/2010/11/firefox-4-font-feature-support/
[3] http://developer.apple.com/fonts/registry/
[4] http://lists.w3.org/Archives/Public/www-style/2009Jun/0506.html
[5] http://en.wikipedia.org/wiki/OpenType_feature_tag_list

Regards,
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Implementing new WebSocket protocol

[イアンフェッティ]

FWIW it has settled down. The spec is in last call and isn't changing,
rather we're just arguing over wording, references in the spec, clarifying
text based on implementation experiences and ambiguities implementers have
found, etc.



On Thu, Jun 23, 2011 at 6:29 PM, Charles Pritchard  wrote:

> **
> That said, you're all lucky that the rest of us developers
> have no idea when the current round of specification flux
> will settle down.
>
> Security vulnerabilities will always trump the specs. Thanks for keeping on
> top of things.
>
> -Charles
>
>
> On 6/23/2011 5:16 PM, Ian Fette (イアンフェッティ) wrote:
>
> That said, I don't think the intent should be to support any old versions
> for any protracted amount of time. -00 has security vulnerabilities brought
> up by people on webkit-dev@ so from the Chrome side, we intend not to
> support -00 at all once we have -09 support available. All the makers of
> server-side code have already published versions compatibile with the latest
> draft, and IETF drafts are intended to expire after a fixed amount of time
> (-00 is already well past its expiration date).
>
>  -Ian
>
> On Thu, Jun 23, 2011 at 11:38 AM, Julian Reschke wrote:
>
>> On 2011-06-23 17:15, Simon Fraser wrote:
>>
>>> I'm surprised that the protocol has no facility for versioning. Is that
>>> really he case? Should it be considered for future versions of the spec?
>>>
>>
>>  It does.
>>
>> <
>> http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-09#section-11.11>
>>
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>
>
> ___
> webkit-dev mailing 
> listwebkit-dev@lists.webkit.orghttp://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
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Implementing new WebSocket protocol

[Charles Pritchard]

That said, you're all lucky that the rest of us developers
have no idea when the current round of specification flux
will settle down.

Security vulnerabilities will always trump the specs. Thanks for keeping 
on top of things.


-Charles

On 6/23/2011 5:16 PM, Ian Fette (イアンフェッティ) wrote:
That said, I don't think the intent should be to support any old 
versions for any protracted amount of time. -00 has security 
vulnerabilities brought up by people on webkit-dev@ so from the Chrome 
side, we intend not to support -00 at all once we have -09 support 
available. All the makers of server-side code have already published 
versions compatibile with the latest draft, and IETF drafts are 
intended to expire after a fixed amount of time (-00 is already well 
past its expiration date).


-Ian

On Thu, Jun 23, 2011 at 11:38 AM, Julian Reschke 
mailto:julian.resc...@gmx.de>> wrote:


On 2011-06-23 17:15, Simon Fraser wrote:

I'm surprised that the protocol has no facility for
versioning. Is that
really he case? Should it be considered for future versions of
the spec?


It does.





___
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


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Some questions about adobe air version webkit

[Brent Fulgham]

Hi Arno,

I'd like to be included in any discussion as well!

-Brent

On Jun 16, 2011, at 9:53 PM, Arno Gourdol wrote:

> Hi Wang,
> 
> We'll contact you off list and help you get sorted. If anyone else is 
> interested in the discussion on this mailing list, let us know.
> 
> – Arno
> 
> 
> 
> 
> On Jun 16, 2011, at 8:36 AM, wang chyz wrote:
> 
>> 1.   I compiled adobe air
>> webkit(http://download.macromedia.com/pub/opensource/webkit/webkit_dreamweavercs5_labs_01.zip)
>> on Windows, but it’s size reach to 10m, and Adobe compiled it to 4m,
>> can somebody give me any adives?
>> 2.   It seems the webkit version on above address is used in dreamwave
>> and some funtions are missing . How to download other version of air
>> webkit on http://webkit_view:webkit_v...@stlab.adobe.com:8080
>> ___
>> 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

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Implementing new WebSocket protocol

[イアンフェッティ]

That said, I don't think the intent should be to support any old versions
for any protracted amount of time. -00 has security vulnerabilities brought
up by people on webkit-dev@ so from the Chrome side, we intend not to
support -00 at all once we have -09 support available. All the makers of
server-side code have already published versions compatibile with the latest
draft, and IETF drafts are intended to expire after a fixed amount of time
(-00 is already well past its expiration date).

-Ian

On Thu, Jun 23, 2011 at 11:38 AM, Julian Reschke wrote:

> On 2011-06-23 17:15, Simon Fraser wrote:
>
>> I'm surprised that the protocol has no facility for versioning. Is that
>> really he case? Should it be considered for future versions of the spec?
>>
>
> It does.
>
>  section-11.11
> >
>
> __**_
> 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] Adding Persistent Position

[Darin Adler]

On Jun 23, 2011, at 2:43 PM, Ryosuke Niwa wrote:

> I think we need a PersistentPosition that auto-corrects itself and survives 
> DOM mutations without being orphaned; similar to how Range is automatically 
> updated.

I’m not sure that auto-correction has a simple unambiguous meaning. There are 
rules for what happens to Range objects when a document is modified, but I’m 
not sure they meet anyones expectations for “still representing the same 
position”.

> Why?
>   • ReplaceSelectionCommand and DeleteSelectionCommand have wrapper for 
> removeNode, deleteTextFromNode, etc... to update Positions they maintain.
>   • InsertListCommand and IndentOutdentCommand crash all the time because 
> Position get lost in moveParagraph, etc...
>   • FrameSelection has a special function that gets called whenever Node 
> is removed to update its end points but VisibleSelection doesn't so 
> endingSelection() becomes stale very easily compared to FrameSelection.

My main concern about this new class would be that it sounds a lot like Range 
and a lot like Position yet seems likely it won’t share much code with either.

I think that “Persistent” is not the right name for this. A normal Position 
works just fine. It sticks to the node it’s pointing to. The difference in the 
new class is that it sticks to something other than the node. What does it 
stick to? The document?

> On the other hand, adding this new class and instantiating them as member 
> variables of subclasses of CompositeEditCommand may impact performance 
> because CompositeEditCommand stays on the memory even after it's pushed into 
> undo stack.

Doesn’t seem likely to be a practical problem, but I could be wrong.

> Also, maintaining a pointer (probably from Document) to stack object 
> (although member variables of CompositeEditCommand will end up living in 
> heap) seems like a dangerous design

I don’t think that’s dangerous. It’s fine to have pointers into objects, 
whether on stack or heap, as long as they are maintained correctly, and 
disconnected when the objects are destroyed.

> To address the performance impact, we can modify CompositeEditCommand so that 
> it won't be added to the undo stack. Instead, CompositeEditCommand will 
> create an EditCommandComposition that stores a tree of SimpleEditCommands 
> that inherits from EditCommand and will be added to the undo stack.

This is a good change.

As I see it, a CompositeEditCommand is the “smarts” to do a command the first 
time, and should be deallocated as soon as the command has been executed. 
What’s saved behind for undo should be just a string of undoable editing steps, 
along with things like the command name for the undo menu item.

Long term I don’t think we need a tree of undoable editing steps. I suspect a 
vector of them will do fine.

But as an incremental step, I think it would be great to get the smarts for 
doing commands out of the tree completely. Your specific proposal sounds like a 
step in the right direction. Later the CompositeEditCommand classes would stop 
inheriting from EditCommand at all.

-- Darin

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Adding Persistent Position

[Ryosuke Niwa]

Hi,

I think we need a PersistentPosition that auto-corrects itself and survives
DOM mutations without being orphaned; similar to how Range is automatically
updated.

Why?

   1. ReplaceSelectionCommand and DeleteSelectionCommand have wrapper for
   removeNode, deleteTextFromNode, etc... to update Positions they maintain.
   2. InsertListCommand and IndentOutdentCommand crash all the time because
   Position get lost in moveParagraph, etc...
   3. FrameSelection has a special function that gets called whenever Node
   is removed to update its end points but VisibleSelection doesn't so
   endingSelection() becomes stale very easily compared to FrameSelection.


On the other hand, adding this new class and instantiating them as member
variables of subclasses of CompositeEditCommand may impact performance
because CompositeEditCommand stays on the memory even after it's pushed into
undo stack.  Also, maintaining a pointer (probably from Document) to stack
object (although member variables of CompositeEditCommand will end up living
in heap) seems like a dangerous design although we could make it ref-counted
as well.

To address the performance impact, we can modify CompositeEditCommand so
that it won't be added to the undo stack.  Instead, CompositeEditCommand
will create an EditCommandComposition that stores a tree of
SimpleEditCommands that inherits from EditCommand and will be added to the
undo stack.

Any thoughts?

Best,
Ryosuke Niwa
Software Engineer
Google Inc.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Inconsistency in logging approach

[Łukasz Ślachciak]

On 23.06.2011 22:16, Darin Adler wrote:
> But I’m surprised that GTK and EFL chose to leave logging on in releases.
>
>  -- Darin
>

They warn user with messaage sth like:
"WEBKIT_DEBUG is not empty, but this is a release build. Notice that 
many log messages will only appear in a debug build."


Of course to have logging working in GTK you need to turn off 
LOG_DISABLED macro in Assertions.h.


Regards

Lukasz Slachciak

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] API documentation in cpp files

[Łukasz Ślachciak]

W dniu 22.06.2011 18:27, Darin Adler pisze:

For WebKit API header files, files intended to be used by the clients of WebKit 
outside the project, I think your proposal makes sense. For an example of a 
header file in WebKit that is done in this way, you could look at 
JavaScriptCore/API/JSObjectRef.h.



I also think that for API files going to development packages should 
have some documentation.


Maybe for WebKit2 we could use consistent approach and for external API 
write documentation in header files?


Regards

Lukasz Slachciak
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Inconsistency in logging approach

[Darin Adler]

On Jun 23, 2011, at 1:12 PM, Łukasz Ślachciak wrote:

> Personally, I like approach of putting logging related code into  #if 
> !LOG_DISABLED macro instead of #ifndef NDEBUG.

As I remember it, my original design for LOG was:

1) Control with LOG_DISABLED, not NDEBUG.
2) Turn off for releases.
3) Feel free to do logging that might make things too slow in a release.
4) Give engineers a way to compile with logging on but leaving, say, 
assertions off.

Correcting the #if to use LOG_DISABLED would be going back to the original 
design.

But I’m surprised that GTK and EFL chose to leave logging on in releases.

-- Darin

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Inconsistency in logging approach

[Łukasz Ślachciak]

Hello All,

I would like to know what do you think about Logging in Release build.
Should WebKit allow it?

Currently it is not possible because some features (like IconDatabase) 
use #ifndef NDEBUG for marking LOG macro related code.
From the other hand in WebKit2 all logging is based on the #if 
!LOG_DISABLED macro.


Ports approach to logging in Release builds is not consistent too:
- GTK and EFL allows to use LOG in Release
- Qt it is not possible

Personally, I like approach of putting logging related code into  #if 
!LOG_DISABLED macro instead of #ifndef NDEBUG.


I prepared small patch to allow building WebKit in Release build and use 
logging. I'll open ticket in bugzilla, but first I would like to know 
your opinion about this idea.


Regards

Lukasz Slachciak
___
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

[Levi Weintraub]

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

[Dan Bernstein]

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

[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  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

[Peter Kasting]

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

[Levi Weintraub]

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

Re: [webkit-dev] Implementing new WebSocket protocol

[Julian Reschke]

On 2011-06-23 17:15, Simon Fraser wrote:

I'm surprised that the protocol has no facility for versioning. Is that
really he case? Should it be considered for future versions of the spec?


It does.


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Implementing new WebSocket protocol

[Simon Fraser]

I'm surprised that the protocol has no facility for versioning. Is that really 
he case? Should it be considered for future versions of the spec?

Simon

On Jun 23, 2011, at 6:07 AM, Yuta Kitamura wrote:

> There seems to be no strong objection to adding a runtime flag, and I think 
> it will take some time and need multiple patches to get the implementation in 
> good shape. Therefore, I'd like to start to implement behind a runtime flag. 
> It allows each port to control the time to switch protocols, too (of course 
> all ports should be migrated eventually).
> 
> As a starting point, could somebody review a patch in bug 60348 
> (http://webkit.org/b/60348), which only adds a flag?
> 
> Regards,
> Yuta
> ___
> 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] Implementing new WebSocket protocol

[Yuta Kitamura]

There seems to be no strong objection to adding a runtime flag, and I think
it will take some time and need multiple patches to get the implementation
in good shape. Therefore, I'd like to start to implement behind a runtime
flag. It allows each port to control the time to switch protocols, too (of
course all ports should be migrated eventually).

As a starting point, could somebody review a patch in bug 60348 (
http://webkit.org/b/60348), which only adds a flag?

Regards,
Yuta
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev