Re: [webkit-dev] Unprefixing requestAnimationFrame

2012-10-12 Thread Maciej Stachowiak

I agree with this position as well. It seems good to have a transition period 
and to gather some data.

 - Maciej

On Oct 11, 2012, at 9:59 PM, Darin Fisher da...@chromium.org wrote:

 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 will be enough.)
 
 Why not be conservative here?
 
 -Darin
 
 
 On Thu, Oct 11, 2012 at 5:29 PM, James Simonsen simon...@chromium.org wrote:
 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 this unprefixed. [3]
 
 3. Toolkits already use the unprefixed version. [4]
 
 4. The advice on the internet recommends everyone use the polyfill technique. 
 [5]
 
 I'm curious what everyone else thinks.
 
 James
 
 [1] https://bugs.webkit.org/show_bug.cgi?id=99116
 [2] https://bugs.webkit.org/show_bug.cgi?id=66683
 [3] http://caniuse.com/#feat=requestanimationframe
 [4] https://gist.github.com/1579671
 [5] https://developer.mozilla.org/en-US/docs/DOM/window.requestAnimationFrame
 
 ___
 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] Transformations precision: double - float

2012-10-12 Thread Gabor Rapcsanyi

Yes I agree that we need to do some measures to see the benefits of floats.
But it's not just about the performance and memory gain of the floats, I 
would like to make ARM SIMD optimizations for the transformation 
functions to fasten up them, but ARM NEON technology only works with 
floats that's why I want to change the doubles.
I would prefer a typedef solution to make this configurable as Ryosuke 
said, and then the ports could chose whether they need floats, doubles 
or long doubles.


- Gabor

On Oct 10, 2012, at 9:00 AM, Gabor Rapcsanyi rga...@inf.u-szeged.hu 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 programming interface to the graphics system on OS X uses doubles, so it’s 
likely we’ll be introducing float to double conversions for at least that 
platform if we change things inside WebKit that are currently doubles to float 
en masse.

Similarly, the native data type for numbers in JavaScript is double. So any 
time we are passing a number from JavaScript to WebKit it’s likely that 
additional double to float conversions will be required as we change internals 
to use doubles instead of floats.

On the other hand, there may also be performance boost or memory gains from 
using float instead of double.

If we do make this change, I think we need to do performance testing as we do 
so, perhaps on more than one platform, to see if these changes are leading to 
benefits or not.

I also think that “we should always use float unless a spec mandates double” is 
probably not the right rule of thumb. There are many factors other than “a 
spec” at play here.

-- Darin


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Fwd: Transformations precision: double - float

2012-10-12 Thread Tom Hudson
(again from corrected account)

Originally To: Gabor Rapcsanyi rga...@inf.u-szeged.hu, CC: Mike Reed
r...@google.com


Do you have particular bottleneck functions that you have reason to
believe would benefit from ARM SIMD optimizations? Under what
workloads, and how much benefit?

We've see a few ridiculously expensive transform functions in WebKit
that my colleagues in Chapel Hill might be able to recall, but usually
it's the rendering engines that are hot, not WebKit itself.

We have seen places where double math appears to be absolutely
required for correctness: matrix inversion and path convexity testing;
there are some other areas we're experimenting with that seem to
require it as well. You'd probably need to survey WebKit for stability
(or just hack in doubles and run layout tests) to see how many other
places will break if you throw away the extra precision.

The rest of Chromium's renderer (Skia) uses float, and we've deployed
SSE/NEON and played with float vs double quite a bit there. The
float-double conversion at the WebKit/Skia boundary doesn't seem to
be too much of a drag, but doing it in any sort of inner loop can
really kill performance.

Meanwhile, there are a lot of places where switching from ARM assembly
to NEON in the renderer hasn't given us as much win as we'd hoped for,
which is why the question how much benefit? seems important to
answer before spending too much time polishing a set of typedefs.

Tom
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] x32 support of JavaScriptCore

2012-10-12 Thread Xian, Yuqiang
Thank you Gavin.

I have created a bug entry and proposed a patch for MacroAssembler refactoring 
at https://bugs.webkit.org/show_bug.cgi?id=99154.

