Re: [webkit-dev] [blink-dev] FOSDEM 2015 Desktops DevRoom Call for Talks

[Levi Weintraub]

Please don't send advertisements or cross-post to these lists.

Thanks,
/L/

On Mon, Oct 27, 2014 at 1:00 PM, Pau Garcia i Quiles 
wrote:

> Hello,
>
> --8<---
>
> FOSDEM  is one of the largest gatherings of Free
> Software contributors in the world and happens each February in Brussels
> (Belgium). One of the tracks will be the Desktops DevRoom (formerly known
> as “CrossDesktop DevRoom”), which will host Desktop-related talks.
>
> We are now inviting proposals for talks about Free/Libre/Open-source
> Software on the topics of Desktop development, Desktop applications and
> interoperability amongst Desktop Environments. This is a unique opportunity
> to show novel ideas and developments to a wide technical audience.
>
> Topics accepted include, but are not limited to: Enlightenment, Gnome,
> KDE, Unity, XFCE, LXQt, Windows, Mac OS X, software development for the
> desktop, general desktop matters, applications that enhance desktops and
> web (when related to desktop).
>
> Talks can be very specific, such as the advantages/disadvantages of
> development with Qt on Wayland over X11/Mir; or as general as predictions
> for the fusion of Desktop and web in 5 years time. Topics that are of
> interest to the users and developers of all desktop environments are
> especially welcome. The FOSDEM 2014 schedule
>  might give you
> some inspiration.
>
> Please include the following information when submitting a proposal:
>
>- Your name
>- The title of your talk (please be descriptive, as titles will be
>listed with around 250 from other projects)
>- Short abstract of one or two paragraphs
>- Short bio (with photo)
>- Requested time: from 15 to 45 minutes. Normal duration is 30
>minutes. Longer duration requests must be properly justified. You may be
>assigned LESS time than you request.
>
> The deadline for submissions is December 7th 2014. FOSDEM will be held on
> the weekend of January 31st-February 1st 2015 and the Desktops DevRoom will
> take place on Sunday, February 1st 2015. Please use the following website
> to submit your proposals: https://penta.fosdem.org/submission/FOSDEM15
> (you do not need to create a new Pentabarf account if you already have one
> from past years).
>
> You can also join the devroom’s mailing list, which is the official
> communication channel for the DevRoom: desktops-devr...@lists.fosdem.org
>  (subscription page
>  for the mailing list)
>
> – The Desktops DevRoom 2015 Organization Team
>
> --8<---
>
>
> --
> Pau Garcia i Quiles
> http://www.elpauer.org
> (Due to my workload, I may need 10 days to answer)
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Compiling WebKit up to 25% faster in Windows?

[Levi Weintraub]

+1. I also like that this will make layering violations clearer.


On Tue, Mar 26, 2013 at 1:53 PM, Filip Pizlo  wrote:

>
> On Mar 26, 2013, at 1:40 PM, Dirk Pranke  wrote:
>
> On Tue, Mar 26, 2013 at 1:29 PM, Benjamin Poulain 
> wrote:
>
>> On Tue, Mar 26, 2013 at 1:20 PM, Dirk Pranke  wrote
>>
>>> If we have consensus that we should just switch to paths relative to
>>> Source (or maybe a couple different options), that would be (IMO) a big
>>> win. It sounds like Daniel & co. have already done the big bang conversion.
>>>
>>
>> I think using full path would be a serious hit regarding hackability.
>>
>> I would rather spend some time tweaking my compiler to cache each
>> directory content than waste time finding where is every single header I
>> need to include.
>>
>>
> Interesting. I have the exact opposite experience, having to paw around to
> figure out where "Font.h" actually lives rather than just seeing
> "WebCore/platform/graphics/Font.h".
>
> At any rate, to be clear, I would be in favor of that change but I'm not
> expecting it to happen :).
>
>
> I'm with Dirk on this.  Full path would help hackability for me.
>
> I don't use an IDE, so I'll be typing more.  But I spend more time reading
> code than typing code.
>
> Also we have a lot of stupid in header file naming right now.  For example
> the DFG calls the JSC::DFG::Node header "DFGNode.h", and puts it in
> JavaScriptCore/dfg/DFGNode.h.  So we duplicate the namespacing of
> JSC::DFG::Node in both the filename and the directory name.  Ridiculous!
>  If we had a discipline to always include using paths relative to Source,
> then we could just rename it to JavaScriptCore/dfg/Node.h.  That would make
> me happy.
>
> -F
>
>
>
>
> -- Dirk
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Please don't leave entries for rebaseline in TestExpectation files

[Levi Weintraub]

I wish I could explicitly set an entry as being intended to be rebaselined,
then notified (by email, by webkit-patch, something) when the tests covered
by that entry have ran through all the bots with a url that shows the
results so I can quickly validate them. In this magic world, if the results
are correct, there'd simply be a button that would auto-generate a patch
and toss it in the commit queue.



On Thu, Mar 21, 2013 at 11:16 AM, Ryosuke Niwa  wrote:

> On Thu, Mar 21, 2013 at 10:54 AM, Žan Doberšek wrote:
>
>> On Thu, Mar 21, 2013 at 5:18 PM, Robert Hogan wrote:
>>
>>> On Thursday, 21 March 2013, Ryosuke Niwa wrote:
>>>
 On Thu, Mar 21, 2013 at 1:31 AM, Robert Hogan wrote:

> On Thursday, 21 March 2013, Ryosuke Niwa wrote:
>
>>  I used to pull results from the bots where possible but creating
>>> inconsistency between png/text results is not good.
>>>
>>
>> It is unfortunate but it's much better than losing the complete test
>> coverage.
>>
>
> If that's the case then I'm happy to land whatever garden-o-matic
> pulls in or I can sweep from the bots, even if it means that png results
> for Mac, Qt, et al. go bad as a result.
>
> I guess we will always have ports whose bots do not run pixel tests so
> if those ports are happy to live with the downsides of doing that then
> there really is no obstacle to authors owning the job of updating the
> baselines for all ports when they land a change.
>
> IMHO ports who don't run pixel tests would be better off deleting any
> png results they have in the tree. Is there a reason Mac hasn't done that?
> Don't you get lots of failures when you run pixel tests locally?
>

 Yes, but I'd argue that it's better than losing the test coverage.

 By the way, we can easily address this problem by always generating
 pixel results for unexpectedly failing tests. Namely, we can force --pixel
 when we're retrying tests.


>>> Perhaps NRWT could produce txt and png results for all tests marked with
>>> REBASELINE or similar in TestExpectations. That would avoid the need to
>>> turn the bots red on each platform for at least one build cycle.
>>>
>>
>> I like this specific proposal. There's already a similar expectation
>> planned, 'NeedsRebaseline'.
>> https://bugs.webkit.org/show_bug.cgi?id=100415
>>
>
> How do we know that new results is correct prior to running tests on each
> platform/port?  There are cases where we regress tests on some ports while
> needing to rebaseline on other ports but all of that is unknown until we
> actually run tests on the bots.
>
> - R. Niwa
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Elliot Sprehn is now a reviewer

