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
>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
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
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
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
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
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
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)
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
> -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
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
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.
>
>
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*".
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
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
15 matches
Mail list logo