Re: [webkit-dev] [blink-dev] FOSDEM 2015 Desktops DevRoom Call for Talks
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?
+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
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
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
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
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()
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
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
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!
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
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
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?
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
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
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
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
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
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
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?
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
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
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
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
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
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
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
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
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
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
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
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?
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?
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
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
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
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
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
