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

2014-10-27 Thread 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 pgqui...@elpauer.org
wrote:

 Hello,

 --8---

 FOSDEM http://www.fosdem.org 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
 https://archive.fosdem.org/2014/schedule/track/desktops/ 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
 https://lists.fosdem.org/private/desktops-devroom/ (subscription page
 https://lists.fosdem.org/listinfo/desktops-devroom 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?

2013-03-26 Thread Levi Weintraub
+1. I also like that this will make layering violations clearer.


On Tue, Mar 26, 2013 at 1:53 PM, Filip Pizlo fpi...@apple.com wrote:


 On Mar 26, 2013, at 1:40 PM, Dirk Pranke dpra...@chromium.org wrote:

 On Tue, Mar 26, 2013 at 1:29 PM, Benjamin Poulain benja...@webkit.org
 wrote:

 On Tue, Mar 26, 2013 at 1:20 PM, Dirk Pranke dpra...@chromium.org 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

2013-03-21 Thread Levi Weintraub
dream
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.
/dream


On Thu, Mar 21, 2013 at 11:16 AM, Ryosuke Niwa rn...@webkit.org wrote:

 On Thu, Mar 21, 2013 at 10:54 AM, Žan Doberšek zandober...@gmail.comwrote:

 On Thu, Mar 21, 2013 at 5:18 PM, Robert Hogan li...@roberthogan.netwrote:

 On Thursday, 21 March 2013, Ryosuke Niwa wrote:

 On Thu, Mar 21, 2013 at 1:31 AM, Robert Hogan li...@roberthogan.netwrote:

 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

2013-03-11 Thread Levi Weintraub
Congrats sir!!


On Mon, Mar 11, 2013 at 3:46 PM, Eric Seidel e...@webkit.org 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

2013-02-28 Thread Levi Weintraub
Congratulations, Mr. Rogers!


On Thu, Feb 28, 2013 at 12:09 PM, Eric Seidel e...@webkit.org 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

2013-02-20 Thread Levi Weintraub
Here here! Congratulations!


On Wed, Feb 20, 2013 at 2:36 PM, Philip Rogers p...@google.com wrote:

 This is fantastic. Congratulations Stephen!


 On Wed, Feb 20, 2013 at 2:34 PM, Dirk Schulze k...@webkit.org wrote:

 Hi WebKit folks,


 It is a pleasure to announce that Stephen Chenney schen...@chromium.org
 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()

2013-02-12 Thread 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 shawnsi...@chromium.orgwrote:

 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.

 body
   div style=-moz-transform: perspective(500px) rotateY(80deg);



   -webkit-transform: perspective(500px) rotateY(80deg);



   background-color: lime;



   width: 300px;



   height: 300px; 
 HELLO WORLD
   /div
 /body


 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 dan...@chromium.org wrote:

 +shawnsingh


 On Tue, Feb 12, 2013 at 9:22 AM, Marcin Szamotulski msza...@gmail.comwrote:

 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