Also, a bug entry is created to trace the x32 support of JavaScriptCore at 
https://bugs.webkit.org/show_bug.cgi?id=99153. There you could also find how 
the code should be (based on the refactoring work) to support x32 in 
JavaScriptCore. Note that currently the low level interpreter on x32 is not 
enabled yet but on the plan.

Would you like to have a look at them?

Thanks much, -Yuqiang

-Original Message-
From: Gavin Barraclough [mailto:barraclo...@apple.com] 
Sent: 2012年10月12日 2:22
To: Xian, Yuqiang
Cc: WebKit Development
Subject: Re: [webkit-dev] x32 support of JavaScriptCore

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 cc me.  If this is the bulk of 
your changes, it may not be a problem to upstream support if you'll be prepared 
to maintain, and if that doesn't work out it should at least reduce the size of 
your diff.  We prefer incremental changes, so please split out any refactoring 
that will affect all platforms from changes to support x32, these should be 
landed separately.

cheers,
G.


On Oct 11, 2012, at 1:52 AM, Xian, Yuqiang wrote:

 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 the JIT compiler, we also take this assumption and invoke the 
 same macro assembler interface for both JSValue and pointer operands. So the 
 primary task for x32 support is to differentiate the operations on pointers 
 from the operations on JSValues, and let them invoking different macro 
 assembler interfaces. For example, we now use the interface of loadPtr to 
 load either a pointer or a JSValue, and we need to switch to using loadPtr 
 to load a pointer and some new load64 interface to load a JSValue.
 The major modification I made is to introduce the *64 interfaces in the 
 MacroAssembler, make the *Ptr interfaces platform dependent implemented 
 (one for X32 and the other for X64), and go through all the JIT compiler code 
 to identify which interfaces should be used.
 Also, the calling convention needs to be cared. For example on X64 you may 
 need two registers to pass or return a structure with two pointer size 
 members, while on X32 those two members are placed in one register.
 
 Thanks, -Yuqiang
 
 -Original Message-
 From: Zoltan Herczeg [mailto:zherc...@webkit.org] 
 Sent: 2012年10月11日 15:43
 To: Xian, Yuqiang
 Cc: Kenneth Rohde Christiansen; webkit-dev@lists.webkit.org
 Subject: Re: [webkit-dev] x32 support of JavaScriptCore
 
 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 basically ignored when you access a memory address. It is called Small
 Code Model or something. I suspect the changes in the JIT code are
 minimal.
 
 Regards,
 Zoltan
 
 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 - it requires a mature x32 system which at least supports all of
 the things that a WebKit port depends on. I know there're efforts porting
 Gentoo and Fedora to x32 - we may depend on each other.
 
 Currently I'm testing the JSC shell only. Though I use the EFL port, I
 eliminated most of the unnecessary dependencies on EFL libraries to run
 the JSC shell, so that I don't need to put efforts on compiling and
 enabling those dependencies for x32 at current stage.
 
 Thanks, -Yuqiang
 
 -Original Message-
 From: Kenneth Rohde Christiansen [mailto:kenneth.christian...@gmail.com]
 Sent: 2012年10月11日 5:51
 To: Xian, Yuqiang
 Cc: webkit-dev@lists.webkit.org
 Subject: Re: [webkit-dev] x32 support of JavaScriptCore
 
 Hi,
 
 I don't think another branch on webkit.org will help you much; then
 you can as well have a branch anywhere.
 
 If you want this code to be well tested and maintained, you need to
 get it upstream (through all the review process) and promise that you
 have resources to keep maintaining it. It will also be an advantage if
 we can get a buildbot running this exact configuration, so that others
 can make sure they don't break your 

Re: [webkit-dev] Unprefixing requestAnimationFrame

2012-10-12 Thread Dean Jackson
Me too. Please don't just remove the prefix - we need a period of time where we 
support both prefixed and unprefixed.

Dean