[Levi Weintraub]

Congrats sir!!


On Mon, Mar 11, 2013 at 3:46 PM, Eric Seidel  wrote:

> May our generated content (and general render safety and speed) live
> long and prosper. :)
>
> Grats Elliot!
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Philip Rogers is now a Reviewer

[Levi Weintraub]

Congratulations, Mr. Rogers!


On Thu, Feb 28, 2013 at 12:09 PM, Eric Seidel  wrote:

> Nice to have another hand for SVG reviews. :)
>
> Grats to pdr!
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] New WebKit reviewer: Stephen Chenney

[Levi Weintraub]

Here here! Congratulations!


On Wed, Feb 20, 2013 at 2:36 PM, Philip Rogers  wrote:

> This is fantastic. Congratulations Stephen!
>
>
> On Wed, Feb 20, 2013 at 2:34 PM, Dirk Schulze  wrote:
>
>> Hi WebKit folks,
>>
>>
>> It is a pleasure to announce that Stephen Chenney 
>> is a WebKit Reviewer now.
>>
>>
>> Stephen did and does an awesome job on various SVG, Font and Skia related
>> topics. He fixed at least a dozen of urgent security bugs and has a great
>> understanding of the WebCore code base.
>>
>> Please join me in congratulating Stephen for his new status!
>>
>>
>> Greetings,
>>
>> Dirk
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>
>>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] css: rotateY(90) with perspective()

[Levi Weintraub]

Either way, I'd suggest you take this conversation to a specific bug report
:)


On Tue, Feb 12, 2013 at 11:49 AM, Shawn Singh wrote:

> Hi Marcin,
>
> I wonder if you might accidentally have a "perspective-origin" set
> differently?  Or maybe there is something in your code where window size
> that affects how the transforms appear?  Maybe you can attach a reduced
> simple example of the difference you're seeing?   I just whipped up the
> following example, which renders almost exactly the same geometry on both
> Firefox and tip-of-tree Chromium.
>
> 
>   
> HELLO WORLD
>   
> 
>
>
> Changing the rotateY to use 90deg makes the layer disappear for both
> Firefox and Chromium, too.
>
> ~Shawn
>
>
>
>
> On Tue, Feb 12, 2013 at 9:53 AM, Dana Jansens  wrote:
>
>> +shawnsingh
>>
>>
>> On Tue, Feb 12, 2013 at 9:22 AM, Marcin Szamotulski wrote:
>>
>>> Dear WebKit-Dev,
>>>
>>> I found an interesting difference between implementation of css 3d
>>> transforms in Gecko (FireFox) and Chromium (WebKit).  In Gecko, the
>>> following css rule:
>>>
>>> tranform: perspective(500px) rotateY(90)
>>>
>>> rotates an element (let say an image) so that it is perpendicular to the
>>> viewer, i.e. it shows the side of the element - hence nothing is printed
>>> to the screen, since html elements have no depth.  While in WebKit based
>>> browsers (I have tested this in both Chromium and surf from suckles.org)
>>> the elements is shown at an angle: both rotations (Gecko & WebKit) have
>>> the same axis (the vertical screen directions).  Testing different
>>> angles I have found that I need to use rotateY(107deg), but this might
>>> depend on the perspective.   The reason for this is that WebKit and
>>> Gecko are computing 3d view in a different way.  The additional minor
>>> difference is that rotateY(30deg) in Gecko turns an element 30deg to the
>>> right while in WebKit it rotates to the left (with a different 3d view).
>>> The reason I found it is because I try to make an animation which turns
>>> a picture around 180deg showing a new picture on the other side, and
>>> I wanted to change the picture in the middle (90deg).  This works for
>>> Gecko but for WebKit I need to know how to compute the angle at which
>>> the element (image) is perpendicular to the view source (showing its
>>> side to the viewer).  Can somebody point me how the 3d rotationY with
>>> a given perspective is calculated so I can make the necessary
>>> converstion.
>>>
>>> Best regards,
>>> Marcin Szamotulski
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>>
>>
>>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Adding Web MIDI API support to WebCore

[Levi Weintraub]

I see that this is intended to go in as a "module". My understanding is
that concept was created to allow this sort of thing with minimal impact to
core functionality.


On Fri, Jan 18, 2013 at 2:15 PM, Steve Williams <
stephen.j.h.willi...@googlemail.com> wrote:

