Re: [webkit-dev] x32 support of JavaScriptCore

2012-10-11 Thread Xian, Yuqiang
Thanks for the suggestions, Kenneth. I'm refining the code and trying to enable the last major component - the low level interpreter for x32. Yes it's ideal if we can upstream the code, and as you mentioned, keep maintaining it. The buildbot is a good idea while we are still way far from it -

Re: [webkit-dev] x32 support of JavaScriptCore

2012-10-11 Thread Zoltan Herczeg
Just out of curiosity, how much code modifications are required? I read the ABI documentation the link you attached, and x32 is a regular 64 bit mode, except it seems to me that the global descriptor table is tweaked to store the same descriptors for all 4G address spaces, so the upper 32 bit is

Re: [webkit-dev] x32 support of JavaScriptCore

2012-10-11 Thread Xian, Yuqiang
On X32, the size of a pointer or a long integer is 4 bytes instead of 8 bytes on X64, while the register size is still 8 bytes. In JavaScriptCore implementation for X64, it assumes that the JSValue size is same to the pointer size, and thus EncodedJSValue is simply type defined as a void*. In

Re: [webkit-dev] x32 support of JavaScriptCore

2012-10-11 Thread Kenneth Rohde Christiansen
OK, I see. If most of your changes are in JavaScriptCore, it might be possible to just have a build bot that builds that and runs the unit tests for now, then later get all of WebKit tested. Kenneth On Thu, Oct 11, 2012 at 9:13 AM, Xian, Yuqiang yuqiang.x...@intel.com wrote: Thanks for the

Re: [webkit-dev] HbbTV support within Webkit

2012-10-11 Thread Dominik Röttsches
On 10/10/2012 10:26 AM, Mark Toller wrote: What we would like to see initially is Webkit based browsers (Chrome, Safari, Minibrowser, etc) actually load HbbTV pages instead of asking the user to download the content - this would indirectly benefit the end goal of Webkit (to get everyone to

Re: [webkit-dev] HbbTV support within Webkit

2012-10-11 Thread Mark Toller
-Original Message- From: Dominik Röttsches [mailto:dominik.rottsc...@intel.com] On 10/10/2012 10:26 AM, Mark Toller wrote: What we would like to see initially is Webkit based browsers (Chrome, Safari, Minibrowser, etc) actually load HbbTV pages instead of asking the user to

[webkit-dev] Interface design question

2012-10-11 Thread Siva B
Hello,   Have a design related question and hope to hear some insights.   Interfaces using abstract classes impose restriction(s) on it's derived implementations.     - The most widely used restriction is to IMPLEMENT Function(s)   Question:     Is it permissible to have

Re: [webkit-dev] Interface design question

2012-10-11 Thread Ryosuke Niwa
webkit-dev doesn't seem like an appropriate place to discuss this topic unless you have a specific WebKit patch or bug that relates this design question. On Thu, Oct 11, 2012 at 1:19 PM, Siva B bvs.s...@yahoo.com wrote: Hello, Have a design related question and hope to hear some

Re: [webkit-dev] Interface design question

2012-10-11 Thread Siva B
I'am Sorry. Siva. From: Ryosuke Niwa rn...@webkit.org To: Siva B bvs.s...@yahoo.com Cc: webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org Sent: Thursday, October 11, 2012 2:43 PM Subject: Re: [webkit-dev] Interface design question webkit-dev

[webkit-dev] Unprefixing requestAnimationFrame

2012-10-11 Thread James Simonsen
I've posted a patch to remove the webkit prefix from requestAnimationFrame. [1] The question is whether or not to continue to support the prefixed version. I propose dropping it for the following reasons: 1. We're changing the callback semantics to match the spec. [2] 2. IE10 is shipping with

Re: [webkit-dev] Unprefixing requestAnimationFrame

2012-10-11 Thread Paul Irish
From early on, requestAnimationFrame articles and documentation recommended shims/polyfills alongside the prose. Because of this nearly every script library using rAF detects all prefixes and the unprefixed standard version. More than nearly any other prefixed API I can think of, shipping

Re: [webkit-dev] Unprefixing requestAnimationFrame

2012-10-11 Thread Darin Fisher
I agree with what Adam wrote in https://bugs.webkit.org/show_bug.cgi?id=99116#c5. Even if a lot of sites will magically failover to the unprefixed API, we can't know for sure that this change won't break sites. We need to give them a chance to update. (I don't know if one Chrome release cycle