2013-01-18 Thread 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 toyos...@chromium.org
 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=107250https://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-devhttp://lists.webkit.org/mailman/listinfo/webkit-dev

 __**_
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/**mailman/listinfo/webkit-devhttp://lists.webkit.org/mailman/listinfo/webkit-dev


 __**_
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/**mailman/listinfo/webkit-devhttp://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

2013-01-07 Thread 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 dschu...@adobe.com wrote:


 On Jan 7, 2013, at 4:18 AM, RGraph.net support richard.he...@gmail.com
 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] Allan Sandfeld Jensen is now a WebKit reviewer!

2012-12-21 Thread 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. http://gmail.comorg

 ﹆﹆﹆
 ___
 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

2012-08-21 Thread Levi Weintraub
Congrats!!

On Tue, Aug 21, 2012 at 7:05 AM, Soo-Hyun Choi s.c...@hackerslab.eu 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-devhttp://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

2012-08-10 Thread 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] bugs.webkit.org and trac.webkit org down?

2012-08-10 Thread Levi Weintraub
We're back!

On Fri, Aug 10, 2012 at 8:07 AM, Peter Beverloo pe...@chromium.org 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 
 o...@inf.u-szeged.huwrote:

 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-devhttp://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] offsetWidth/Height/Left/Top int to float

2012-06-18 Thread 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 ro...@adobe.com 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 
 inhttp://code.google.com/p/chromium/issues/detail?id=104074with 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 
 archivehttp://lists.webkit.org/pipermail/webkit-dev/2011-June.txtan email 
 from
 *Levi Weintraub le...@chromium.org*, 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 
 54018https://bugs.webkit.org/show_bug.cgi?id=54018
 * (Make offset* return doubles instead of ints) *and* *bug 
 39884https://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


[webkit-dev] FYI: sub-pixel layout landing soon

2012-04-23 Thread 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] FYI: sub-pixel layout landing soon

2012-04-23 Thread 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 ad...@apple.com 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


Re: [webkit-dev] FYI: sub-pixel layout landing soon

2012-04-23 Thread 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 m...@apple.com 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 ad...@apple.com 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] Git/SVN is slow

2012-03-15 Thread 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 p...@google.com 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 wsiegr...@apple.comwrote:

 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] Git/SVN is slow

2012-03-15 Thread Levi Weintraub
Likewise in Mountain View... it's making WebKit gardening impossible :(

On Thu, Mar 15, 2012 at 2:03 PM, Dmitry Titov dim...@chromium.org 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 jar...@webkit.orgwrote:

 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 rn...@webkit.org 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 jar...@webkit.orgwrote:

 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 le...@google.comwrote:

 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 p...@google.com 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 
 wsiegr...@apple.com 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

Re: [webkit-dev] Is converting pixel tests to reftests kosher for imported libraries?

2012-03-07 Thread Levi Weintraub
On Wed, Mar 7, 2012 at 4:50 PM, Ryosuke Niwa rn...@webkit.org wrote:

 On Wed, Mar 7, 2012 at 4:44 PM, Darin Fisher da...@chromium.org 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

2012-02-23 Thread Levi Weintraub
On Wed, Feb 22, 2012 at 6:15 PM, Dirk Schulze dschu...@adobe.com wrote:


 On Feb 21, 2012, at 10:13 AM, Levi Weintraub wrote:

 Hi Dirk,

 Inline:

 On Sat, Feb 18, 2012 at 9:44 PM, Dirk Schulze dschu...@adobe.com wrote:

 Hi Emil and Levi,

 I have a question to sub pixels from the SVG point of view.

 Right now a lot of content on renderers and also in RenderStyle uses
 LayoutPoint, LayoutSize, LayoutRect, Length… and so on. How would
 LayoutUnit deal with SVG's float system? Your Wiki says that SVG's float
 system stays unchanged. I assume that you mean that the source code of the
 SVG implementation will stay float based and not move to LayoutUnit. Is
 that correct?


 Currently, when SVG code queries the Render Tree it receives results as
 integers or floats. The only change we're making is to replace those
 integers with a subpixel unit. Things that were floats before will remain
 so (including all SVG layout), and we'll only increase precision in other
 places.

 I understand that. But if you look at RenderStyle::applyTransform() it
 takes LayoutSize. There are more examples like that. SVG could use some of
 these functions as well. That is why I hoped that LayoutSize and co could
 get more generic. Taking floats or integers and translating them to the
 needs of the addressor. But I understand the use case you are addressing.
 But this means we still have to use new functions to address the precision
 that is needed for SVG.

 Another question: It looks like Length.h/cpp switch to float values
 internally in your branch. Will that go to trunk as well? That would help
 us a lot on SVG. Currently I try to implement transform-origin for SVG. The
 function Length::calcFloatValue should take a float to calculate a length
 value on SVG elements. I just notice that some tests started to fail after
 that change. I couldn't verify the differences (lack of time). When will
 these changes land? Will the complete branch land as a package, or in
 smaller chunks? How long does it take to land these parts (I am primarily
 interested in the change of Length :))?


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

2012-02-21 Thread Levi Weintraub
Hi Dirk,

Inline:

On Sat, Feb 18, 2012 at 9:44 PM, Dirk Schulze dschu...@adobe.com wrote:

 Hi Emil and Levi,

 I have a question to sub pixels from the SVG point of view.

 Right now a lot of content on renderers and also in RenderStyle uses
 LayoutPoint, LayoutSize, LayoutRect, Length… and so on. How would
 LayoutUnit deal with SVG's float system? Your Wiki says that SVG's float
 system stays unchanged. I assume that you mean that the source code of the
 SVG implementation will stay float based and not move to LayoutUnit. Is
 that correct?


Currently, when SVG code queries the Render Tree it receives results as
integers or floats. The only change we're making is to replace those
integers with a subpixel unit. Things that were floats before will remain
so (including all SVG layout), and we'll only increase precision in other
places.



 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

2012-02-21 Thread Levi Weintraub
You're right, those are obsolete. We'll get those removed.


On Tue, Feb 21, 2012 at 10:37 AM, David Hyatt hy...@apple.com 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

2012-02-10 Thread 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 le...@chromium.org 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

2012-02-10 Thread Levi Weintraub
On Fri, Feb 10, 2012 at 6:03 PM, Adam Barth aba...@webkit.org wrote:

 On Fri, Feb 10, 2012 at 5:49 PM, Levi Weintraub le...@google.com 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 le...@chromium.org
 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

2012-02-10 Thread Levi Weintraub
On Fri, Feb 10, 2012 at 6:14 PM, Adam Barth aba...@webkit.org wrote:

 On Fri, Feb 10, 2012 at 6:09 PM, Levi Weintraub le...@google.com wrote:
  On Fri, Feb 10, 2012 at 6:03 PM, Adam Barth aba...@webkit.org wrote:
 
  On Fri, Feb 10, 2012 at 5:49 PM, Levi Weintraub le...@google.com
 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 le...@chromium.org
   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


[webkit-dev] Subpixel Layout Update

2011-10-28 Thread 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] Subpixel Layout Update

2011-10-28 Thread 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 e...@webkit.org 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 e...@chromium.org wrote:
 On Fri, Oct 28, 2011 at 13:47, Eric Seidel e...@webkit.org 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


Re: [webkit-dev] Subpixel Layout Update

2011-10-28 Thread 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 e...@webkit.org 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 e...@chromium.org wrote:
 On Fri, Oct 28, 2011 at 14:52, Eric Seidel e...@webkit.org 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] Mobile Safari Source Code

2011-10-23 Thread Levi Weintraub
Correct. Only WebCore and JavascriptCore sources are provided.

On Sun, Oct 23, 2011 at 10:42 AM, Vineet Chaudhary rgf...@motorola.com 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 道雄野口 mnopq...@gmail.com

 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 rgf...@motorola.com:
  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 道雄野口 mnopq...@gmail.com
 
  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

2011-09-29 Thread 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 lcerv...@me.com 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?

2011-09-09 Thread Levi Weintraub
I know webOS ships (or doesn't these days?) sans-SVG.

On Fri, Sep 9, 2011 at 2:42 PM, Eric Seidel e...@webkit.org 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] Do you compile with ENABLE_SVG diabled?

2011-09-09 Thread Levi Weintraub
That seems like a very reasonable solution to me.

On Fri, Sep 9, 2011 at 2:51 PM, Dirk Schulze k...@webkit.org 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 e...@webkit.org 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] help with commit queue failure

2011-08-18 Thread 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 s...@chromium.org 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


[webkit-dev] Switching away from integers for layout

2011-06-23 Thread 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

2011-05-19 Thread 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 ch...@jumis.com wrote:

  On 5/18/11 2:09 PM, Peter Kasting wrote:

 On Wed, May 18, 2011 at 12:36 PM, Brent Fulgham bfulg...@webkit.orgwrote:

 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

2011-05-09 Thread 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 rjkro...@chromium.orgwrote:

 Hi Adam,

 On Mon, May 9, 2011 at 2:54 PM, Adam Barth aba...@webkit.org 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 rjkro...@chromium.org
 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