> Implement as a dynamic/shared library plugin then whoever wants it gets it
> & there's minimal bloat for those who don't.
>
>
> On 18/01/2013 19:51, Maciej Stachowiak wrote:
>
>> Some questions:
>>
>> - Are any other browser engines planning to implement this? (I couldn't
>> tell from looking at the public-au...@w3.org archives).
>> - Is this API useful in any way for users who do not have specialized and
>> somewhat uncommon hardware devices?
>>
>> Regards,
>> Maciej
>>
>> On Jan 18, 2013, at 2:51 AM, Takashi Toyoshima 
>> wrote:
>>
>>  Hi webkit-dev,
>>>
>>> I want to let you know that I plan to add Web MIDI API support to WebKit.
>>> This support will be behind the ENABLE_WEB_MIDI feature define.
>>>
>>> See the master bug for Web MIDI API:
>>> https://bugs.webkit.org/show_**bug.cgi?id=107250
>>>
>>> I'll enable this feature in Chromium port once the implementation
>>> becomes ready for that.
>>>
>>> Thanks,
>>> __**_
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> http://lists.webkit.org/**mailman/listinfo/webkit-dev
>>>
>> __**_
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/**mailman/listinfo/webkit-dev
>>
>>
> __**_
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/**mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Keeping up with new additions to canvas

[Levi Weintraub]

The best way to watch changes to specific features in WebKit is by adding
yourself to a WatchList: http://trac.webkit.org/wiki/WatchList

-Levi


On Mon, Jan 7, 2013 at 8:47 AM, Dirk Schulze  wrote:

>
> On Jan 7, 2013, at 4:18 AM, RGraph.net support 
> wrote:
>
> > Hi,
> >
> > Is watching this mailing list the best way to keep up-to-date with new
> > additions to the WebKit canvas implementation (such as the canvas Path
> > object or hit regions)? Or perhaps there's an  announcements list too?
>
> Bigger new features like Path or hit region proposals need to get
> pronounced on this list. Smaller improvements (bug fixes) are not
> necessarily announced. There is no separate list beside webkit-changes for
> all changes to WebKit.
>
> Greetings,
> Dirk
>
> >
> > Thanks!
> >
> > --
> > Richard
> > ___
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo/webkit-dev
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Int/FloatPoint and Int/FloatSize

[Levi Weintraub]

Hi Steve,

When converting the old tx/ty paint offsets to use IntPoint and IntSize
(later LayoutPoint/Size) we had some discussion around this. Darin Adler
wrote some good advice here:
https://bugs.webkit.org/show_bug.cgi?id=61562#c2 -- quoting:
"It’s hard to tell points and sizes apart when we have nested coordinate
systems. The distance from the top left to a rect is a “size”, yet it’s
expressed as an origin point. I think that whenever we can’t decide, we
should use IntPoint, and we should use IntSize only when it’s clearly the
size of something, not just a distance (a point described relative to
another point)."

Cheers,
-Levi


On Wed, Jan 2, 2013 at 11:21 PM, Steve Block wrote:

> Hi webkit,
>
> I was hoping that somebody could clarify the policy regarding the
> correct use of Int/FloatPoint vs Int/FloatSize.
>
> It seems that xxxPoint is consistently used to represent a position,
> which makes sense. However, when representing the position of one
> point relative to another, both xxxPoint and xxxSize are used, which
> seems inconsistent. I'd expect that xxxPoint should be used for this
> case of a relative position, since its x(), y() and length() methods
> make more sense than the width() and height() methods of xxxSize.
> However, the operators [1] for subtracting one xxxPoint from another
> encourage the use of xxxSize. I recognize that in some situations, you
> need really do want to represent the difference between two points as
> an area or size, but this seems the less common case, and it might be
> better to make it more explicit [2].
>
> My questions are ...
> - What (if any) is the correct policy?
> - Would people welcome changes to encourage that policy?
>
> Thanks,
> Steve
>
> [1] eg 'inline FloatSize operator-(const FloatPoint&, const FloatPoint&)'
> [2] Perhaps something like 'static FloatSize
> FloatSize::fromCornerPoints(const FloatPoint&, const FloatPoint&)'.
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Allan Sandfeld Jensen is now a WebKit reviewer!

[Levi Weintraub]

Congrats Allan! :)


On Fri, Dec 21, 2012 at 8:13 AM, Kenneth Rohde Christiansen <
kenneth.christian...@gmail.com> wrote:

> Congrats Allan!
>
> On Fri, Dec 21, 2012 at 5:09 PM, Turcotte Jocelyn <
> jocelyn.turco...@digia.com> wrote:
>
>>   Before joining WebKit a year ago, Allan was spending some of his free
>> time hacking on KHTML. Since then he has been contributing in various areas
>> of the Qt port, WebKit2 and WebCore, including touch adjustment and hit
>> testing.
>>
>> Please join me in congratulating Allan on his new role as a
>> WebKit reviewer!
>> - Jocelyn
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo/webkit-dev
>>
>>
>
>
> --
> Kenneth Rohde Christiansen
> Senior Engineer, WebKit, Qt, EFL
> Phone  +45 4093 0598 / E-mail kenneth at webkit. org
>
> ﹆﹆﹆
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] New WebKit reviewer: Gyuyoung Kim

[Levi Weintraub]

Congrats!!

On Tue, Aug 21, 2012 at 7:05 AM, Soo-Hyun Choi  wrote:

> Good stuff and congratulations, Gyuyoung!
>
>
> Soo-Hyun
>
>
>
> Kenneth Rohde Christiansen wrote:
>
>> I’m pleased to announce that Gyuyoung Kim is now a WebKit reviewer.
>>
>> Gyuyoung joined the WebKit team as part of an effort to port WebKit to
>> the EFL platform. Since then he has taken leadership of the Samsung
>> activities in WebKit trunk and helped integrating his team members in
>> the community and community practices. Lately, Gyuyoung have been
>> focused on adding device API's to WebKit, as well as refocusing the
>> EFL efforts on WebKit2.
>>
>> Please join me in congratulating him in his new WebKit reviewer role.
>>
>>  __**_
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/**mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] bugs.webkit.org and trac.webkit org down?

[Levi Weintraub]

We're back!

On Fri, Aug 10, 2012 at 8:07 AM, Peter Beverloo  wrote:

> It's been down for the past hour, again.  Just a nudge in case it slipped
> through.
>
> Peter
>
>
> On Thu, Aug 9, 2012 at 10:41 AM, Osztrogonac Csaba 
> wrote:
>
>> Hi,
>>
>> bugs.webkit.org and trac.webkit.org is unavailable again. :(
>> Could you check it, please?
>>
>> br,
>> Ossy
>>
>> Osztrogonac Csaba írta:
>>
>>  It seems bugs.webkit.org and trac.webkit.org is unavailable
>>> now. (at least from Hungary) Have you got any idea what happened?
>>>
>> __**_
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/**mailman/listinfo/webkit-dev
>>
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] bugs.webkit.org returning 500 errors

[Levi Weintraub]

I'm getting Internal Server Errors accessing anything in bugs.webkit.org.

TGIF I guess? :)
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] offsetWidth/Height/Left/Top int to float

[Levi Weintraub]

Hey Ion,

A few things...
- We didn't actually switch to floats for Layout, but with sub-pixel layout
enabled, we use integers that represent 1/60th of a pixel instead of one
(similar to Gecko).
- The CSSOM defines those properties to be longs
http://dev.w3.org/csswg/cssom-view/#extensions-to-the-htmlelement-interfaceso
changing this would violate the spec and potentially lead to
web-compat
issues.
- You can get floating-point-level precision values by using
getClientBoundingRect().
- IE uses a flag that switches between ints and floats. I don't advocate
this option (I think it adds complexity and doesn't solve a problem that
can't be solved using getClientBoundingRect) but it at least avoids web
compat issues.
http://msdn.microsoft.com/en-us/library/ie/hh673543(v=vs.85).aspx

Hope that helps,
-Levi

On Mon, Jun 18, 2012 at 7:56 AM, Ion Rosca  wrote:

> Hello,
>
> ** **
>
> I have some questions regarding zooming and offsetWidth/Height/Top/Left*.
> *
>
> Currently, Element.offset* properties return imprecise values when zooming
> in/out. One of the bugs describing this problem would be Issue 104074:
> offsetWidth of element is shrinking when zooming 
> in<http://code.google.com/p/chromium/issues/detail?id=104074>with a simple 
> test
> case <http://jsfiddle.net/V4HQc/>. 
>
> The product I’m working on also embeds WebKit and it would really need
> more precision from Element.offset*. We’ve done some testing by making
> offset*s to return floats and this approach appears to improve precision a
> lot.
>
> ** **
>
> I found in 
> archive<http://lists.webkit.org/pipermail/webkit-dev/2011-June.txt>an email 
> from
> *Levi Weintraub *, sent in June 2011, saying:
>
> *… 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]<https://bugs.webkit.org/show_bug.cgi?id=54018>
> .*
>
> The meta bug 60318 <https://bugs.webkit.org/show_bug.cgi?id=60318>  (*Switch
> away from integers …)* Levi was working on is already fixed and the inner
> bugs (addressing this problem) bug 
> 54018<https://bugs.webkit.org/show_bug.cgi?id=54018>
> * (Make offset* return doubles instead of ints) *and* *bug 
> 39884<https://bugs.webkit.org/show_bug.cgi?id=39884>
> * - Full Page Zoom: rounding errors with element metrics *are still
> opened and theirs resolution is not clear.
>
> ** **
>
> What’s your opinion on this subject? Were there some other discussions on
> it I couldn’t find? Is there a chance for making offset properties
> returning floats to be accepted? What are the implications of making this
> change in terms of specifications?
>
> ** **
>
> Thank you,
>
> Ion Rosca
>
> ___
> 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] FYI: sub-pixel layout landing soon

[Levi Weintraub]

Given the concerns brought up, we'll be adding an ENABLE_SUBPIXEL_LAYOUT
flag that will default to on. Turning this off will continue to use
FractionalLayoutUnits, but the fraction will switch to 1/1 from the default
of 1/60. This should be ready in the near future, and we'll provide another
heads-up when we're again ready to land.

-Levi

On Mon, Apr 23, 2012 at 2:55 PM, Maciej Stachowiak  wrote:

>
> If it's a global switch that ports can't opt out of, then we have to do
> this at a time when it wouldn't disrupt anyone's release cycle. Let's say
> hypothetically a vendor was going to branch from trunk and ship in two
> weeks (not actually the case for us, but just to make it an extreme
> example). It would be insane for them to take this change. So we need one
> of the following:
>
> (1) It needs to be compile-time switchable so that vendors who are close
> to shipping can turn it on to mitigate risk without having to roll back to
> earlier on trunk.
> OR
> (2) We need up-front buy-in from all vendors who ship from the open source
> tree that now is a reasonable time for them to make such a major change.
>
> Regards,
> Maciej
>
>
> On Apr 23, 2012, at 2:48 PM, Levi Weintraub wrote:
>
> Supporting this would be very logistically intensive and error prone.
> Beyond huge test expectation differences, hacking on the rendering engine
> could easily result in bugs in one path or the other.
>
> -Levi
>
> On Mon, Apr 23, 2012 at 2:31 PM, Adele Peterson  wrote:
>
>> Is there an if-def ports can use if they don't want this on by default?
>>
>>  - Adele
>>
>> On Apr 23, 2012, at 2:15 PM, Levi Weintraub wrote:
>>
>> WebKittens and Unlucky Sheriffs
>>
>> We intend to flip the switch on sub-pixel layout tomorrow morning PST. We
>> apologize in advance for any breakages. See
>> https://trac.webkit.org/wiki/LayoutUnit and http://webkit.org/b/60318for 
>> reference, and feel free to contact Emil (eae) or me (leviw) with any
>> questions.
>>
>> Happy zooming!
>>
>> -Emil and Levi
>> ___
>> 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] FYI: sub-pixel layout landing soon

[Levi Weintraub]

Supporting this would be very logistically intensive and error prone.
Beyond huge test expectation differences, hacking on the rendering engine
could easily result in bugs in one path or the other.

-Levi

On Mon, Apr 23, 2012 at 2:31 PM, Adele Peterson  wrote:

> Is there an if-def ports can use if they don't want this on by default?
>
> - Adele
>
> On Apr 23, 2012, at 2:15 PM, Levi Weintraub wrote:
>
> WebKittens and Unlucky Sheriffs
>
> We intend to flip the switch on sub-pixel layout tomorrow morning PST. We
> apologize in advance for any breakages. See
> https://trac.webkit.org/wiki/LayoutUnit and http://webkit.org/b/60318 for
> reference, and feel free to contact Emil (eae) or me (leviw) with any
> questions.
>
> Happy zooming!
>
> -Emil and Levi
> ___
> 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] FYI: sub-pixel layout landing soon

[Levi Weintraub]

WebKittens and Unlucky Sheriffs

We intend to flip the switch on sub-pixel layout tomorrow morning PST. We
apologize in advance for any breakages. See
https://trac.webkit.org/wiki/LayoutUnit and http://webkit.org/b/60318 for
reference, and feel free to contact Emil (eae) or me (leviw) with any
questions.

Happy zooming!

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

Re: [webkit-dev] Git/SVN is slow

[Levi Weintraub]

Likewise in Mountain View... it's making WebKit gardening impossible :(

On Thu, Mar 15, 2012 at 2:03 PM, Dmitry Titov  wrote:

> over here in Seattle I am getting 5KiB/s all day, no way to get an updated
> checkout today :-(
>
>
> On Thu, Mar 15, 2012 at 10:54 AM, Jarred Nicholls wrote:
>
>> Well I was just about to follow up that from the east coast on Comcast
>> bbone, I'm pulling at acceptable rates from git.webkit.org, ~700KiB/s.
>>  That's about as fast as it's always been.  Same goes for
>> nightly.webkit.org.
>>
>> There's a number of possible issues that would result in slow response
>> times and slow downloads.  E.g., it could be sheer packet loss between
>> carrier backbones and not necessarily tapped bandwidth.
>>
>>
>> On Thu, Mar 15, 2012 at 1:45 PM, Ryosuke Niwa  wrote:
>>
>>> I don't really think checking the latency is interesting. What's killing
>>> us is bandwidth. As far as I tested yesterday, the ping at my work (Google
>>> SF office) gives me a reasonable time as well.
>>>
>>> There's something that's killing our bandwidth. Does anyone know some
>>> tools to investigate this?
>>>
>>> - Ryosuke
>>>
>>>
>>> On Thu, Mar 15, 2012 at 10:40 AM, Jarred Nicholls wrote:
>>>
>>>> Ditto, @ ae-11-70 attempting to get to ae-21-60 the trace dies.  Pings
>>>> to svn.webkit.org succeed in acceptable times however, for me.
>>>>  Perhaps the hops following ae-11-70 and ae-21-60 simple aren't able to
>>>> reply with proper ICMP packets; no real conclusion to based on that info
>>>> alone, but maybe worth passing off to the provider and/or directly to
>>>> Level3.
>>>>
>>>> Jarred
>>>>
>>>>
>>>> On Thu, Mar 15, 2012 at 1:22 PM, Levi Weintraub wrote:
>>>>
>>>>> Likewise, I lose everything past *.car1.sanjose2.level3.net. SVN
>>>>> updates are dog slow :(
>>>>>
>>>>>  6  pr01-xe-8-2-0.sjc07.net.google.com (72.14.218.230)  4.306 ms
>>>>>  4.966 ms *
>>>>>  7  xe-11-1-0.edge2.sanjose3.level3.net (4.79.40.153)  20.116 ms
>>>>>  3.031 ms  3.056 ms
>>>>>  8  ae-31-90.car1.sanjose2.level3.net (4.69.152.203)  4.316 ms
>>>>> ae-11-70.car1.sanjose2.level3.net (4.69.152.75)  4.239 ms
>>>>> ae-21-60.car1.sanjose2.level3.net (4.69.152.11)  4.545 ms
>>>>>  9  * * *
>>>>> 10  * * *
>>>>> 11  * * *
>>>>>
>>>>>
>>>>> On Thu, Mar 15, 2012 at 7:31 AM, Philip Rogers  wrote:
>>>>>
>>>>>> Bill,
>>>>>>
>>>>>> I'm currently pulling from svn.webkit.org at what feels like 5kbps,
>>>>>> and poor http://build.webkit.org/console hits the page refresh
>>>>>> before it's even able to render to the bottom :(
>>>>>>
>>>>>> Below is a traceroute to webkit.org:
>>>>>> traceroute to svn.webkit.org (17.254.20.241), 30 hops max, 60 byte
>>>>>> packets
>>>>>>   1  DD-WRT (192.168.2.1)  0.233 ms  0.297 ms  0.371 ms
>>>>>>  2  10.1.10.1 (10.1.10.1)  2.446 ms  2.445 ms  2.518 ms
>>>>>>  3  96.176.191.1 (96.176.191.1)  24.451 ms  25.398 ms  28.688 ms
>>>>>>  4  xe-11-0-0-0-sur01.a2atlanta.ga.atlanta.comcast.net(68.85.91.177)  
>>>>>> 14.588 ms  15.541 ms  15.733 ms
>>>>>>  5  xe-2-1-3-0-ar01.b0atlanta.ga.atlanta.comcast.net (68.86.106.57)
>>>>>>  16.563 ms  16.929 ms  16.946 ms
>>>>>>  6  pos-3-6-0-0-cr01.atlanta.ga.ibone.comcast.net (68.86.93.201)
>>>>>>  17.967 ms pos-3-5-0-0-cr01.atlanta.ga.ibone.comcast.net(68.86.93.125)  
>>>>>> 14.599 ms  11.428 ms
>>>>>>  7  4.28.24.77 (4.28.24.77)  15.973 ms  17.858 ms  17.307 ms
>>>>>>  8  vlan51.ebr1.Atlanta2.Level3.net (4.69.150.62)  19.688 ms
>>>>>> vlan52.ebr2.Atlanta2.Level3.net (4.69.150.126)  14.891 ms
>>>>>> vlan51.ebr1.Atlanta2.Level3.net (4.69.150.62)  15.116 ms
>>>>>>  9  ae-73-73.ebr3.Atlanta2.Level3.net (4.69.148.253)  14.651 ms
>>>>>> ae-63-63.ebr3.Atlanta2.Level3.net (4.69.148.241)  13.767 ms
>>>>>> ae-73-73.ebr3.Atlanta2.Level3.net (4.69.148.253)  14.955 ms
>>>>>> 10  ae-7-7.ebr3.Dallas1.Level3.net (4.69.134.21)  34.004 ms  36.807
>>>>>> m

Re: [webkit-dev] Git/SVN is slow

[Levi Weintraub]

Likewise, I lose everything past *.car1.sanjose2.level3.net. SVN updates
are dog slow :(

 6  pr01-xe-8-2-0.sjc07.net.google.com (72.14.218.230)  4.306 ms  4.966 ms *
 7  xe-11-1-0.edge2.sanjose3.level3.net (4.79.40.153)  20.116 ms  3.031 ms
 3.056 ms
 8  ae-31-90.car1.sanjose2.level3.net (4.69.152.203)  4.316 ms
ae-11-70.car1.sanjose2.level3.net (4.69.152.75)  4.239 ms
ae-21-60.car1.sanjose2.level3.net (4.69.152.11)  4.545 ms
 9  * * *
10  * * *
11  * * *


On Thu, Mar 15, 2012 at 7:31 AM, Philip Rogers  wrote:

> Bill,
>
> I'm currently pulling from svn.webkit.org at what feels like 5kbps, and
> poor http://build.webkit.org/console hits the page refresh before it's
> even able to render to the bottom :(
>
> Below is a traceroute to webkit.org:
> traceroute to svn.webkit.org (17.254.20.241), 30 hops max, 60 byte packets
>   1  DD-WRT (192.168.2.1)  0.233 ms  0.297 ms  0.371 ms
>  2  10.1.10.1 (10.1.10.1)  2.446 ms  2.445 ms  2.518 ms
>  3  96.176.191.1 (96.176.191.1)  24.451 ms  25.398 ms  28.688 ms
>  4  xe-11-0-0-0-sur01.a2atlanta.ga.atlanta.comcast.net (68.85.91.177)
>  14.588 ms  15.541 ms  15.733 ms
>  5  xe-2-1-3-0-ar01.b0atlanta.ga.atlanta.comcast.net (68.86.106.57)
>  16.563 ms  16.929 ms  16.946 ms
>  6  pos-3-6-0-0-cr01.atlanta.ga.ibone.comcast.net (68.86.93.201)  17.967
> ms pos-3-5-0-0-cr01.atlanta.ga.ibone.comcast.net (68.86.93.125)  14.599
> ms  11.428 ms
>  7  4.28.24.77 (4.28.24.77)  15.973 ms  17.858 ms  17.307 ms
>  8  vlan51.ebr1.Atlanta2.Level3.net (4.69.150.62)  19.688 ms
> vlan52.ebr2.Atlanta2.Level3.net (4.69.150.126)  14.891 ms
> vlan51.ebr1.Atlanta2.Level3.net (4.69.150.62)  15.116 ms
>  9  ae-73-73.ebr3.Atlanta2.Level3.net (4.69.148.253)  14.651 ms
> ae-63-63.ebr3.Atlanta2.Level3.net (4.69.148.241)  13.767 ms
> ae-73-73.ebr3.Atlanta2.Level3.net (4.69.148.253)  14.955 ms
> 10  ae-7-7.ebr3.Dallas1.Level3.net (4.69.134.21)  34.004 ms  36.807 ms
>  34.950 ms
> 11  ae-3-3.ebr2.LosAngeles1.Level3.net (4.69.132.77)  66.601 ms  65.766
> ms  66.692 ms
> 12  ae-6-6.ebr2.SanJose5.Level3.net (4.69.148.202)  78.577 ms  78.007 ms
>  78.175 ms
> 13  ae-1-100.ebr1.SanJose5.Level3.net (4.69.148.109)  78.594 ms  78.520
> ms ae-5-5.ebr4.SanJose1.Level3.net (4.69.148.142)  81.371 ms
> 14  ae-34-34.ebr2.SanJose1.Level3.net (4.69.153.33)  71.989 ms
> ae-5-5.ebr1.SanJose1.Level3.net (4.69.148.138)  77.341 ms
> ae-34-34.ebr2.SanJose1.Level3.net (4.69.153.33)  77.662 ms
> 15  ae-62-62.csw1.SanJose1.Level3.net (4.69.153.18)  80.375 ms
> ae-61-61.csw1.SanJose1.Level3.net (4.69.153.2)  87.895 ms
> ae-81-81.csw3.SanJose1.Level3.net (4.69.153.10)  77.137 ms
> 16  ae-31-90.car1.SanJose2.Level3.net (4.69.152.203)  77.660 ms
> ae-41-80.car1.SanJose2.Level3.net (4.69.152.139)  78.313 ms
> ae-21-60.car1.SanJose2.Level3.net (4.69.152.11)  77.746 ms
> 17  * * *
> 18  * * *
> 19  * * *
> 20  * * *
> 21  * * *
> 22  * * *
> 23  * * *
> 24  * * *
> 25  * * *
> 26  * * *
> 27  * * *
>  28  * * *
> 29  * * *
> 30  * * *
>
> Thanks for looking into this.
> Philip
>
> On Thu, Mar 15, 2012 at 10:23 AM, William Siegrist wrote:
>
>> Our network provider did not find anything wrong. If anyone is currently
>> seeing slow download times, I would like to see a traceroute to the server.
>>
>> Thanks,
>> -Bill
>>
>>
>> ___
>> 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] Is converting pixel tests to reftests kosher for imported libraries?

[Levi Weintraub]

On Wed, Mar 7, 2012 at 4:50 PM, Ryosuke Niwa  wrote:

> On Wed, Mar 7, 2012 at 4:44 PM, Darin Fisher  wrote:
>
>> Hrm, if the test expectations are customized already for different ports
>> of WebKit, then why not support replacing a PNG file with a HTML file that
>> is intended to generate exactly the same result?  How does this impair our
>> ability to update the tests?
>>
>> (I realize that our current reftest system may not work like this.  I'm
>> not familiar with the details of how it works in fact, but it seems like it
>> could be as simple as having an expected result that is a HTML file instead
>> of a PNG file.)
>>
>
> How do we know that we are testing what the test is intending to test
> after the conversion? e.g. it's possible to create a reference file that
> fails to catch certain bugs.
>

This sums up my worry as well. I can imagine a bug causing a CSS test and
its reference to fail in the same way, masking the failure.


>
> It's not obvious to me how one would figure out how many reference files
> are needed for a given test to make sure we're not making the test more
> permissible than the author intended it to be.
>
> - Ryosuke
>
>
> ___
> 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] Subpixel Layout Update

[Levi Weintraub]

On Wed, Feb 22, 2012 at 6:15 PM, Dirk Schulze  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  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@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] Subpixel Layout Update

[Levi Weintraub]

You're right, those are obsolete. We'll get those removed.


On Tue, Feb 21, 2012 at 10:37 AM, David Hyatt  wrote:

> I had a question about the subpixel layout stuff. Right now RenderBlock is
> full of comments talking about switching to floats, .e.g.,
>
>
> FIXME: Might need rounding once we switch to float, see
> https://bugs.webkit.org/show_bug.cgi?id=64021
>
>
>
>
> FIXME: Change to use roughlyEquals when we move to float.
>
>
> Are these comments obsolete? If so, can we get that code cleaned up?
>
> dave
> (hy...@apple.com)
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Subpixel Layout Update

[Levi Weintraub]

Hi Dirk,

Inline:

On Sat, Feb 18, 2012 at 9:44 PM, Dirk Schulze  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.


>
> 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
> 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] Subpixel Layout Update

[Levi Weintraub]

On Fri, Feb 10, 2012 at 6:14 PM, Adam Barth  wrote:

> On Fri, Feb 10, 2012 at 6:09 PM, Levi Weintraub  wrote:
> > On Fri, Feb 10, 2012 at 6:03 PM, Adam Barth  wrote:
> >>
> >> On Fri, Feb 10, 2012 at 5:49 PM, Levi Weintraub 
> wrote:
> >> > WebKittens,
> >> >
> >> > We're planning to wrap up our conversion of the RenderTree to subpixel
> >> > units
> >> > next week. We've created a the following wiki page to help explain the
> >> > changes we are making: https://trac.webkit.org/wiki/LayoutUnit If you
> >> > work
> >> > on the rendering code, please take a look and talk to Emil and me if
> you
> >> > have any questions.
> >> >
> >> > This will effect a large number of layout test expectations as well as
> >> > some
> >> > platform interfaces. If you are working on or maintaining a port other
> >> > than
> >> > Apple, Qt, and Chromium, please touch bases with us.
> >>
> >> We've been talking about turning on mock scroll bars for Chromium.
> >> Would it make sense to do that at the same time to minimize the number
> >> of baseline updates?
> >
> > It would allow us to make only one WebKit sheriff's life miserable
> instead
> > of two, but the changes don't really relate in any other meaningful way.
>
> I meant it would let us update the PNGs once instead of twice.
>
> Of course. We're only looking at something on the order of 500-600 layout
test expectation updates, which I believe is quite a bit smaller than the
mock scrollbar update, but we're totally interested in saving this effort.
Who should we talk to about aligning these changes?


> Adam
>
>
> >> > On Fri, Oct 28, 2011 at 1:43 PM, Levi Weintraub 
> >> > wrote:
> >> >>
> >> >> WebKittens,
> >> >>
> >> >> As you may know, Emil and I have been diligently working on getting
> >> >> subpixel layout up and running in WebKit. After much testing, we
> >> >> settled on a fixed point implementation instead of floats; we're
> happy
> >> >> to discuss how we arrived at this decision. We're currently in a
> state
> >> >> where we pass most of the layout tests and many (but not all) of the
> >> >> remaining failures are due to rounding differences that are
> desirable.
> >> >>
> >> >> As such, we've moved our efforts to a public branch on the WebKit.org
> >> >> svn server, and would love early feedback and advice. Our branch
> >> >> currently runs the following ports: Mac, Qt, Chromium-Linux, and
> >> >> Chromium-Mac. Any advice or help bringing up other platforms would be
> >> >> greatly appreciated.
> >> >>
> >> >> You can check our work out here:
> >> >> http://svn.webkit.org/repository/webkit/branches/subpixellayout
> >> >> (currently branched from r98654 and we'll continue to track head by a
> >> >> day or two)
> >> >>
> >> >> Thanks,
> >> >> Emil and Levi
> >> >
> >> >
> >> >
> >> > ___
> >> > 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] Subpixel Layout Update

[Levi Weintraub]

On Fri, Feb 10, 2012 at 6:03 PM, Adam Barth  wrote:

> On Fri, Feb 10, 2012 at 5:49 PM, Levi Weintraub  wrote:
> > WebKittens,
> >
> > We're planning to wrap up our conversion of the RenderTree to subpixel
> units
> > next week. We've created a the following wiki page to help explain the
> > changes we are making: https://trac.webkit.org/wiki/LayoutUnit If you
> work
> > on the rendering code, please take a look and talk to Emil and me if you
> > have any questions.
> >
> > This will effect a large number of layout test expectations as well as
> some
> > platform interfaces. If you are working on or maintaining a port other
> than
> > Apple, Qt, and Chromium, please touch bases with us.
>
> We've been talking about turning on mock scroll bars for Chromium.
> Would it make sense to do that at the same time to minimize the number
> of baseline updates?
>

It would allow us to make only one WebKit sheriff's life miserable instead
of two, but the changes don't really relate in any other meaningful way.


>
> Adam
>
>
> > On Fri, Oct 28, 2011 at 1:43 PM, Levi Weintraub 
> wrote:
> >>
> >> WebKittens,
> >>
> >> As you may know, Emil and I have been diligently working on getting
> >> subpixel layout up and running in WebKit. After much testing, we
> >> settled on a fixed point implementation instead of floats; we're happy
> >> to discuss how we arrived at this decision. We're currently in a state
> >> where we pass most of the layout tests and many (but not all) of the
> >> remaining failures are due to rounding differences that are desirable.
> >>
> >> As such, we've moved our efforts to a public branch on the WebKit.org
> >> svn server, and would love early feedback and advice. Our branch
> >> currently runs the following ports: Mac, Qt, Chromium-Linux, and
> >> Chromium-Mac. Any advice or help bringing up other platforms would be
> >> greatly appreciated.
> >>
> >> You can check our work out here:
> >> http://svn.webkit.org/repository/webkit/branches/subpixellayout
> >> (currently branched from r98654 and we'll continue to track head by a
> >> day or two)
> >>
> >> Thanks,
> >> Emil and Levi
> >
> >
> >
> > ___
> > 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] Subpixel Layout Update

[Levi Weintraub]

WebKittens,

We're planning to wrap up our conversion of the RenderTree to subpixel
units next week. We've created a the following wiki page to help explain
the changes we are making: https://trac.webkit.org/wiki/LayoutUnit If you
work on the rendering code, please take a look and talk to Emil and me if
you have any questions.

This will effect a large number of layout test expectations as well as some
platform interfaces. If you are working on or maintaining a port other than
Apple, Qt, and Chromium, please touch bases with us.

Thanks!
-Emil and Levi


On Fri, Oct 28, 2011 at 1:43 PM, Levi Weintraub  wrote:

> WebKittens,
>
> As you may know, Emil and I have been diligently working on getting
> subpixel layout up and running in WebKit. After much testing, we
> settled on a fixed point implementation instead of floats; we're happy
> to discuss how we arrived at this decision. We're currently in a state
> where we pass most of the layout tests and many (but not all) of the
> remaining failures are due to rounding differences that are desirable.
>
> As such, we've moved our efforts to a public branch on the WebKit.org
> svn server, and would love early feedback and advice. Our branch
> currently runs the following ports: Mac, Qt, Chromium-Linux, and
> Chromium-Mac. Any advice or help bringing up other platforms would be
> greatly appreciated.
>
> You can check our work out here:
> http://svn.webkit.org/repository/webkit/branches/subpixellayout
> (currently branched from r98654 and we'll continue to track head by a
> day or two)
>
> Thanks,
> Emil and Levi
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Subpixel Layout Update

[Levi Weintraub]

We've been pretty heavily in bug-fix mode recently, but it's been our
intention to synchronize layout-unit usage in trunk to shrink down our
patch for awhile now.

On Fri, Oct 28, 2011 at 3:14 PM, Eric Seidel  wrote:
> It's not a big deal.  It just wasn't until I saw the diff in
> prettydiff that I had any clue what the branch changes look like.
> After looking at the diff, it looks like you all should be able to
> easily merge most of your branch into trunk *today*.  Much of it is
> changes we want regardless of whether we move to subpixel layout or
> not. :)
>
> On Fri, Oct 28, 2011 at 2:54 PM, Emil A Eklund  wrote:
>> On Fri, Oct 28, 2011 at 14:52, Eric Seidel  wrote:
>>> I've posted the current diff from the branch so that its easier to read.
>>
>> Thanks Eric,
>>
>> I'll make sure to update it periodically to make it easier to follow
>> our progress.
>>
>> --
>> Emil
>>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Subpixel Layout Update

[Levi Weintraub]

Thanks Eric,

I just created a meta bug to track issues found in the branch. Please
file issues as blocking bugs against 71143:
https://bugs.webkit.org/show_bug.cgi?id=71143

-Levi

On Fri, Oct 28, 2011 at 2:38 PM, Eric Seidel  wrote:
> Do you have a master bug we can CC ourselves on to follow along at home?
>
> I've attached the diff, btw.
>
> On Fri, Oct 28, 2011 at 1:54 PM, Emil A Eklund  wrote:
>> On Fri, Oct 28, 2011 at 13:47, Eric Seidel  wrote:
>>> Most interesting is to see the branch diff.  Is that possible from the
>>> web?  Could you tell me what the magic svn command is if it's not
>>> possible?
>>
>> The easiest seems to be the following:
>>
>> svn diff --old http://svn.webkit.org/repository/webkit/trunk@98654
>> --new http://svn.webkit.org/repository/webkit/branches/subpixellayout
>> Source/
>>
>> Where the magic revision number is the last revision we've merged into
>> the branch, in this case 98654. You can find the latest revision we've
>> merged by looking at the revision history here:
>> http://trac.webkit.org/log/branches/subpixellayout
>>
>>
>> --
>> Emil
>>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Subpixel Layout Update

[Levi Weintraub]

WebKittens,

As you may know, Emil and I have been diligently working on getting
subpixel layout up and running in WebKit. After much testing, we
settled on a fixed point implementation instead of floats; we're happy
to discuss how we arrived at this decision. We're currently in a state
where we pass most of the layout tests and many (but not all) of the
remaining failures are due to rounding differences that are desirable.

As such, we've moved our efforts to a public branch on the WebKit.org
svn server, and would love early feedback and advice. Our branch
currently runs the following ports: Mac, Qt, Chromium-Linux, and
Chromium-Mac. Any advice or help bringing up other platforms would be
greatly appreciated.

You can check our work out here:
http://svn.webkit.org/repository/webkit/branches/subpixellayout
(currently branched from r98654 and we'll continue to track head by a
day or two)

Thanks,
Emil and Levi
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Mobile Safari Source Code

[Levi Weintraub]

Correct. Only WebCore and JavascriptCore sources are provided.

On Sun, Oct 23, 2011 at 10:42 AM, Vineet Chaudhary  wrote:
> Sorry my mistake..
>
> For iOS,
> http://opensource.apple.com/release/ios-50/
> but I don't think you will get Safari App code here.
>
> 2011/10/23 道雄野口 
>>
>> Hi
>>
>> >1) WebCore Code
>> > http://opensource.apple.com/source/WebCore/WebCore-7534.51.22/
>> >2) Webkit Code
>> > http://opensource.apple.com/source/WebKit/WebKit-7534.51.22/
>>
>> I thinnk these source is 'for mac desktop' source.
>> I want to see 'for iOS' Safari app source.
>>
>> Thanks
>>
>> 2011年10月24日1:01 Vineet Chaudhary :
>> > Hi,
>> >
>> > You may refer the code at below links,
>> >
>> > 1) WebCore Code
>> > http://opensource.apple.com/source/WebCore/WebCore-7534.51.22/
>> > 2) Webkit Code
>> > http://opensource.apple.com/source/WebKit/WebKit-7534.51.22/
>> >
>> > You may also like refer xcode projects WebCore.xcodeproj/
>> > WebKit.xcodeproj/
>> > I Hope that helps.
>> >
>> > --Vineet
>> >
>> >
>> > 2011/10/23 道雄野口 
>> >>
>> >> Hi
>> >>
>> >> I am looking for a source code of mobile safari.(iOS Safari)
>> >> I want to see address bar and search bar source code.
>> >>
>> >> Where is XCode Project File ?
>> >> (Have already looked here 'http://www.webkit.org/' , but could not
>> >> find.
>> >>
>> >> Please tell me somehow.
>> >> ___
>> >> 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
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] XCode > 4.0

[Levi Weintraub]

I know some people have been building WebKit with the 4.1 IDE, but
after a cursory attempt I was only able to build from the command
line. I'd also love tips from those more familiar with it :)

-Levi

On Thu, Sep 29, 2011 at 3:04 PM, lcerveau  wrote:
> HI
> Apologies in advance for this newbie question.
> I started to have a deeper look into WebKit code for some bugs I would like
> to fix . In order to grasp the develop/compile/debug cycle for webkit, I did
> follow the instructions at https://ebkit.org/building/debug.html
> However it looks like Xcode 4.0 is far form what is written.
> Are there any guidelines  for Xcode 4.1 (or above)? Or is using directly db
> in the console the favored way to proceed?
> thanks
> laurent
>
> ___
> 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] Do you compile with ENABLE_SVG diabled?

[Levi Weintraub]

That seems like a very reasonable solution to me.

On Fri, Sep 9, 2011 at 2:51 PM, Dirk Schulze  wrote:
> We could at least remove the subsets of SVG. Some developers build without 
> SVG for compile time reasons.
>
> Dirk
>
> Am 09.09.2011 um 23:45 schrieb Levi Weintraub:
>
>> I know webOS ships (or doesn't these days?) sans-SVG.
>>
>> On Fri, Sep 9, 2011 at 2:42 PM, Eric Seidel  wrote:
>>> I am interested in removing the ENABLE_SVG define, and all associated
>>> sub-defines
>>>
>>> ENABLE_SVG_ANIMATION
>>> ENABLE_SVG_AS_IMAGE
>>> ENABLE_SVG_FONTS
>>> ENABLE_SVG_FOREIGN_OBJECT
>>> ENABLE_SVG_USE
>>>
>>> SVG is part of HTML5, and all major ports compile and ship with SVG
>>> enabled (and have for years).
>>>
>>> Please let me know if you are compiling with ENABLE_SVG disabled.
>>>
>>> -eric
>>> ___
>>> 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] Do you compile with ENABLE_SVG diabled?

[Levi Weintraub]

I know webOS ships (or doesn't these days?) sans-SVG.

On Fri, Sep 9, 2011 at 2:42 PM, Eric Seidel  wrote:
> I am interested in removing the ENABLE_SVG define, and all associated
> sub-defines
>
> ENABLE_SVG_ANIMATION
> ENABLE_SVG_AS_IMAGE
> ENABLE_SVG_FONTS
> ENABLE_SVG_FOREIGN_OBJECT
> ENABLE_SVG_USE
>
> SVG is part of HTML5, and all major ports compile and ship with SVG
> enabled (and have for years).
>
> Please let me know if you are compiling with ENABLE_SVG disabled.
>
> -eric
> ___
> 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] help with commit queue failure

[Levi Weintraub]

The failure is before the last 500 characters of output, so you can't see it
unfortunately. Your patch doesn't apply to trunk, try updating your local
checkout, resolving any conflicts, and re-uploading.

-L

On Thu, Aug 18, 2011 at 2:05 PM, Sailesh Agrawal  wrote:

> Hi all, I'm trying to commit a patch through commit queue and I'm getting a
> strange error:
> http://queues.webkit.org/results/9419886
>
> As far as I can tell there's nothing wrong but it still fails. Does anyone
> know what's going on here?
>
> The bug I'm working on is this:
> https://bugs.webkit.org/show_bug.cgi?id=6
>
> Thanks!
> Sailesh
>
> ___
> 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

[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

[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] Large Source Reorganizations By External WebKit Ports

[Levi Weintraub]

Speaking from my time at HP/Palm working on webOS, there was always a desire
to upstream the project particularly to avoid missing all the source
reorganization going on in the main tree. Unfortunately, there's a large bar
of entry to upstream a new WebKit port, and we never had the resources to
make that happen...


On Thu, May 19, 2011 at 9:09 AM, Charles Pritchard  wrote:

>  On 5/18/11 2:09 PM, Peter Kasting wrote:
>
> On Wed, May 18, 2011 at 12:36 PM, Brent Fulgham wrote:
>
>> Google
>> used this same approach with their Chromium port, the side effects of
>> which find us in year two (or three?) of the effort to merge those
>> changes back into the core WebKit archive.
>>
>
>  Um, what?  The Chromium port is fully upstreamed and has been for some
> time.  I'm not sure what you're saying here.  We are not forked and in fact
> have no support for building Chromium with anything other than upstream
> WebKit.
>
>
> And as a web app developer, I've been happy to push bug fixes into WebKit
> via Chromium bug reports.
>
> I heard from RIM that they're working hard to get their fork back in line
> with WebKit upstream;
> they've contributed a lot of work to WebKit upstream, but are not yet
> merged back in... That's what I heard.
>
> I think Brent's question to the list may have some merit if looked at from
> a different perspective.
> Let me try it... Peter: Are there any lessons learned about that process
> Chromium went through?
>
> As a coder, I certainly see that fork and merge process as a normal process
> -- a company
> forks from the upstream, works on the code base within their own product,
> and at some point
> their use becomes mature and they're able to merge back in with the
> upstream.
>
> Are there any insights to that process -- or even estimates -- such as --
> it took us "x" months
> once we had WebKit working for us, to get back to building directly with
> the upstream.
>
> Little bits of information like that may be helpful to some WebKit vendors.
>
>
> -Charles
>
> ___
> 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 ENABLE_GESTURE_MANAGER

[Levi Weintraub]

Some platforms implement touch recognition at a higher level than WebKit, so
I don't think it necessarily make senes to re-use the TOUCH_EVENTS feature
since you can have touch events in WebKit without a touch manager
implemented there... But I also don't see the need for this to live in
WebCore.

On Mon, May 9, 2011 at 12:06 PM, Robert Kroeger wrote:

> Hi Adam,
>
> On Mon, May 9, 2011 at 2:54 PM, Adam Barth  wrote:
> > I'm mostly ignorant of how touch works, but would it make sense for
> > the gesture recognition engine to be part of WebCore or is this
> > functionality that's usually provided by the platform?
>
> In current platforms (iOS, Android), each platform has its own gesture
> recognizer. Discussion with reviewers (Antonio Gomes, Benjamin
> Poulain) led me to add a platform-independent hook that could invoke
> platform-specific code.
>
> Chrome (in particular ChromeOS) has no gesture recognizer and needs
> one. Placing the Chrome gesture recognizer in the Chrome platform
> makes it efficient for delivering the synthesized events without
> additional IPC or external libraries.
>
> Rob.
>
> >
> > Adam
> >
> >
> > On Mon, May 9, 2011 at 11:32 AM, Robert Kroeger 
> wrote:
> >> Hi webkit-dev!
> >>
> >> As suggested by Eric Seidel's email from earlier today, I thought it
> >> would be proper to let you know that I am in the process of adding a
> >> touch gesture recognition feature to the Chromium port of WebKit. The
> >> first part of this feature is
> >> https://bugs.webkit.org/show_bug.cgi?id=49345. This patch adds a hook
> >> to WebCore to pass touch events to an optional platform-specific
> >> gesture recognition engine. The code is turned off by default except
> >> in the Chromium port where it is enabled with ENABLE_GESTURE_MANAGER.
> >>
> >> Patch https://bugs.webkit.org/show_bug.cgi?id=54417 and its successors
> >> will add a progressively more useful gesture recognizer implementation
> >> to the Chromium platform.
> >>
> >> All code in this feature will be exercised by the Chromium buildbots.
> >>
> >> Rob.
> >> ___
> >> 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