On 12/10/2012, at 6:58 PM, Maciej Stachowiak m...@apple.com wrote:

 
 I agree with this position as well. It seems good to have a transition period 
 and to gather some data.
 
  - Maciej
 
 On Oct 11, 2012, at 9:59 PM, Darin Fisher da...@chromium.org wrote:
 
 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 will be enough.)
 
 Why not be conservative here?
 
 -Darin
 
 
 On Thu, Oct 11, 2012 at 5:29 PM, James Simonsen simon...@chromium.org 
 wrote:
 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 this unprefixed. [3]
 
 3. Toolkits already use the unprefixed version. [4]
 
 4. The advice on the internet recommends everyone use the polyfill 
 technique. [5]
 
 I'm curious what everyone else thinks.
 
 James
 
 [1] https://bugs.webkit.org/show_bug.cgi?id=99116
 [2] https://bugs.webkit.org/show_bug.cgi?id=66683
 [3] http://caniuse.com/#feat=requestanimationframe
 [4] https://gist.github.com/1579671
 [5] https://developer.mozilla.org/en-US/docs/DOM/window.requestAnimationFrame
 
 ___
 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

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] HbbTV support within Webkit

2012-10-12 Thread Randall Bennett
On Thu, Oct 11, 2012 at 12:16 PM, Maciej Stachowiak m...@apple.com wrote:


 On Oct 11, 2012, at 7:40 AM, Mark Toller mark.tol...@samsung.com 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) 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 support standard W3C/HTML5)...
 
  This particular change is just a matter of adding one more displayable
  mime-type, right?
 
  Almost. I've created a bug and patch for this particular change:
 
  https://bugs.webkit.org/show_bug.cgi?id=99049
 
  As someone else stated, I think the best approach is to create
  a bug for each change we consider worthwhile, and then they can be
  considered individually.

 I don't think we should take this change or accept this feature in
 general. It seems that of those who have spoken up, the WebKit community is
 not in favor of this direction.



 Even though the specific change in that patch is relatively small,
 supporting custom MIME types has significant disadvantages:

 - Creates interoperability issues with other browsers.
 - Fragments the web
 - Opens us up to further requests to add support for similarly niche MIME
 types in the future

 If CE-HTML and HbbTV content is fine to process as ordinary HTML, then it
 should be served with text/html MIME type. That would avoid all of these
 problems. If a consortium decided to create custom mime types instead, then
 they made a mistake and should fix it. In some cases, when the technology
 is compelling or there is a wealth of existing content, we live with
 arguable errors in the standard. But neither of those considerations
 applies here.

 Regards,
 Maciej

 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev



 +1. As someone who builds applications specifically for TV producers, I
feel that this custom mime type is the first in a series of bad moves.

Why doesn't the HBB group form its own W3 style group? I think this is just
heading in the wrong direction.

rb
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] recompilation in dfg

2012-10-12 Thread Blake Fiddler
Hi.
I have some example in which my function recompiling in dfg jit (it's
parsing in second time without OSR exits).
Can you explain me why that happens and in which cases?

Regards, Blake.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] recompilation in dfg

2012-10-12 Thread Maciej Stachowiak

The best way to find out would be to file a bug at http://bugs.webkit.org/ with 
a test case demonstrating the problem.

 - Maciej

On Oct 12, 2012, at 6:26 PM, Blake Fiddler blake.fidd...@gmail.com wrote:

 Hi.
 I have some example in which my function recompiling in dfg jit (it's parsing 
 in second time without OSR exits).
 Can you explain me why that happens and in which cases? 
 
 Regards, Blake.
 ___
 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] recompilation in dfg

2012-10-12 Thread Filip Pizlo
Two bad things could have happened:

1) OSR entry failed.  That's rare.  You could try to put some logging in 
prepareOSREntry.

2) The GC decided that it didn't want to keep your code around anymore.  We 
have heuristics for doing this even if your code doesn't OSR exit, and even 
when the owning function is still live.  The reason is that the generated 
machine code may have pointers to the heap.  If those objects are not otherwise 
live, the GC has to either make them live (which could increase footprint) or 
kill the DFG code block.  It will often do the latter.

As Maciej suggests, a bug report would be great.  We are always interested in 
looking at programs where our heuristics fail.

-F


On Oct 12, 2012, at 6:26 PM, Blake Fiddler blake.fidd...@gmail.com wrote:

 Hi.
 I have some example in which my function recompiling in dfg jit (it's parsing 
 in second time without OSR exits).
 Can you explain me why that happens and in which cases? 
 
 Regards, Blake.

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev