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 wi

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 unpre

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

Re: [webkit-dev] Interface design question

2012-10-11 Thread Siva B
I'am Sorry. Siva. From: Ryosuke Niwa To: Siva B Cc: "webkit-dev@lists.webkit.org" Sent: Thursday, October 11, 2012 2:43 PM Subject: Re: [webkit-dev] Interface design question webkit-dev doesn't seem like an appropriate place to discuss this topic unles

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 wrote: > Hello, > > Have a design related question and hope to hear some insights. > > Int

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

Re: [webkit-dev] x32 support of JavaScriptCore

2012-10-11 Thread Gavin Barraclough
Hi Yuqiang, I think that this could be a good refactoring for the MacroAssembler – to move all ( Ptr->32 / Ptr->64 ) remapping into MacroAssembler.h, introduce a Imm64, rename all the current *Ptr* methods in MacroAssemblerX86_64 to *64*, etc – please feel free to put up patches for this, and c

Re: [webkit-dev] HbbTV support within Webkit

2012-10-11 Thread Maciej Stachowiak
On Oct 11, 2012, at 7:40 AM, Mark Toller wrote: >> -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)

Re: [webkit-dev] Transformations precision: double -> float

2012-10-11 Thread Darin Adler
On Oct 10, 2012, at 9:00 AM, Gabor Rapcsanyi wrote: > That was a long time ago and there were no objections >> Unless there's something in the spec requiring double precision it makes >> sense to move away from double precision throughout WebKit. I’m a little concerned about this. The program

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

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 suppor

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 wrote: > Thanks for the suggestions, Kenneth. > >

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*".

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