[webkit-dev] Vector iteration

[Oliver Hunt]

Hi all, I just landed a patch that replaces Vector::iterator and 
Vector::const_iterator with a non-pointer object that is actually memory 
safe. Everything _should_ work the same as before, with a few exciting changes:

* begin() and end() can no longer be used transparently as pointers.  Happily 
WTF::getPtr() will do the right thing.
* The iterators them selves are larger - they have to track the current 
location and the source vector. It would be nice if we could avoid this within 
the enumeration syntax but that would require language changes.
* Iteration is bounds checked! Woo! As everyone has been switching to C++ 
enumeration syntax we lost all the bounds checking we were doing previously, 
but happily that hole is now plugged again.
* Huge and happy advantage: Vector iteration is now safe against mutation!!! 
Previously mutating a vector during enumeration was not memory safe, bounds 
safe, or in fact any kind of safe (but you weren’t doing that right?), and now 
it is!!!

Happily there is no performance hit from this.

—Oliver

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

Re: [webkit-dev] size_t vs unsigned in WTF::Vector API ?

[Oliver Hunt]

We almost always perform bounds checking in our use of Vector — the default 
behaviour bounds checks every access, it is a negligible cost, and in most 
cases the remaining non-checked instances of Vector<> can probably actually be 
made checked.

The current bounds checked iterator on bugs.webkit.org also has no performance 
impact, and it is having to do bounds and overflow checking. We really need to 
be careful about saying release checking is expensive, if even in our core 
vector type bounds checking is fine it’s unlikely most other simple tests will 
be fine. For example JSC has been steadily moving towards RELEASE_ASSERT for 
everything.

—Oliver


> On Nov 19, 2014, at 5:06 PM, Alex Christensen  
> wrote:
> 
> Has anybody done any performance benchmarking on this?  I imagine the changes 
> would be significant based on how hot the vector code is.  There are 8 cases 
> I see that would be worth looking into: unsigned and size_t, with and without 
> bounds checking, 32-bit and 64-bit architectures.  The performance gains of 
> not doing bounds checking would be worth being extra careful in some cases.
> 
> Alex
> 
> On Wed, Nov 19, 2014 at 4:13 PM, Chris Dumez  > wrote:
> If we don’t want to crash on overflow, the callers can use the try*() API I 
> believe (e.g. tryAppend()). This returns false (and does not resize the 
> vector) instead of crashing, when we reach the size limit.
> 
> Kr,
> --
> Chris Dumez - Apple Inc.
> Cupertino, CA
> 
> 
> 
> 
>> On Nov 19, 2014, at 2:58 PM, Alexey Proskuryakov > > wrote:
>> 
>> 
>> 19 нояб. 2014 г., в 13:58, Filip Pizlo > > написал(а):
>> 
 With Vector though, I don't know how we would differentiate code paths 
 that need large allocations from ones that don't. Nearly anything that is 
 exposed as a JS API or deals with external world can hit sizes over 4Gb. 
 That's not out of reach in most scenarios, not even for resources loaded 
 from network.
>>> 
>>> Can you provide an example?
>> 
>> Yes. XMLHttpRequest::m_binaryResponseBuilder keeps the downloaded data in a 
>> Vector, so any time there is much data, something bad will happen. This is a 
>> case that we should support, and not just crash as we would when we think 
>> that only exploits would try to use as much memory.
>> 
>> All code that is Blob related also uses Vectors, and of course Blobs can 
>> legitimately be large.
>> 
>> Crypto code uses Vectors internally for the data.
>> 
>> These and related uses are all over the place - see also Vectors in 
>> FormDataBuilder, data returned from FrameLoader::loadResourceSynchronously, 
>> plug-in code that loads from network, SharedBuffer etc.
>> 
>> - Alexey
>> 
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org 
> https://lists.webkit.org/mailman/listinfo/webkit-dev 
> 
> 
> 
> 
> 
> -- 
>  
> Alex Christensen
> 
> FlexSim Software Products, Inc.
> 
> 1577 North Technology Way | Building A | Suite 2300 | Orem, Utah 84097
> 
> Voice: 801-224-6914 <> | Fax: 801-224-6984 <>
> Email: al...@flexsim.com 
> URL: www.flexsim.com 
>  
> 
>  
> This message may contain confidential information, and is intended
> 
> only for the use of the individual(s) to whom it is addressed. 
> 
> 
> ___
> 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] size_t vs unsigned in WTF::Vector API ?

[Oliver Hunt]

On a related note I’ve also got a patch up for review that adds bounds checking 
to Vector::iterator, and that vigorously performs bounds and overflow checking.

—Oliver

> On Nov 19, 2014, at 2:04 PM, Chris Dumez  wrote:
> 
> Hi,
> 
> I believe the Vector class is already checking for overflows. I looked 
> quickly and it seems that when trying to allocate / reallocate the Vector 
> buffer, we will call CRASH() if:
> (newCapacity > std::numeric_limits::max() / sizeof(T))
> 
> Kr, 
> --
> Chris Dumez - Apple Inc.
> Cupertino, CA
> 
> 
> 
> 
>> On Nov 19, 2014, at 1:57 PM, Geoffrey Garen > > wrote:
>> 
>> I don’t haver a specific opinion on size_t vs unsigned, but I have a related 
>> point:
>> 
>> If Vector uses unsigned, then it must RELEASE_ASSERT that it does not 
>> overflow unsigned when growing. 
>> 
>> Even if most normal content allocates < 4GB, exploit content surely will try 
>> to allocate > 4GB.
>> 
>> Chris, maybe you can make this change in trunk, since trunk uses unsigned?
>> 
>> Geoff
>> 
>>> On Nov 19, 2014, at 1:50 PM, Alexey Proskuryakov >> > wrote:
>>> 
>>> 
>>> That makes good sense for internal implementation, do you think that class 
>>> API should also use a custom type, or should it use size_t?
>>> 
>>> With Vector though, I don't know how we would differentiate code paths that 
>>> need large allocations from ones that don't. Nearly anything that is 
>>> exposed as a JS API or deals with external world can hit sizes over 4Gb. 
>>> That's not out of reach in most scenarios, not even for resources loaded 
>>> from network.
>>> 
>>> - Alexey
>>> 
>>> 
>>> 19 нояб. 2014 г., в 13:19, Filip Pizlo >> > написал(а):
>>> 
 ArrayBuffers are very special because they are part of ECMAScript.
 
 We use unsigned for the length, because once upon a time, that would have 
 been the right type; these days the right type would be a 53-bit integer.  
 So, size_t would be wrong.  I believe that ArrayBuffers should be changed 
 to use a very special size type; probably it wouldn't even be a primitive 
 type but a class that carefully checked that you never overflowed 53 bits.
 
 -Filip
 
 
> On Nov 19, 2014, at 12:54 PM, Alexey Proskuryakov  > wrote:
> 
> 
> This is not exactly about Vector, but if one uses 
> FileReader.prototype.readAsArrayBuffer() on a large file, I think that it 
> overflows ArrayBuffer. WebKit actually crashes when uploading 
> multi-gigabyte files to YouTube, Google Drive and other similar services, 
> although I haven't checked whether it's because of ArrayBuffers, or 
> because of a use of int/unsigned in another code path.
> 
> I think that we should use size_t everywhere except for perhaps a few key 
> places where memory impact is critical (and of course we need explicit 
> checks when casting down to an unsigned). Or perhaps the rule can be even 
> simpler, and unsigned may never be used for indices and sizes, period.
> 
> - Alexey
> 
> 
> 19 нояб. 2014 г., в 12:32, Filip Pizlo  > написал(а):
> 
>> Whatever we do, the clients of Vector should be consistent about what 
>> type they use.  I'm actually fine with Vector internally using unsigned 
>> even if the API uses size_t, but right now we have lots of code that 
>> uses a mix of size_t and unsigned when indexing into Vectors.  That's 
>> confusing.
>> 
>> If I picked one type to use for all Vector indices, it would be unsigned 
>> rather than size_t.  Vector being limited to unsigned doesn't imply 4GB 
>> unless you do Vector.  Usually we have Vectors of pointer-width 
>> things, which means 32GB on 64-bit systems (UINT_MAX * sizeof(void*)).  
>> Even in a world where we had more than 32GB of memory to use within a 
>> single web process, I would hope that we wouldn't use it all on a single 
>> Vector and that if we did, we would treat that one specially for a bunch 
>> of other sensible reasons (among them being that allocating a contiguous 
>> slab of virtual memory of that size is rather taxing).  So, size_t would 
>> buy us almost nothing since if we had a vector grow large enough to need 
>> it, we would be having a bad time already.
>> 
>> I wonder: are there cases that anyone remembers where we have tried to 
>> use Vector to store more than UINT_MAX things?  Another interesting 
>> question is: What's the largest number of things that we store into any 
>> Vector?  We could use such a metric to project how big Vectors might get 
>> in the future.
>> 
>> -Filip
>> 
>> 
>>> On Nov 19, 2014, at 12:20 PM, Chris Dumez >> > wrote:
>>> 
>>> Hi all,
>>> 
>>> I recently started updating the WTF::Vector API to use unsig

Re: [webkit-dev] support for navigator.cores or navigator.hardwareConcurrency

[Oliver Hunt]

On May 7, 2014, at 3:15 PM, Rik Cabanier  wrote:

> 
> 
> 
> On Wed, May 7, 2014 at 2:47 PM, Oliver Hunt  wrote:
> 
> On May 7, 2014, at 2:41 PM, Rik Cabanier  wrote:
> >
> > When would I as a user, not want a page or web application to be as fast as 
> > possible? Has a user ever complained about a desktop app that uses too many 
> > of his CPU's? I think Oliver's point was that other processes might fight 
> > for the same CPU resources but that is not unexpected for users.
> 
> What happen if i go to your website while i'm doing something else in the 
> background?  What if i'm playing a game while waiting for my machine to do 
> something else? What if your page is in the background? Or my battery is 
> running low.
> 
> Sure. However, a page can already do this today.
> This will just give the author a way to make a semi-informed decision. 
> Without this, he might just spin up too many threads and starve the rest of 
> the system.
>  
> You need to stop thinking in terms of a user wanting only one thing to happen 
> at a time.
> 
> I'm not sure if I follow. How would this be any different from a regular 
> desktop application?


The argument is that this is not behaviour that users want - the fact that 
desktop applications do this is a bug in the programming model.

APIs like GCD were specifically created to allow a developer to make an 
application than can automatically scale (or descale) to match the behaviour 
that is best for the user. That’s the model we want to encourage on the web.

—Oliver


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

Re: [webkit-dev] support for navigator.cores or navigator.hardwareConcurrency

[Oliver Hunt]

On May 7, 2014, at 2:41 PM, Rik Cabanier  wrote:
> 
> When would I as a user, not want a page or web application to be as fast as 
> possible? Has a user ever complained about a desktop app that uses too many 
> of his CPU's? I think Oliver's point was that other processes might fight for 
> the same CPU resources but that is not unexpected for users.

What happen if i go to your website while i'm doing something else in the 
background?  What if i'm playing a game while waiting for my machine to do 
something else? What if your page is in the background? Or my battery is 
running low.

You need to stop thinking in terms of a user wanting only one thing to happen 
at a time.

--Oliver

> ___
> 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] support for navigator.cores or navigator.hardwareConcurrency

[Oliver Hunt]

On May 5, 2014, at 6:13 PM, Rik Cabanier  wrote:
>  
> Do you really want a page to know that you have a  fancy-pants 24-core Mac 
> Pro rather than a little Mac mini?
> 
> Yes!
> If I have 24 cores ready to do work and the page can put them to use, I would 
> like it to do so.
> At the same time, if I just have a old mac mini, I don't want the page to 
> launch 24 workers as that will exhaust my memory and cause contention. 

But I don't have 24 cores available, i have 24 cores installed.  You have no 
idea what the actual workload of the system is, you don't know whether any 
other tabs are also using workers, you only have one piece of information, and 
that is nowhere near sufficient to make a reasonable choice.

A better solution would be to have a WorkerSet API where the browser is able to 
make a sensible choice given the current system, system load, power source, 
etc, etc

Generating workloads on the basis of # of installed cores has be attempted on 
every environment and it almost always leads to incorrect choices being made.

--Oliver

> 
> On May 5, 2014, at 4:58 PM, Filip Pizlo  wrote:
> 
>> I like this.  Personally, I don't see any downside.
>> 
>> Is there a bug (on bugs.webkit.org), and if not, can you create one? :-)
>> 
>> -Phil
>> 
>> 
>> On May 5, 2014 at 4:49:35 PM, Rik Cabanier (caban...@gmail.com) wrote:
>> 
>>> All,
>>> 
>>> there's a thread on blink-dev [1] and whatwg [2] to create a new parameter 
>>> on the navigator object that returns the maximum number of tasks that can 
>>> run in parallel. [3]
>>> 
>>> Is this something that WebKit would support?
>>> 
>>> 1: 
>>> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/B6pQClqfCp4
>>> 2: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2014-May/254200.html
>>> 3: http://wiki.whatwg.org/wiki/NavigatorCores
> 
> 
> ___
> 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] EFL EWS Bot output

[Oliver Hunt]

Could whoever is responsible for the EFL EWS bot please make the bot set the 
correct mimetype on the build output.

I've requested this before, but i'm trying again.  It is really annoying that 
it triggers a download rather than just opening in the browser like the output 
from every other bot.

Cheers,
  Oliver
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] [JavaScriptCore] When to JSValueProtect?

[Oliver Hunt]

On Dec 7, 2013, at 12:15 PM, Alexei Sholik  wrote:

> The garbage collector scans the C stack.
> 
> Hm, let me make sure I understand this correctly.
> ...
> I'm asking because I've never previously dealt with a library that scans the 
> host application's stack. So it sounds pretty incredible to me.

Every JSC vm will do a full conservative scan of the in use portion of the 
stack for every thread in your application whenever it needs to GC.  Anything 
that looks like it could be a pointer to a gc value is treated as though it is 
_definitely_ a GC value and marked accordingly.

> 
> Thanks!
>
> 
> 
> On Sat, Dec 7, 2013 at 9:37 PM, Geoffrey Garen  wrote:
> > At this point, the code is not inside the JS stack, so is it possible for 
> > an object to be collected between the calls to JSObjectMake and 
> > JSObjectCallAsFunction?
> 
> The garbage collector scans the C stack.
> 
> Geoff
> 
> 
> 
> -- 
> Best regards
> Alexei Sholik
> ___
> 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] WTF::fastMalloc

[Oliver Hunt]

On Oct 1, 2013, at 11:56 AM, Martin Robinson  wrote:

> On Tue, Oct 1, 2013 at 11:33 AM, Geoffrey Garen  wrote:
>>> A 5% regression in page load performance seems pretty serious.
>> 
>> I’m assuming you’re considering the GTK port here, and not the end-of-life 
>> Qt port.
>> 
>> Are you up for some engineering work to adopt a better malloc for GTK?
> 
> I appreciate your offer!
> 
>> Here’s a rough task list:
>> 
>> (1) Define a canonical GTK platform we’ll use for performance measurement.
> 
> Perhaps the University of Szeged team has some insight into what
> platforms they used for comparing allocator performance.
> 
>> (1) Refactor GTK APIs so that API-level objects are not allocated/deleted by 
>> global operator new/delete in WebCore+JavaScriptCore.
>>(1a) Either build the API layer as a separate library from 
>> WebCore+JavaScriptCore,
>>(1b) or specifically annotate each object at the API library with a 
>> per-class operator new / operator delete.
> 
> I don't think this should be a problem. Currently all allocations of
> API-level objects happen with the GLib slab allocator (or system
> malloc/free, given the right environment arguments).
> 
>> (2) Find a fast secure random number API on the canonical GTK platform.
> 
> I can look into this.

WTF has a custom implementation of arc4random(), i suspect most current Gtk 
host environments have a native one as well (s_rand on windows is terribly 
slow, but like i said, WTF has its own secure generator that will seed 
appropriately)

> 
>> (3) Find a fast thread-specific data API on the canonical GTK platform.
> 
> Threading for GTK+ on non-Mac/non-Windows platforms is essentially
> pthreads. It probably wouldn't be a lot of work to defer to Windows
> and Mac implementations on those platforms.

I recall linux having fast thread locals, as does windows.

--Oliver

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

Re: [webkit-dev] Changes in QtWebKit development

[Oliver Hunt]

On Oct 1, 2013, at 12:50 AM, Allan Sandfeld Jensen  wrote:

> On Monday 30 September 2013, Oliver Hunt wrote:
>> On Sep 30, 2013, at 7:41 AM, Allan Sandfeld Jensen  wrote:
>>> Some of this is exactly the reason we want to keep Qt WebKit alive. It
>>> may never be possible to fully replace Qt WebKit with anything
>>> Blink/Chromium based.
>> 
>> I really don’t understand this, there are only two options:
>> 1. Qt Webkit is critical to you and you want to support and maintain it,
>> and do all the work necessary for that; or 2. Qt WebKit is not critical,
>> and so you could simply branch and have a permanent stable release
>> platform similar to what the S60 port did years ago.
>> 
>> Currently you seem to be arguing for a third option, wherein all of the
>> WebKit developers need to deal with your port, and be hamstrung by the
>> numerous invasive Qt-isms scattered throughout the codebase, for a port
>> that isn’t considered critical to its own platform.
>> 
> Actually I am arguing we should get rid of most of the invasive Qt'ism unless 
> they are really required for Qt WebKit to even work. Many of them were only 
> necessary due to having to support so many platforms. With a more narrow 
> focus 
> we can hopefully get rid of 90% of the burden. If it turns out not to be 
> possible in the end, we can always leave after having helped as far as we 
> could.
> 

But why should webkit have _any_ burden when Qt itself cares so little about 
QtWebKit that it is happy to have qtisms that were ostensibly necessary for 
performance, etc removed?

My reading of that is that you are more willing to have the quality of QtWebKit 
deteriorate than to simply fork off a final high quality stable branch.

I don’t believe WebKit should be taking _any_ burden for a port that is 
primarily focused on a completely separate fork in an unrelated tree.

So could you please say whether the QtWebKit plan going forward is option 1 or 
option 2.

—Oliver

> Best regards
> `Allan

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

Re: [webkit-dev] Changes in QtWebKit development

[Oliver Hunt]

On Sep 30, 2013, at 7:41 AM, Allan Sandfeld Jensen  wrote:
> Some of this is exactly the reason we want to keep Qt WebKit alive. It may 
> never be possible to fully replace Qt WebKit with anything Blink/Chromium 
> based.

I really don’t understand this, there are only two options:
1. Qt Webkit is critical to you and you want to support and maintain it, and do 
all the work necessary for that; or
2. Qt WebKit is not critical, and so you could simply branch and have a 
permanent stable release platform similar to what the S60 port did years ago.

Currently you seem to be arguing for a third option, wherein all of the WebKit 
developers need to deal with your port, and be hamstrung by the numerous 
invasive Qt-isms scattered throughout the codebase, for a port that isn’t 
considered critical to its own platform.

—Oliver



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

Re: [webkit-dev] LLInt alignment problem on ARM

[Oliver Hunt]

I believe that there’s a mnemonic that forces alignment that we could (arguably 
should?) be using before these labels.

IIRC it’s something like .align N — if we aren’t doing this already we could 
make the lint assembler backend emit a .align 16 prior to each global symbol.

—Oliver

On Sep 26, 2013, at 1:09 AM, Gabor Rapcsanyi  wrote:

> Hello!
> 
> I'm fighting with a strange LLInt alignment problem on ARM. As I see we put 
> the LLInt code into .rodata section instead of .text.
> Is there a specific reason why we are doing this? If there is not I would put 
> them to the .text section.
> 
> Here is the objdump:
> 
> ./Source/JavaScriptCore/.obj/release-shared/llint/LowLevelInterpreter.o: file 
> format elf32-littlearm
> 
> Disassembly of section .rodata:
> 
>  <_ZStL19piecewise_construct>:
>   0:   andeq   r0, r0, r0
> 
> 0004 <_ZStL13allocator_arg>:
>   4:   andeq   r0, r0, r0
> 
> 0008 <_ZStL6ignore>:
>...
> 
> 0009 :
>   9:   e30b3eefmovwr3, #48879  ; 0xbeef
>   d:   e34b3badmovtr3, #48045  ; 0xbbad
>  11:   e583str r0, [r3]
>  15:   e3a0mov r0, #0
>  19:   e12fff30blx r0
> 
> 001d :
>  1d:   e1a0200emov r2, lr
>  21:   e5852010str r2, [r5, #16]
>  25:   e5951008ldr r1, [r5, #8]
> ...
> 
> 
> The problem is that these traditional instructions are lying on odd adresses 
> in the .rodata section.
> 
> Regards,
>  Gabor
> 
> ___
> 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] Can we disable "control reaches end of non-void function" warning on Qt?

[Oliver Hunt]

Hurk :-/

I guess there's no nice automate-able to handle everything magically.

Still it would probably be good to replace the default:ASSERT_NOT_REACHED() 
cases at least.

--Oliver

On Sep 13, 2013, at 10:33 AM, Darin Adler  wrote:

> On Sep 13, 2013, at 10:31 AM, Oliver Hunt  wrote:
> 
>> We may want to hunt through the other cases of default: ASSERT_NOT_REACHED() 
>> and clobber those with RELEASE_ASSERT_NOT_REACHED() as well.
>> 
>> I wonder if it would be easier to have DEFAULT_NOT_REACHED() and 
>> DEFAULT_OKAY() macros, and convince the style bot to require ether a 
>> default: block or one of these two macros at the end of every switch?
> 
> 
> Maybe.
> 
> The advantage of doing the not-reached assertion after the switch is that we 
> get the compile time warning if we don’t enumerate one of the enum values. 
> Having a default case turns that warning off.
> 
> -- Darin

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

Re: [webkit-dev] Can we disable "control reaches end of non-void function" warning on Qt?

[Oliver Hunt]

We may want to hunt through the other cases of default: ASSERT_NOT_REACHED() 
and clobber those with RELEASE_ASSERT_NOT_REACHED() as well.

I wonder if it would be easier to have DEFAULT_NOT_REACHED() and DEFAULT_OKAY() 
macros, and convince the style bot to require ether a default: block or one of 
these two macros at the end of every switch?

--Oliver

On Sep 13, 2013, at 10:29 AM, Darin Adler  wrote:

> On Sep 13, 2013, at 10:28 AM, Alexey Proskuryakov  wrote:
> 
>> 13 сент. 2013 г., в 10:13, Darin Adler  написал(а):
>> 
>>> Since there’s no runtime guarantee that the enum will have a valid value, I 
>>> think there needs to be a return statement outside the switch, even if we 
>>> have ASSERT_NOT_REACHED before it.
>> 
>> Should it be a RELEASE_ASSERT? If we have a bad value in an enum, it's 
>> likely a memory smasher, so it's best to crash before it's exploited.
> 
> Sure, that’d be OK with me.
> 
> -- Darin
> ___
> 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] Announcing new port: Nix

[Oliver Hunt]

On Sep 12, 2013, at 6:38 AM, Thomas Fletcher  wrote:
> TDLR: Crank Software Supports a NIX port
This is a question of maintenance burden.  As Geoff said every port adds a cost 
to developing and maintaining webkit.  You've said you support a NIX port, but 
a quick search doesn't show any contributions from you or crank software (very 
quick so feel free to correct me if i'm wrong) so it's hard to see what this 
"support" entails.

--Oliver


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

Re: [webkit-dev] Proposed feature: Network Service Discovery

[Oliver Hunt]

On Sep 6, 2013, at 9:44 AM, youenn fablet  wrote:

> Hi Ryosuke,
> 
> The two points you are mentioning make sense to me.
>  
> 
> For starters, most of users wouldn't even know what a local network is; let 
> alone what discovering media sources, etc... mean.
> 
> Most users may not be able to understand what means “discover local network 
> DACP servers”.
> But if a user is requested to grant/deny access to “Bob music library” 
> service (the service being a DACP server), the situation seems getting better.
> The spec is a work in progress and may be improved.

For the sake of argument let's say this "discovery" is allowed to occur.  How 
do you talk to "Bob music library" without the web page sending raw data 
to/from the DACP server?

--Oliver___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Proposed feature: Network Service Discovery

[Oliver Hunt]

On Aug 30, 2013, at 12:44 PM, Dirk Pranke  wrote:

> On Fri, Aug 30, 2013 at 10:06 AM, Oliver Hunt  wrote:
> 
> On Aug 30, 2013, at 9:15 AM, Brendan Long  wrote:
> 
> > On 08/29/2013 05:45 PM, Benjamin Poulain wrote:
> >> Can you explain a bit what it is for? What are the common use cases?
> > This would be useful for certain kinds of web apps. For example,a music 
> > website like Pandora or Spotify could allow users to include music on their 
> > local network. Or a service like Netflix could include local network movies 
> > (on networked hard drives, or DVR's) in their search results, and play them 
> > from the same interface.
> Here's my concern - if you say "a service like " might want to search for 
> something, that is better described as "a random website".  That may be 
> something the user wants, alternatively it could be something evil.  It could 
> also be something evil embedded in an ad on the site a user "trusts".
> 
> My concern here is that as a web spec this essentially acts as a way for 
> arbitrary web content from any source to perform a network scan of your local 
> machine and get data about your internal network topology and services from 
> inside your firewall.  That's a really scary concept to me.
> 
> While there are certainly security concerns that need to be  clearly thought 
> through and addressed, the spec isn't as broad as you make it sound. It picks 
> up services that are advertising themselves, after all; you can't probe. 
> (Unless you've noticed something in the spec I haven't; I've scanned the 
> spec, but not read it super-carefully).

Define advertise? Bonjour like? UPnP?


> The draft does contain the sentence "Web pages should not be able to 
> communicate with Local-networked Services that have not been authorized by 
> the user thereby maintaining the user's privacy" in the use cases section; 
> this should definite be emphasized and fleshed out, in a security section.

How does the user know what they're doing?  If there's an ad/unescaped comment 
containing something malicious should a remote site be able to know what 
services you have in your internal network?

> -- Dirk
> 

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

Re: [webkit-dev] Proposed feature: Network Service Discovery

[Oliver Hunt]

On Aug 30, 2013, at 9:15 AM, Brendan Long  wrote:

> On 08/29/2013 05:45 PM, Benjamin Poulain wrote:
>> Can you explain a bit what it is for? What are the common use cases?
> This would be useful for certain kinds of web apps. For example,a music 
> website like Pandora or Spotify could allow users to include music on their 
> local network. Or a service like Netflix could include local network movies 
> (on networked hard drives, or DVR's) in their search results, and play them 
> from the same interface.
Here's my concern - if you say "a service like " might want to search for 
something, that is better described as "a random website".  That may be 
something the user wants, alternatively it could be something evil.  It could 
also be something evil embedded in an ad on the site a user "trusts".

My concern here is that as a web spec this essentially acts as a way for 
arbitrary web content from any source to perform a network scan of your local 
machine and get data about your internal network topology and services from 
inside your firewall.  That's a really scary concept to me.

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

Re: [webkit-dev] Ports not building as C++11?

[Oliver Hunt]

So wait, is everyone using C++11 now?

I dream of using auto…

:-D

On Jul 28, 2013, at 12:47 PM, Gergely Kis  wrote:

> Hi,
> 
> On Sun, Jul 28, 2013 at 7:30 PM, Allan Sandfeld Jensen  
> wrote:
>> became required in WebKit2. The only fallout will likely be the loss of the 
>> Qt
>> MIPS bot which is maintained by a third party and is too old.
>> 
> The MIPS bot was updated to Debian Wheezy and GCC 4.7.2 a few weeks
> ago, I just forgot to update the buildbot slave info file, did it now.
> 
> Best Regards,
> Gergely
> the 3rd party maintaining the MIPS bot :)
> ___
> 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] FTL merge (and subsequent mayhem)

[Oliver Hunt]

(I meant to send this last night, so many apologies for the delay)

Last night I merged over the FTL branch to trunk, currently the FTL itself is 
guarded by ENABLE_FTL_JIT and HAVE_LLVM guards, however the branch does bring 
in a lot of general improvements to JSC's existing execution engines.

Unfortunately this has hosed all the non-Mac builds, and my initial attempt to 
fix the CMake based build systems had so little effect that I felt I needed 
assistance from engineers on those specific platforms, unfortunately none were 
around by the time I headed to bed.

I would like to apologise to the maintainers of those platforms that I 
destroyed, and offer my heart felt thanks to those who have already started 
getting the builds running.  I will be available all day today if help is 
needed, but to my knowledge this should primarily require updating project 
files *crosses fingers*.

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

Re: [webkit-dev] WebGL validations

[Oliver Hunt]

On Jul 15, 2013, at 4:04 AM, SzymanskiPrzemyslaw  
wrote:

> Hello.
> Valgrind shows that WebGL performance is lowered by WebGL validation methods 
> like: WebGLRenderingContext::validateRenderingState, 
> WebGLRenderingContext::validateUniformMatrixParameters  or validations in 
> drawElements/drawArrays. Those validations are done in the OpenGL driver. 
> WebKit use those validations mostly for console output.

The validation routines that you're talking are not simple logging functions: 
they are critical for WebGL to have any semblance of safety.

All of these validation routines have the following basic logic:

bool Thing::validateFoo() {
if (fooState is valid)
return true;
log(foo error)
return false;
}

all WebGL functions call the relevant validation functions and then abort if 
the validation returns false.

This validation is _not_ optional, even the WebGL spec talks about what is 
necessary.

> I propose to make some setting bool variable like: webgl_validations_enabled 
> = true/false and use it in WebGLRenderingContext.
> So if webgl_validations_enabled = false then WebKit should not validate WebGL 
> and performance will be increased. Typically user doesn’t need those 
> validations. It is helpful only for developers. So they can enable WebGL 
> validations by check webgl_validations_enabled = true.
> In WebKit it is a variable indicating to print messages to console so for 
> WebGL validations this solutions should also works.

Having an option to remove validation simply is not viable - if you wanted you 
could try to speed up the validation logic, but the validation cannot be 
dropped.

The validation is needed to achieve a semblance of safety in WebGL and the 
WebGL spec even specifies what validation must occur, so removing the 
validation would also result in incorrect behavior (relative to that specified 
by the spec.  Crashing the browser is also incorrect behavior :D )

>  
>  
> Regards,
> Przemyslaw Szymanski
>  

--Oliver

>  
> ___
> 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] All development moved private?

[Oliver Hunt]

Webkit development occurs on trunk and most communication is on IRC and in 
bugs.webkit.org.  If you rely on email to see signs of activity I recommend 
subscribing to webkit-commits (or whatever that list is called).  All it would 
have taken is the briefest look at webkit's svn or git repositories to see that.

Discussion on webkit-dev is usually about substantial changes, or in recent 
years bike shedding discussions that carry on with no apparent end.

--Oliver

On Jul 12, 2013, at 10:55 AM, Randall Bennett  wrote:

> I've noticed this list has basically gone silent.
> 
> I'm wondering if there's another place where I can find out about what's 
> being developed with Webkit, or if Webkit's public development has 
> essentially ceased now that Google has forked Blink.
> 
> rb
> ___
> 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] Pepper and NaCl supporting (prototype)

[Oliver Hunt]

Neither NaCl nor Pepper are trivial pieces of code, they would require 
maintenance if they were in trunk.  If they're not in trunk then the entire 
discussion on webkit-dev is moot as they would (by definition) not be present 
in WebKit.

You also haven't said _why_ they're a "cool and useful technology", which was 
my point.  What do they provide that is not already provided by the 
standardized_ web platform?

Taking a large pile of code, to support a platform with no obvious signs of 
standardization reeks of the "science experiment" concept we don't want in the 
tree.  I have not seen any evidence of a specification document anywhere, and 
without a spec document how can anyone else write their own implementation?

--Oliver

On Jul 11, 2013, at 5:46 AM, Jake  wrote:

> I would suggest you re-read the original post - Halton's work adds no 
> maintenance burden to the webkit project whatsoever. It does, however, make 
> some very cool and useful technology available to those who choose to use 
> webkit2. I believe that would qualify as obvious benefit.
> 
> 
> On Tue, Jul 9, 2013 at 12:49 PM, Oliver Hunt  wrote:
> Aside from any other issues, my recollection was that there had not been any 
> work to formally specify NaCl or Pepper, has that changed?
> 
> I'm also concerned as this adds a significant maintenance burden to the 
> project for no obvious benefit.
> 
> --Oliver
> 
> On Jun 30, 2013, at 11:41 PM, halton huo  wrote:
> 
>> Dear WebKit developers and users,
>> 
>> I’m pleased to announce the initial contribution of Pepper[1] and NaCl[2] 
>> support for WebKit2. The home page is located at 
>> https://github.com/nacl-webkit/native_client/wiki. 
>> The initial code include supporting of:
>> * Partial pepper api supporting includes: 2d, scripting, url_loader, file 
>> chooser, audio, mouse and keyboard events, websockets. 
>> * Basic NaCl support with post message api (HelloWorld from nacl_sdk)
>> 
>> There are some sceenshots on 
>> https://github.com/nacl-webkit/native_client/wiki/Screenshots 
>> 
>> Q&A
>> ===
>> Q: Why this project?
>> A: We enjoy working with the WebKit projects. We also enjoy technologies 
>> like NaCl, and wanted to lower the barrier to letting people integrate NaCl 
>> into their WebKit2 based projects. We prototyped this work and now want to 
>> make it available for others to use if they want.
>> 
>> Q: Can I modify and re-use the project?
>> A: Yes. The code is inherited from the Chromium, WebKit2 and native_client 
>> projects. As such, this project follows the same licenses.
>> 
>> Q: Why not upstream?
>> A: There are two main reasons. First, the current code is only a prototype 
>> to support NaCl in the Linux EFL port of WebKit2. There still remains work 
>> to be done before the patches would be appropriate to try and take upstream. 
>> Second, the WebKit community has stated in the past that they did not want 
>> NaCl upstream.
>> 
>> Q: How to contribute?
>> A: Fork the repo on github and submit the pull request, committers will 
>> review the patches. For the time being, the initial contributors are 
>> committers, we're welcome to anyone who can show his ability to be as 
>> committer. Follow the https://github.com/nacl-webkit/native_client/wiki/Code 
>> to get code and build.
>> 
>> Q: Any next plan?
>> A: We don't have any formal plans for the project moving forward; it is 
>> being developed as a part-time effort by a few engineers. As such, there is 
>> no guarantee for future work. Again, anyone is welcome to contribute! Or 
>> fork the project and run with it.
>> 
>> [1] http://code.google.com/p/ppapi/ 
>> [2] http://code.google.com/p/nativeclient/
>> ___
>> 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] Pepper and NaCl supporting (prototype)

[Oliver Hunt]

Aside from any other issues, my recollection was that there had not been any 
work to formally specify NaCl or Pepper, has that changed?

I'm also concerned as this adds a significant maintenance burden to the project 
for no obvious benefit.

--Oliver

On Jun 30, 2013, at 11:41 PM, halton huo  wrote:

> Dear WebKit developers and users,
> 
> I’m pleased to announce the initial contribution of Pepper[1] and NaCl[2] 
> support for WebKit2. The home page is located at 
> https://github.com/nacl-webkit/native_client/wiki. 
> The initial code include supporting of:
> * Partial pepper api supporting includes: 2d, scripting, url_loader, file 
> chooser, audio, mouse and keyboard events, websockets. 
> * Basic NaCl support with post message api (HelloWorld from nacl_sdk)
> 
> There are some sceenshots on 
> https://github.com/nacl-webkit/native_client/wiki/Screenshots 
> 
> Q&A
> ===
> Q: Why this project?
> A: We enjoy working with the WebKit projects. We also enjoy technologies like 
> NaCl, and wanted to lower the barrier to letting people integrate NaCl into 
> their WebKit2 based projects. We prototyped this work and now want to make it 
> available for others to use if they want.
> 
> Q: Can I modify and re-use the project?
> A: Yes. The code is inherited from the Chromium, WebKit2 and native_client 
> projects. As such, this project follows the same licenses.
> 
> Q: Why not upstream?
> A: There are two main reasons. First, the current code is only a prototype to 
> support NaCl in the Linux EFL port of WebKit2. There still remains work to be 
> done before the patches would be appropriate to try and take upstream. 
> Second, the WebKit community has stated in the past that they did not want 
> NaCl upstream.
> 
> Q: How to contribute?
> A: Fork the repo on github and submit the pull request, committers will 
> review the patches. For the time being, the initial contributors are 
> committers, we're welcome to anyone who can show his ability to be as 
> committer. Follow the https://github.com/nacl-webkit/native_client/wiki/Code 
> to get code and build.
> 
> Q: Any next plan?
> A: We don't have any formal plans for the project moving forward; it is being 
> developed as a part-time effort by a few engineers. As such, there is no 
> guarantee for future work. Again, anyone is welcome to contribute! Or fork 
> the project and run with it.
> 
> [1] http://code.google.com/p/ppapi/ 
> [2] http://code.google.com/p/nativeclient/
> ___
> 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] Feature announcement: WebCL

[Oliver Hunt]

On May 1, 2013, at 5:29 PM, Antonio Gomes  wrote:
> - 4.2 Cross-Origin Information Leakage
> WebCL's position is that this be handled by the same mechanism as used for 
> WebGL, ie https://www.khronos.org/registry/webgl/specs/latest/#4.2 . A bug 
> will be filed to request update of wording in the working draft.
> 
Thanks

> - 4.3 Out-of-Range Memory Access
> 
> The validator will perform static analysis on WebCL kernels to determine 
> violations of WebCL kernel behavior and language restrictions. The results 
> from the analysis will also be used to determine any necessary 
> instrumentation to bring the WebCL kernels in compliance with security and 
> syntactic requirements of the WebCL API.  The RFQ for the WebCL Validator 
> located at https://cvs.khronos.org/wiki/index.php/WebCL_Validator provides 
> information on the approach recommended by the WebCL working group. 
> 

How do you statically verify the all memory accesses are within bounds without 
limiting a WebCL kernel to the functionality already offered by shaders in 
WebGL?
> - 4.6 Prevention of potential denial of service (DoS) from long running 
> kernels:
> 
> This is addressed by the OpenCL CL_CONTEXT_TERMINATE extension. In 
> http://www.khronos.org/registry/cl/specs/opencl-1.2-extensions.pdf , please 
> refer to section "9.16 Terminating OpenCL contexts".
> 
I haven't seen any real evidence of widespread support for responsive 
termination in WebGL shaders yet, and given that the same hardware is involved 
when you want GPU backed WebCL I don't see how much this will help.

> It is chicken-egg problem: without Browser vendors commitment to WebCL, the  
> motivation for hardware vendors to implement, for example, OpenCL 1.2 "Memory 
> Initialization" and "Context termination" extensions, required by WebCL, is 
> not as strong.

The extensions mentioned above are required by WebGL shaders, and WebGL has 
been around for a lot longer (and has even more stringent requirements than 
WebCL) - are there any GPUs that support the WebGL restrictions natively?

--Oliver

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

Re: [webkit-dev] Feature announcement: WebCL

[Oliver Hunt]

Before i saw any patches landed i would expect the specification to state 
exactly what kernel features are allowed and required.

Additionally the specification language of the security section is fairly weak 
- 4.2 doesn't say how CORS will be used to achieve security.  Presumably WebCL 
just wants the WebGL security resource semantics, but the language needs to be 
explicit.

How is 4.3 enforced?

The only way to reliably enforce 4.4 is to either restrict the valid kernel 
constructs (see my first point - you aren't defining the kernel semantics 
sufficiently well), or to avoid ever pushing the kernels onto a gpu.  On the 
plus side not pushing the kernel to the GPU means executing on the CPU, and so 
having the benefit of sane interruption and memory access behavior, which 
neatly solves 4.6.

I'd rather not support the half-float format anywhere, as that simply means at 
some point in the communication paths we end up having to do a software double 
or single to half conversion, and back again later, all in order to support 
older GPUs that don't support single, assuming we even let the kernel get 
anywhere near the gpu.

In general I don't like the design of the API, I believe it over-exposes system 
information and doesn't sufficiently define edge case behavior.

--Oliver

On Apr 30, 2013, at 5:10 PM, Antonio Gomes  wrote:

> Hello.
> 
> As discussed before, Khronos has been working on a specification for WebCL, a 
> JavaScript API that exposes GPUs and multi-core processors for intensive 
> compute tasks. The latest version of the working draft is available here: [1].
> 
> Over the past weeks, some discussion involving WebCL took place in this 
> mailing list ([2]), when some concerns were raised, and to which I later on 
> tried to address in [3].
> 
> At this time, I would like to contribute our WebCL prototype implementation 
> [4] to WebKit.org.
> 
> Feature would be defined behind a ENABLE(WEBCL) feature flag, and work will 
> be tracked onhttps://bugs.webkit.org/show_bug.cgi?id=115457.
> 
> Let me know if you have any comments or concerns.
> 
> Cheers,
> 
> [1] 
> https://cvs.khronos.org/svn/repos/registry/trunk/public/webcl/spec/latest/index.html
>  
> [2] https://lists.webkit.org/pipermail/webkit-dev/2013-April/024546.html
> [3] https://lists.webkit.org/pipermail/webkit-dev/2013-April/024747.html
> [4] https://github.com/SRA-SiliconValley/webkit-webcl 
> 
> -- 
> --Antonio Gomes
> ___
> 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] Is there a plan for supporting multi-process and WebCL in webkit

[Oliver Hunt]

I'm not sure what you mean here: a parallel array is simply an array of 
numbers; there is nothing "magic" about it.

If we _really_ wanted to be blunt about it, we could simply say (in Array.map)

if (length >= giant && function.isEasyPeasy() && everything in the array is a 
number)
   return doHardcoreMap();

// carry on doing regular map
...

Understand that the parallel APIs have to do all of this as well, the only 
thing they lose is the "is everything a number" check

--Oliver

On Apr 10, 2013, at 12:50 PM, Dirk Pranke  wrote:

> Right, I get how ParallelArrays would work. I was asking Filip how you might 
> infer that an array could be a ParallelArray.
> 
> -- Dirk
> 
> On Wed, Apr 10, 2013 at 12:45 PM, Oliver Hunt  wrote:
> The parallel arrays apis aren't a magic "make my code parallel" wand.
> 
> They don't make general code parallel, they simply provide a bunch of 
> functions like map, etc where if you restrict your list of language features 
> to a specific subset, they'll vectorise it.
> 
> For instance
> 
> ParallelArray([1,2,3]).map(function(a,v) { return v * 2; })
> 
> would be vectorised
> 
> ParallelArray([1,2,3]).map(function(a,v) { return v.x * 2; })
> 
> wouldn't be.
> 
> This isn't "solve autovectorisation", this is "we've been given a specific 
> operation to perform on each element of an array, parallelise it if 
> possible", and what's possible is arbitrarily limited, and require a distinct 
> type that isn't an array.
> 
> --Oliver

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

Re: [webkit-dev] Is there a plan for supporting multi-process and WebCL in webkit

[Oliver Hunt]

The parallel arrays apis aren't a magic "make my code parallel" wand.

They don't make general code parallel, they simply provide a bunch of functions 
like map, etc where if you restrict your list of language features to a 
specific subset, they'll vectorise it.

For instance

ParallelArray([1,2,3]).map(function(a,v) { return v * 2; })

would be vectorised

ParallelArray([1,2,3]).map(function(a,v) { return v.x * 2; })

wouldn't be.

This isn't "solve autovectorisation", this is "we've been given a specific 
operation to perform on each element of an array, parallelise it if possible", 
and what's possible is arbitrarily limited, and require a distinct type that 
isn't an array.

--Oliver

On Apr 10, 2013, at 12:37 PM, Dirk Pranke  wrote:

> 
> 
> 
> On Wed, Apr 10, 2013 at 7:37 AM, Filip Pizlo  wrote:
> 
> 
> On Apr 10, 2013, at 2:29 AM, "Pozdnyakov, Mikhail" 
>  wrote:
> 
> >
> >
> >> Why not infer ParallelArrays automatically?
> > Sorry, did not get it. Could you please elaborate?
> 
> Normal JS arrays. You use them with pure computation. Profiler notices this. 
> And then the same things that you have in the ParallelArrays proposal now 
> work except you don't need a new type.
> 
> 
> Compiler writers have been chasing this problem for 50 years, with (AFAIK) 
> very limited success for languages that don't give you compile-time 
> annotations to help you along. I'm not aware of any work on JIT compilers 
> doing this. Why do you think we could do better? (Honest question, I'm not 
> trying to be snarky, nor am I an expert).
>  
> ___
> 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] Is there a plan for supporting multi-process and WebCL in webkit

[Oliver Hunt]

On Apr 10, 2013, at 9:44 AM, Jarred Nicholls  wrote:

> On Wed, Apr 10, 2013 at 9:33 AM, Antonio Gomes  wrote:
> Hi
> 
> On Wed, Apr 10, 2013 at 12:59 AM, Thibault Imbert  wrote:
> 
> Yes, leveraging multicore and the power of GPUs for general computations is 
> great and very powerful but first, securing such kernels is hard, and 
> authoring these would be pretty brutal to most web developers, I think this 
> is what Benjamin was referring to.
> 
> With WebCL, you are basically writing C style kernels that you load and run 
> to drive the computations, initiatives like RiverTrail are more restrictive 
> but way more approachable and closer to the web, exposing higher level 
> primitives on top of WebCL (ParallelArray for example) and integrated at the 
> language level, which makes a lot of sense.
> 
> 
> Security is a primary goal of WebCL, and both WebCL and OpenCL working groups 
> are working together to ensure a safe parallel programming environment to the 
> Web, as you can see in [1]. If you have specific concerns, please raise it in 
> the Khronos working group mailing list ([2]) or file a bug ([3]) against the 
> draft spec.
> 
> Particularly in terms of security, WebCL is to OpenCL as WebGL is to OpenGL.  
> Introducing "OpenGL" (i.e. WebGL) to the web had similar security concerns, 
> and yet…

OpenCL is fundamentally less safe than OpenGL+GLSL, so it not correct to say 
that the security concerns are similar.

There is no part of GLSL that is overtly operating on raw memory with arbitrary 
pointer access, whereas in OpenCL such functionality is a core primitive.  I am 
not saying that it will be impossible to make WebCL safe (after all OpenCL can 
trivially be kept on the cpu, which already has the assumption that it is 
running untrusted code), but whether you can keep it safe without completely 
compromising the programming and performance model remains to be seen.

--Oliver


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

Re: [webkit-dev] Deleting V8 bindings (was Cleaning House)

[Oliver Hunt]

There are plenty of other bindings - Gtk has a set of dom bindings i believe, 
there used to be COM (shudder) bindings as well, but those aren't the problem.  
We could have as many binding languages as we want, there's no major 
architectural reason not to.

But supporting javascript isn't simply a matter of another binding.  The 
complexity comes from javascript being the internal scripting language used by 
webcore for script tags, etc.  It's that complexity that creates the need for 
massive abstraction when supporting multiple distinct JS engines.  There is 
simply no way to support multiple JS engines without retaining the current 
abstraction - the fact that it's currently only present in order to support the 
existence of V8 isn't relevant - the same machinery would be necessary to 
support _any_ other JS engine in addition to JSC.

There is strictly no advantage to WebKit in keeping that machinery, it is 
purely performance and opportunity cost.  You need an _extremely_ compelling 
argument to outweigh those costs.

--Oliver

On Apr 4, 2013, at 11:15 PM, Per Bothner  wrote:

> On 04/04/2013 09:14 PM, Ryosuke Niwa wrote:
>> On the other hand, I don't think optimizing WebCore for JSC doesn't
>> necessarily mean it'll become impossible for you to have a custom build
>> of WebKit that uses some other binding code.  For example, Mac has
>> Objective-C bindings and that's not going anywhere in the foreseeable
>> future.
> 
> True, but Objective-C bindings are *in addition* to JSC.
> Our use of Nashorn *replaces* JSC.
> 
> Still, we can certainly have local changes in the code-base,
> like we currently do.  My worry is about the places the code
> hard-wires in an assumption on JSC - if those proliferate
> it will complicate us keeping updated with WebKit.
> 
> I can see the logic for simplifying, and I'm not asking you
> to support an alternative JavaScript engine where it
> complicates the code.  Just please keep in mind there are people
> who use WebKit *without* JSC.
> -- 
>   --Per Bothner
> per.both...@oracle.com   p...@bothner.com   http://per.bothner.com/
> ___
> 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] Cleaning House

[Oliver Hunt]

Supporting V8 places a considerable burden on webkit, there are a number of 
large, cumbersome and expensive abstractions required for to support multiple
JS engines (see the original discussions on the topic from many years ago).

Additionally we will only be supporting JSC in WebKit2, so I don't think 
anything could
convince me at least that maintaining support for multiple JS engines is good 
for
the project.

When thinking about which JS engines you want to se please consider that
JSC is webkit's main JS engine, that has a fast purely C backend that supports 
every
architecture under the sun, and even faster assembly support for at _least_ 
i386, x86-64,
ARMv5, Thumb2, MIPS, and SH4.  It has JITs for all of those CPUs as well, and
the DFG optimizing JIT support i386, x86-64, and Thumb2 (unsure about the other 
CPUs
in that list).

Adding support for more architectures is relatively simple courtesy of our well
designed cpu abstractions ;)

JSC also has an ABI stable pure C API, supports an essentially unlimited number
of independent VMs running concurrently in a single process, and execution on 
any given VM can be interleaved across multiple threads.

Given these many great and wondrous features, the support (at some level) for
_all_ architectures, the substantial cost of maintaining support for V8 bindings
does not seem worth it, at least to me.

If there are features that you do want that V8 provides, but JSC does not, you 
are
welcome to file bugs, or even contribute implementations :D

--Oliver



On Apr 4, 2013, at 3:56 AM, Mario Sanchez Prada  wrote:

> Hi,
> 
>> On Apr 4, 2013, at 1:39 AM, Allan Sandfeld Jensen 
> wrote:
>> [...]
>>  #if USE(V8)
>>  #if !USE(JSC)
> 
> Here at Samsung we are using WebKitGTK+ and V8, and I bet we are not the
> only ones doing it, so it would be great to keep those guards there.
> 
>> Geoff posted the list in part because we'd like to know if any of the
> things
>> above are used by other ports. We're not planning to remove things still
> in use.
> 
> Cool, thanks.
> 
> Mario
> 
> 
> ___
> 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] Opera and WebKit

[Oliver Hunt]

Welcome to webkit!

Are you still going to be using Carakan?  Or are you planning on using WebKit's 
ES engine?  If so are there any Carakan<->JSC compatibility issues we should be 
aware of?

--Oliver

On Feb 13, 2013, at 12:06 AM, Håkon Wium Lie  wrote:

> Dear WebKit community,
> 
> Many of us have met through various web standards efforts, such as
> W3C and WHAT WG. Today I'd like to introduce Opera Software in a new
> forum for us: the webkit-dev mailing list.
> 
> We have known WebKit and its KTHML predecessor for some time. Lars
> Knoll, who (re)wrote KHTML in 1999, worked for TrollTech for many
> years. TrollTech and Opera shared a building in Oslo, a building which
> has earned its place in the rendering engine hall of fame.
> 
> Some of our best programmers have been working on the WebKit code for
> a while, and today we have announced that we will be using the WebKit
> engine in the future [1]. We will also submit our code; switching from
> Presto to WebKit frees up resources and allows us to contribute to the
> WebKit platform.
> 
> The first contributions from our side will be in multi-column layout
> [2]. We have experimented with combining multicol layout with
> page floats and column spans [3]; in 10 lines of CSS code one can
> create amazingly beautiful, scaleable and responsive paged
> presentations [4].
> 
> We hope to work with you to further strengthen the open web that we
> all believe in.
> 
>   [1] http://www.opera.com/press/releases/2013/02/13/
>   [2] http://www.w3.org/TR/css3-multicol/
>   [3] http://dev.w3.org/csswg/css3-gcpm/#page-floats
>   [4] http://people.opera.com/howcome/2013/02-reader
> 
> Cheers,
> 
> Håkon Wium Lie
> CTO Opera Software
> http://people.opera.com/howcome
> ___
> 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] SerializedScriptValue: signed vs unsigned char

[Oliver Hunt]

On Feb 6, 2013, at 4:59 PM, Alec Flett  wrote:

> On Wed, Feb 6, 2013 at 4:48 PM, Maciej Stachowiak  wrote:
> 
> I think we should continue to use uint8_t instead of char as the primary way 
> to represent a raw byte in WebKit. First, it's good to distinguish raw data 
> from C strings at the type system level, and second, the unpredictable 
> signedness of char is actively bad for byte-oriented processing. Another 
> library making a different choice doesn't overcome these reasons.
> 
> To be fair, there hasn't been a convention in WebKit at all.  uint8_t was 
> chosen for SerializedScriptValue roughly two months ago, with specific 
> IndexedDB support in mind: https://bugs.webkit.org/show_bug.cgi?id=104354 - 
> this usage is not widespread, and in fact the only consumer of this type is 
> IndexedDB.

I don't know where you get this idea from -- SerializedScriptValue has always 
used uint8 buffers.  That IndexedDB used Strings and that _it_ changed to uint8 
buffers is entirely irrelevant here.

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

Re: [webkit-dev] Out-of-process networking and potential for sharing memory cache (was Re: Feature Announcement: Moving HTML Parser off the Main Thread)

[Oliver Hunt]

>> 
>> I take your word for it that it's not possible on Windows.
> 
> Given that Chromium has many users on Windows (and other non-Mac
> platforms), you should now understand why this design does not fit
> well with Chromium's design constraints.

But chromium doesn't use webkit or webkit2, so i'm not entirely sure why 
webkit2 design decisions should consider chromium's (pre-wk2) design decisions.

One thing that I'm unclear on is how having a distinct network process can 
possibly be less secure than a single thread in _any_ circumstance.  
Fundamentally any sandbox model that allows a single thread to be sandboxed, 
can just sandbox the main appropriate threads in the separate networking 
process, vice versa is not true however.

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

Re: [webkit-dev] Feature Announcement: Moving HTML Parser off the Main Thread

[Oliver Hunt]

How will we ensure thread safety?  Even at just the tokenizing level don't we 
use AtomicString?  AtromicString isn't threadsafe wrt StringImpl IIRC so this 
seems like it sould add a world of hurt.

I realise it's been a long time since I've worked on this so it's completely 
possible that I'm not aware of the current behaviour.

That aside I question what the benefit of this will be.  All those cases where 
we've started parsing html are intrinsically tied to the web's general "single 
thread of execution" model, which implies that even if we do push parsing into 
a separate thread we'll just end up with the ui thread blocked on the parsing 
thread which doesn't seem hugely superior.

What is the objective here? To improve performance, add parallelism, or reduce 
latency?

--Oliver

On Jan 9, 2013, at 6:10 PM, Adam Barth  wrote:

> On Wed, Jan 9, 2013 at 6:00 PM, Eric Seidel  wrote:
>> We're planning to move parts of the HTML Parser off of the main thread:
>> https://bugs.webkit.org/show_bug.cgi?id=106127
>> 
>> This is driven by our testing showing that HTML parsing on mobile is
>> be slow, and long (causing user-visible delays averaging 10 frames /
>> 150ms).
>> https://bug-106127-attachments.webkit.org/attachment.cgi?id=182002
>> Complete data can be found at [1].
> 
> In case it's not clear from that link, the "ParseHTML" column is the
> total amount of time the web inspector attributes to HTML parsing when
> loading those URLs on a Nexus 7 using a top-of-tree build of
> Chromium's content_shell (similar to WebKitTestRunner).
> 
> The HTML parser parses data a chunk at a time, which means the total
> time doesn't tell the whole story.  The "ParseHTML_max" column shows
> the largest single block of time spent in the HTML parser, which is
> more of a measure of the main thread "jank" caused by the parser.
> 
> Antti has pointed out that the inspector isn't the best source of
> data.  He measured total time using instruments, and got numbers that
> are consistent (within a factor of 2) of the inspector measurements.
> (We were using different data sets, so we wouldn't expect perfect
> agreement even if we were measuring precisely the same thing.)
> 
> Adam
> 
> 
>> Mozilla moved their parser onto a separate thread during their HTML5
>> parser re-write:
>> https://developer.mozilla.org/en-US/docs/Mozilla/Gecko/HTML_parser_threading
>> 
>> We plan to take a slightly simpler approach, moving only Tokenizing
>> off of the main thread:
>> https://docs.google.com/drawings/d/1hwYyvkT7HFLAtTX_7LQp2lxA6LkaEWkXONmjtGCQjK0/edit
>> The left is our current design, the middle is a tokenizer-only design,
>> and the right is more like mozilla's threaded-parser design.
>> 
>> Profiling shows Tokenizing accounts for about 10x the number of
>> samples as TreeBuilding.  Including Antti's recent testing (.5% vs.
>> 3%):
>> https://bugs.webkit.org/show_bug.cgi?id=106127#c10
>> If after we do this we measure and find ourselves still spending a lot
>> of main-thread time parsing, we'll move the TreeBuilder too. :)  (This
>> work is a nicely separable sub-set of larger work needed to move the
>> TreeBuilder.)
>> 
>> We welcome your thoughts and comments.
>> 
>> 
>> 1. 
>> https://docs.google.com/spreadsheet/ccc?key=0AlC4tS7Ao1fIdGtJTWlSaUItQ1hYaDFDcWkzeVAxOGc#gid=0
>> (Epic thanks to Nat Duca for helping us collect that data.)
> ___
> 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] Please avoid rolling out patches speculatively and reland them ASAP if you had to

[Oliver Hunt]

On Dec 11, 2012, at 2:17 PM, Peter Kasting  wrote:

> On Tue, Dec 11, 2012 at 2:14 PM, Oliver Hunt  wrote:
> I don't understand why anyone is _speculatively_ rolling out patches.
> 
> You should only be rolling it out if you _know_ the patch is bad.
> 
> Sometimes something bad happens to the tree, the sheriff doesn't know which 
> patch is responsible, and the change authors are not present to ask for help. 
>  In a case like this the sheriff has to either do speculative rollouts or 
> leave the tree broken.
> 
> Ideally, of course, change authors are around when something like this 
> happens.  But maybe the bustage doesn't happen until much later, due to some 
> subtle/latent issue, or maybe the change author is in fact irresponsible.

Or the sheriff could actually see if rolling out a patch locally fixes the 
problem.  I'm not sure why they're considering "not testing" to be a valid 
behaviour for someone who is ostensibly meant to be keeping things going in the 
face of people who aren't testing.


> 
> PK 

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

Re: [webkit-dev] Please avoid rolling out patches speculatively and reland them ASAP if you had to

[Oliver Hunt]

I don't understand why anyone is _speculatively_ rolling out patches.

You should only be rolling it out if you _know_ the patch is bad.

That said if you do rollout a random unrelated patch it is obviously your job 
to roll it back in.  You can't say "i thought this broke something, but i was 
wrong.  Here you can have that bug again."  There is no case where the original 
author needs to be involved as we've already determined that they did nothing 
wrong - the original breakage (of whatever form) was not caused by the patch 
you selected randomly, and they were not the author responsible for landing 
anything (eg. the rollout).

--Oliver

On Dec 11, 2012, at 1:21 PM, Peter Kasting  wrote:

> On Tue, Dec 11, 2012 at 1:19 PM, Emil A Eklund  wrote:
> > I don't understand your logic.  A patch landed, the sheriff thinks maybe it
> > was bad and rolls it out, then it turns out it was a red herring.  Why is it
> > not now the sheriff's responsibility to re-land?  After all, the patch was
> > landed originally by people who understood it and hasn't been seen to cause
> > any problems.
> 
> There might very well have been other changes that conflicts with it.
> If it applies cleanly then I agree with you that whoever rolled it out
> should reland it. If there are conflicts or if it requires merging in
> any way though I'd argue that the original author needs to get
> involved.
> 
> There are certainly cases where the original author needs to be involved, but 
> I'd be happy just saying this is a judgment call.  Usually rollouts happen 
> not long after a patch lands, and roll-ins happen not long after that.  In 
> those cases, most merge failures are trivial and mechanical and can easily be 
> handled by a conscientious sheriff who reads the relevant changes involved in 
> the conflicts.  Sometimes, of course, that's not true.  But sheriffs should 
> be biased towards "try to leave working patches in the tree".
> 
> PK
> ___
> 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] RenderArena: Teaching an old dog new tricks

[Oliver Hunt]

Since a common theme people are bringing up is vtable overrides, I do recall 
reading about vtable masking being available in some compilers.  I'm wondering 
if we should push for support for such in compilers we use - I'm not sure what 
the vcall perf hit is in such cases, but it would knock kill off vtable 
overwrites as an attack vector.  We can also trivially add vtable poisoning to 
dealloc if we felt it necessary - i'm not sure here if the problem is 
specifically use-after-free, use-after-free-and-overwritten-with-evil-data, or 
use-after-free-and-overwritten-with-another-object-with-a-different-type.

--Oliver

On Nov 15, 2012, at 2:08 AM, Chris Evans  wrote:

> On Thu, Nov 15, 2012 at 12:34 AM, Elliott Sprehn  wrote:
> 
> On Thu, Nov 15, 2012 at 3:22 AM, Chris Evans  wrote:
> 
> ...
> 
> My read on the Arena is that it's fragmentation resistant (i.e. it will not 
> repurpose a larger free chunk to satisfy a smaller allocation.) However, 
> memory usage at any given time is defined by peak usage since it cannot 
> release pages back to the system without ruining its security guarantee. 
> Interestingly, it can't be super bad: we already bite this bullet for 
> RenderArena as used by RenderObjects. The RenderArena lifetime is the same as 
> the document / DOM and I was surprised to recently be told that we don't 
> throw away the RenderArena on a full layout.
> 
> 
> My understanding is that the render tree is rather small compared to the DOM 
> in terms of memory usage on most pages
> 
> This does not seem to necessarily be the case.
> 
> Loading Gmail to the inbox view, sizes in bytes for all live allocations:
> - 541k in the DOM arena
> - At least a 918k plus a 49k render arena. May have failed to count a few 
> smaller ones that are still live.
> 
> Would you like similar measurements for a simpler page? Or some other 
> complicated page you think might be instructive?
> 
> 
> Cheers
> Chris
> 
> so not releasing it may not be so bad, but never releasing the memory used 
> from DOM nodes seems like it'd be bad for large web apps.
> 
> - E
> 
> ___
> 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] JavaScriptCore in Webkit

[Oliver Hunt]

How are you testing?

The "correct" method is the run-javascriptcore-tests script which compares the 
test output with an expected output.

As these are very old tests harvested from the spidermonkey test suite (old == 
maybe 7 or 8 years at this point), so there areanumber of expected failures 
(typically SpiderMonkey specific language and runtime extensions)

--Oliver

On Oct 2, 2012, at 7:29 PM, HOAT  wrote:

> Hello all, I'm testing JavaScriptCore.lib (build in Webkit).
> But when run testcase : "Function_object" in 
> JavaScriptCore\tests\mozilla\js1_2\function\Function_object.js
> it FAILED at f.arity
> So, who can tell me what f.arity
> Is it as f.length or is it obsolete.
> Thank all.
> ___
> 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] Is there a rule to use UNUSED_PARAM ?

[Oliver Hunt]

On Oct 1, 2012, at 8:47 AM, Ryosuke Niwa  wrote:

> On Mon, Oct 1, 2012 at 7:07 AM, Dirk Schulze  wrote:
> 
> 
> On Monday, October 1, 2012, Gyuyoung Kim wrote:
> Hello WebKit folks,
> 
> There were build warning related to unused parameter nowadays. I think there 
> are three solutions. One is to remove parameter,
> another is to use UNUSED_PARAM macro and the other is to use /* */ in 
> parameters.
> 
> I like to use UNUSED_PARAM macro except for primitive parameters personally, 
> for example
> 
> void foo(RenderObject* object, int /*width*/, int /*height*/) {
> UNUSED_PARAM(object);
> }
> 
> I'd like to know what webkittens think about this.
> 
> If it is crystal clear what the parameters stand for, omit them. If not, you 
> find them commented out. UNUSED_PARAM is used when just some platforms of 
> flagged features use parameters, others not.
> 
> or only used in ASSERTs.

That's what the ASSERT_UNUSED(variable, assertion) macro is for :D

--Oliver

> 
> - Ryosuke
> 
> ___
> 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] platform-specific differences in test case inputs

[Oliver Hunt]

It isn't, it's never been a concern as our serialisation format is simple 
enough to be hard to break.  That said tests would be fine, i'm just not sure 
how you would do them nicely.

--Oliver

On Sep 19, 2012, at 1:50 PM, Alec Flett  wrote:

> So this thread kinda died. Anyone have any suggestions? Where is JSC's 
> SerializedScriptValue consistency tested? 
> 
> Alec
> 
> On Tue, Sep 18, 2012 at 1:22 PM, Alec Flett  wrote:
> Sorry I totally left out the "I expose this through Internals" - and adam has 
> explained the rationale
> 
> On Tue, Sep 18, 2012 at 12:46 PM, Oliver Hunt  wrote:
> What exactly are you trying to test here?  The internal serialisation format 
> isn't exposed anywhere (nor should it be).
> 
> By definition newer formats won't be backwards compatible, or are you trying 
> to ensure that newer deserialisers will be able to continue to deserialise 
> old content?
> 
> exactly.
> 
> Where does JSC test this? I'm happy to follow whatever pattern is already 
> established.
> 
> Alec
> 
> ___
> 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] platform-specific differences in test case inputs

[Oliver Hunt]

What exactly are you trying to test here?  The internal serialisation format 
isn't exposed anywhere (nor should it be).

By definition newer formats won't be backwards compatible, or are you trying to 
ensure that newer deserialisers will be able to continue to deserialise old 
content?

--Oliver


On Sep 18, 2012, at 12:19 PM, Alec Flett  wrote:

> Background: some of the storage systems use SerializedScriptValue to persist 
> structured-clonable objects 
> (http://www.w3.org/TR/html5/common-dom-interfaces.html#safe-passing-of-structured-data)
>  - most of this is implemented in a V8 or JSC-specific implementation of 
> SerializedScriptValue.
> 
> I'm adding tests for the actual values stored with SerializedScriptValue so 
> that we can move forward with serialization changes without breaking 
> backwards compatibility.
> 
> So many of my js tests boil down to:
> 
> testSerialization({}, [0x01ff, 0x003f, 0x7b6f, 0x]);
> 
> Which makes sure that these two representations are equivalent by going in 
> both directions.
> 
> The issue I'm hitting is that JSC has a different implementation with a 
> different storage format, and the serialization/deserialization between the 
> two storage formats is not compatible - the above code works great on V8 but 
> JSC uses different bytes. 
> 
> I can't address this with just expectations files (i.e. only check that {} 
> serializes to some byte array, and have different expectations depending on 
> the port) because I need to check that specific inputs (such as old V8-based 
> formats) can also deserialize back into the right native objects.
> 
> What I kind of want is something like:
> 
> #ifdef JSC
>  
> #endif
> 
> #ifdef V8
>  
> #endif
> 
> Thoughts?
> ___
> 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] platform-specific differences in test case inputs

[Oliver Hunt]

JSC's SerializedScriptValue has always been versioned (having learned the 
horror of no versioning with localStorage :( )

Newer formats (obviously) can't be read by older clients, but the serialisation 
is intentionally forwards compatible.

--Oliver

On Sep 18, 2012, at 12:36 PM, Adam Barth  wrote:

> This is an interesting case because it's important for the
> serialization format to be consistent across time (so that an
> IndexedDB created at one point in time can work at another point in
> time), but it's not important to be consistent across embedders
> (because IndexedDB created by Safari don't need to be readable by
> Chrome and vice versa).
> 
> Perhaps we shouldn't use LayoutTests to test this functionality.
> Instead, it might make more sense to use API-level tests that check
> that a particular embedder API is stable and working as expected.
> 
> Adam
> 
> 
> On Tue, Sep 18, 2012 at 12:19 PM, Alec Flett  wrote:
>> Background: some of the storage systems use SerializedScriptValue to persist
>> structured-clonable objects
>> (http://www.w3.org/TR/html5/common-dom-interfaces.html#safe-passing-of-structured-data)
>> - most of this is implemented in a V8 or JSC-specific implementation of
>> SerializedScriptValue.
>> 
>> I'm adding tests for the actual values stored with SerializedScriptValue so
>> that we can move forward with serialization changes without breaking
>> backwards compatibility.
>> 
>> So many of my js tests boil down to:
>> 
>> testSerialization({}, [0x01ff, 0x003f, 0x7b6f, 0x]);
>> 
>> Which makes sure that these two representations are equivalent by going in
>> both directions.
>> 
>> The issue I'm hitting is that JSC has a different implementation with a
>> different storage format, and the serialization/deserialization between the
>> two storage formats is not compatible - the above code works great on V8 but
>> JSC uses different bytes.
>> 
>> I can't address this with just expectations files (i.e. only check that {}
>> serializes to some byte array, and have different expectations depending on
>> the port) because I need to check that specific inputs (such as old V8-based
>> formats) can also deserialize back into the right native objects.
>> 
>> What I kind of want is something like:
>> 
>> #ifdef JSC
>>  
>> #endif
>> 
>> #ifdef V8
>>  
>> #endif
>> 
>> Thoughts?
>> 
>> ___
>> 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] Pre-proposal: Adding a Coverity instance for WebKIt

[Oliver Hunt]

My preference would simply be to improve the Clang static analyser - it's free, 
open source, etc.

I periodically run that analyzer on JSC, but apparently their ToT code has many 
improvements over stable.

--Oliver

On Sep 17, 2012, at 9:20 PM, Brent Fulgham wrote:

> Hi Gang,
> 
> On Sep 17, 2012, at 4:11 PM, James Hawkins  wrote:
> 
>> TL;DR - If you have opinions one way or another about having a Coverity 
>> instance available for WebKit developers, please respond to this message.
> 
> I have used Coverity at on a couple of occasions, without modifying source 
> code to help the static analyzer. While its rather high cost has prevented me 
> from using it recently, I did think that it provided enough signal-to-noise 
> that I really wish I still had it.
> 
> I think one of its main advantages is the ability to have it run over the 
> entire source tree periodically to do larger-scale analysis than we can do 
> looking at individual changesets.
> 
> Many of the bugs it found were of the 'uninitialized variable' type, but I 
> did find that it could dredge up some very clever edge cases that were 
> definitely worth fixing.
> 
> Since the cost to the project is effectively zero, I think we would be very 
> foolish not to take advantage of this very generous offer.
> 
> Thanks,
> 
> -Brent
> 
> ___
> 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] unsigned vs unsigned int

[Oliver Hunt]

Does the style bot pick up "unsigned int" etc?

--Oliver

On Sep 13, 2012, at 1:19 PM, Ryosuke Niwa  wrote:

> Landed in http://trac.webkit.org/changeset/128499 (Thanks ggaren!)
> 
> On Thu, Sep 13, 2012 at 12:29 PM, Ryosuke Niwa  wrote:
> Uploaded a patch on https://bugs.webkit.org/show_bug.cgi?id=96682.
> 
> - Ryosuke
> 
> On Thu, Sep 13, 2012 at 8:11 AM, Dan Bernstein  wrote:
> 
> 
> On Sep 13, 2012, at 1:29 AM, Kenneth Rohde Christiansen 
>  wrote:
> 
> > Hi there,
> >
> > I was telling people to use "unsigned" instead of "unsigned int", as I
> > have been told that was the preferred style before, but apparently
> > that is not in the style guide.
> >
> > The question is, should it be?
> 
> Yes.
> 
> >
> > A few greps in the code:
> >
> > "unsigned" -> 18406 occurrences.
> > "unsigned int" -> 1721
> > "unsigned i =" -> 1548
> >
> > It does in fact seem to be the preferred style.
> >
> > Cheers
> > Kenneth
> >
> > --
> > Kenneth Rohde Christiansen
> > Senior Engineer, WebKit, Qt, EFL
> > Phone  +45 4093 0598 / E-mail kenneth at webkit.org
> >
> > ﹆﹆﹆
> > ___
> > 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] Non JS Function call.

[Oliver Hunt]

op_call_NotJSFunction is only referenced during the final linking phase.

Actual compilation requires two distinct operations:  1) planting the call 
instruction and 2) linking the call target after the code has been relocated.  
Here is the (64-bit) version of the call + link logic:

...
preserveReturnAddressAfterCall(regT3);
emitPutToCallFrameHeader(regT3, RegisterFile::ReturnPC);
emitPutImmediateToCallFrameHeader(0, RegisterFile::CodeBlock);

storePtr(callFrameRegister, &m_globalData->topCallFrame);
restoreArgumentReference();
Call callCallNotJSFunction = call(); <-- here is the call
emitGetFromCallFrameHeaderPtr(RegisterFile::CallerFrame, callFrameRegister);
restoreReturnAddressBeforeReturn(regT3);
ret();
...
patchBuffer.link(callCallNotJSFunction, 
FunctionPtr(cti_op_call_NotJSFunction));  <-- here is us linking the call

--Oliver



On Jul 24, 2012, at 1:45 PM, vahe vardanyan wrote:

> Grep gives nothing, there is only one mention of op_call_NotJSFunction in 
> privateCompileCTIMachineTrampolines(JITOpcodes.cpp), but I don't see any call 
> instruction there.
> 
> Still can't understand how calls orgonized in SXF.  
> 
> On 24 July 2012 20:07, Filip Pizlo  wrote:
> 
> On Jul 24, 2012, at 5:51 AM, vahe vardanyan  wrote:
> 
> > Hi all.
> >
> > As I understand in SFX all non JS functions calls go trough 
> > JITStubs:op_call_NotJSFunction function.
> >
> > But in which point, where, the op_call_NotJSFunction function is called?
> 
> It's called from code generated by the JIT. I would start by running a 
> command called "grep" on the code in the "jit" directory to search for 
> mentions of NotJSFunction.
> 
> >
> > Can anyone please explain how function calls are implemented in SFX(simple 
> > jit).
> >
> > Thanks for attention
> > ___
> > 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] SH4, MIPS, and legacy-ARM assemblers in JavaScriptCore

[Oliver Hunt]

That would be the ifdef hell we currently deal with. 

One option (that would keep everything building till appropriate people have 
fixed whatever needs to be fixed) would simply be to disable the JIT for 
effected platforms everytime something changes that is too difficult for us to 
blindly fix.  Then people with appropriate hardware and toolchains could make 
the (probably trivial) changes required to bring them up again.

--Oliver

On Jun 22, 2012, at 11:20 AM, Maciej Stachowiak wrote:

> 
> Is there a way to reduce these costs other than deleting the 
> slower-maintained JITs? For example, could we temporarily freeze the JIT 
> (perhaps the whole JSC engine somehow) at old versions somehow for 
> architectures that may take time to catch up?
> 
> Regards,
> Maciej
> 
> On Jun 22, 2012, at 10:52 AM, Oliver Hunt  wrote:
> 
>> The problem is that as we make changes we end up breaking the SH4, MIPS, 
>> ARMvOld builds, which we are ostensibly not allowed to do, and so have to 
>> spend significant amounts of time trying to ensure that the builds don't 
>> break/start failing horribly, and then having committed the patch[es] we 
>> have to spend multiple build bot cycles discovering all the cases that we 
>> missed.
>> 
>> This consumes a lot of time that would be better spent working on the higher 
>> level portions of the JIT, that benefit all platforms.
>> 
>> --Oliver
>> 
>> On Jun 21, 2012, at 11:44 PM, Zoltan Herczeg wrote:
>> 
>>> Hi Filip,
>>> 
>>> we (Gabor Loki and me) are the maintainers of the traditional ARM port,
>>> and we are willing to fix all issues. Just let us know what we need to do.
>>> You can assign the necessary bug reports to us and we are available in the
>>> #squirrelfish (or #webkit) channel as well.
>>> 
>>> Regards,
>>> Zoltan
>>> 
>>>> Hi all,
>>>> 
>>>> We are actively trying to improve the WebKit JavaScript engine
>>>> (JavaScriptCore), with new debugging, profiling, memory efficiency, and
>>>> performance features.  Because JavaScriptCore is a JIT-based engine, this
>>>> inevitably means doing JIT work, which in turn includes adding new
>>>> instructions to the JIT assemblers and changing the API between the
>>>> assemblers and the JIT.
>>>> 
>>>> Currently, the maintenance situation in the assembler layer is not great.
>>>> We have three well-supported assemblers, X86-32, X86-64, and ARMv7. Then
>>>> we have three assemblers that appear to be on life support: legacy
>>>> (non-THUMB2, pre-v7) ARM, SH4, and MIPS.  It is increasingly painful to
>>>> maintain these three barely-supported assemblers.  None of these
>>>> assemblers has been updated to support the new JIT or interpreter
>>>> infrastructure, and there appears to be no ongoing effort to do so.  That
>>>> means that for progress to be made on X86 and ARMv7, we need to
>>>> increasingly scatter #if ENABLE(...) noise throughout the system to keep
>>>> those other assemblers building.  Neither the active JavaScriptCore
>>>> contributors, nor those running the bots for those hardware platforms,
>>>> appear to have much interest in maintaining those assemblers, other than
>>>> the occasional build fix.
>>>> 
>>>> This is not a good situation to be in.
>>>> 
>>>> So, I am curious: is anyone shipping with the legacy ARM assembler, the
>>>> MIPS assembler, or the SH4 assembler?
>>>> 
>>>> As a secondary question, if you are shipping the legacy ARM assembler, are
>>>> you doing so because you have legacy ARM hardware or because you have not
>>>> had the chance to switch to the new ARM assembler in your codebase?
>>>> 
>>>> -Filip
>>>> 
>>>> 
>>>> ___
>>>> 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] SH4, MIPS, and legacy-ARM assemblers in JavaScriptCore

[Oliver Hunt]

The problem is that as we make changes we end up breaking the SH4, MIPS, 
ARMvOld builds, which we are ostensibly not allowed to do, and so have to spend 
significant amounts of time trying to ensure that the builds don't break/start 
failing horribly, and then having committed the patch[es] we have to spend 
multiple build bot cycles discovering all the cases that we missed.

This consumes a lot of time that would be better spent working on the higher 
level portions of the JIT, that benefit all platforms.

--Oliver

On Jun 21, 2012, at 11:44 PM, Zoltan Herczeg wrote:

> Hi Filip,
> 
> we (Gabor Loki and me) are the maintainers of the traditional ARM port,
> and we are willing to fix all issues. Just let us know what we need to do.
> You can assign the necessary bug reports to us and we are available in the
> #squirrelfish (or #webkit) channel as well.
> 
> Regards,
> Zoltan
> 
>> Hi all,
>> 
>> We are actively trying to improve the WebKit JavaScript engine
>> (JavaScriptCore), with new debugging, profiling, memory efficiency, and
>> performance features.  Because JavaScriptCore is a JIT-based engine, this
>> inevitably means doing JIT work, which in turn includes adding new
>> instructions to the JIT assemblers and changing the API between the
>> assemblers and the JIT.
>> 
>> Currently, the maintenance situation in the assembler layer is not great.
>> We have three well-supported assemblers, X86-32, X86-64, and ARMv7. Then
>> we have three assemblers that appear to be on life support: legacy
>> (non-THUMB2, pre-v7) ARM, SH4, and MIPS.  It is increasingly painful to
>> maintain these three barely-supported assemblers.  None of these
>> assemblers has been updated to support the new JIT or interpreter
>> infrastructure, and there appears to be no ongoing effort to do so.  That
>> means that for progress to be made on X86 and ARMv7, we need to
>> increasingly scatter #if ENABLE(...) noise throughout the system to keep
>> those other assemblers building.  Neither the active JavaScriptCore
>> contributors, nor those running the bots for those hardware platforms,
>> appear to have much interest in maintaining those assemblers, other than
>> the occasional build fix.
>> 
>> This is not a good situation to be in.
>> 
>> So, I am curious: is anyone shipping with the legacy ARM assembler, the
>> MIPS assembler, or the SH4 assembler?
>> 
>> As a secondary question, if you are shipping the legacy ARM assembler, are
>> you doing so because you have legacy ARM hardware or because you have not
>> had the chance to switch to the new ARM assembler in your codebase?
>> 
>> -Filip
>> 
>> 
>> ___
>> 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] webkit2 with v8

[Oliver Hunt]

They may have a desire for it, but certainly not a need -- Webkit includes a 
well maintained, guaranteed ABI stable JS engine that works on _all_ 
architectures, with a high performance JIT support available on numerous 
architectures and OS's.  Being able to support two engines just in webcore has 
added substantial complexity to the codebase, and has led to many features 
being implemented only for one engine but not the other.  There is a very large 
and substantial cost to this, and very little actual benefit.

We have repeatedly stated that support for JS engines other than that provided 
by webkit is not a primary goal of webkit, and ports that wish to make use of 
any other engines do so at their own risk, and there attempts to do so can't 
interfere with the actual webkit project.

--Oliver

On Jun 1, 2012, at 10:12 AM, Jake wrote:

> What constitutes a need? Qt obviously has a need for it. Is there a threshold 
> of ports needing a feature before it becomes blessed?
> 
> 
> On Fri, Jun 1, 2012 at 11:09 AM, Darin Adler  wrote:
> On Jun 1, 2012, at 9:55 AM, Jake  wrote:
> 
> > I believe it's a disservice to the community as a whole to not provide 
> > proper javascript engine abstractions in webkit.
> 
> I don’t agree.
> 
> We should have abstractions for things that need to be abstract. Too many 
> abstractions make the code much harder to work with.
> 
> -- Darin
> 
> ___
> 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] SFX instructions emission slow cases

[Oliver Hunt]

LLInt is on if the target platform is a supported architecture (currently only 
x86, x86-64, and ARM w/Thumb2 I believe) on a platform with an ABI we 
understand (which I believe is normal unix-derivative cdecl)

--Oliver

On Apr 18, 2012, at 4:35 AM, wingoog moon wrote:

> 
> Thanks for anwers.
> Can you please tell more about  LLInt and is it turned on by default?
> On Wed, Apr 18, 2012 at 12:48 PM, Filip Pizlo  wrote:
> JavaScript is a dynamically typed language. Therefore, we cannot know for 
> sure what types of values may flow into an instruction at the time we compile 
> it. a + b may be an integer addition that produces an integer result, an 
> integer addition that overflows and produces a double, an addition of a 
> double to an integer, an addition of an integer to a double, a double 
> addition, a string concatenation, or an "object-to-value" conversion followed 
> by any of the previous.
> 
> But the common case is typically going to be an integer addition or a double 
> addition.
> 
> Therefore, the baseline JIT (which you seem to be looking at) has a fast path 
> for the common cases and a slow path for the uncommon ones.  The slow path 
> almost always results in a C function call, which then does all of the magic 
> necessary to satisfy JS semantics.
> 
> Similar things happen for almost all other JS instructions: there is a simple 
> path for the cases we have found to be common and a slow-path C function call 
> for the rare cases.
> 
> The slow paths are emitted as a separate piece of out-of-line code because 
> that optimizes instruction cache locality for the main path, and helps a bit 
> with branch prediction.
> 
> However, if you want to see how JSC actually makes JavaScript run fast, you 
> should probably also look at either the LLInt (which enables very fast 
> start-up by using a well-tuned threaded OSR-capable interpreter) or the DFG 
> (which enables high throughput for longer-running code by leveraging value 
> profiling to avoid having to deal with JS's dynamism in most cases). The 
> baseline JIT is still probably important for performance, but this is 
> becoming less and less true as the LLInt is likely to get faster and the DFG 
> is likely to expand coverage to more kinds of code (DFG still cannot compile 
> some functions at all due to missing opcode support).
> 
> -F
> 
> 
> 
> On Apr 18, 2012, at 1:39 AM, wingoog moon wrote:
> 
>> Hi!
>> As I understand there are two passes to translate SFX bytecode to the native 
>> code(functions privateCompileMainPass() and   privateCompileSlowCases()).
>> So whats the purpose of privateCompileSlowCases(). Why we need slow cases 
>> for each bytecodeInstruction? Is it needed when arguments of instruction not 
>> integer or something else?
>> 
>> Thanks for attention! 
>> ___
>> 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] Feature announcement: canvas pixel access API additions for high-resolution backing stores

[Oliver Hunt]

On Apr 16, 2012, at 1:44 PM, Darin Fisher  wrote:
> I'm not sure why developers would choose to ignore HiDPI.  It seems like it 
> helps their apps/pages look better!
> 
> You really feel like you need to "kowtow" to developers to get them to adopt 
> HiDPI?

The existing API supported high dpi, no one wrote there code to handle it 
because no one really uses it.  It will be decades before high dpi is the norm 
(eg. it will remain a "no one really uses it" feature), so why would you go for 
the more complex and slower code path to support something that will in general 
not effect anyone?

--Oliver

> 
> -Darin
> 
>  
>> 
>> -Darin
>> 
>>  
>>> 
>>> Regards,
>>> -Darin
>>> 
>>> 
>>> 
>>> On Thu, Apr 12, 2012 at 6:17 PM, Dan Bernstein  wrote:
>>> [This is actually an enhancement announcement to an existing feature]
>>> 
>>> Over at 
>>> ,
>>>  Edward O’Connor has proposed enhancements to CanvasRenderingContext2D to 
>>> allow authors to take full advantage of high-resolution backing stores, 
>>> when available (whereas the existing API hides the fact that the backing 
>>> store resolution is not CSS pixel resolution, for compatibility with 
>>> existing content). The enhancements include a backingStorePixelRatio 
>>> attribute and {get,put}ImageDataHD functions on CanvasRenderingContext2D.
>>> 
>>> Through  and 
>>> , I am making these 
>>> enhancements, with the names prefixed with “webkit”.
>>> 
>>> There is no build-time option to disable these enhancements. Ports that 
>>> don’t opt into ENABLE_HIGH_DPI_CANVAS get a working, albeit boring, version 
>>> of the additional API. Ports that opt into high-DPI canvas need to enhance 
>>> their ImageBuffer implementation to fully support the resolutionScale and 
>>> CoordinateSystem parameters.
>>> ___
>>> 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] Feature announcement: canvas pixel access API additions for high-resolution backing stores

[Oliver Hunt]

On Apr 16, 2012, at 1:00 PM, Darin Fisher  wrote:

> On Mon, Apr 16, 2012 at 12:55 PM, Maciej Stachowiak  wrote:
> 
> On Apr 16, 2012, at 10:52 AM, Darin Fisher wrote:
> 
>> Could this be an opportunity to design an asynchronous API for fetching the 
>> pixel buffer?  It seems like many implementations are GPU backed now, and 
>> fetching the pixel buffer is an expensive (blocking) operation.  Had you 
>> considered making such a change?
> 
> Adding async support was suggested on the whatwg thread about this. I think 
> async support is useful, but should not be tied to high DPI support. In 
> particular, we shouldn't, in my opinion, require authors to rewrite their 
> existing sync code to an async model just to properly support higher 
> resolutions.
> 
> In addition, the whatwg thread revealed that there are many hidden 
> complexities in the design of get/putImageData, in particular designing how 
> they work in the face of sychronous drawing operations to the same canvas. 
> The HiDPI problem is much more straightforward and does not need to be gated 
> on resolving the async design issues.
> 
> 
> I think you are giving up a good opportunity.  The barriers to an async API 
> are more readily overcome when there are extra benefits to developers.  HiDPI 
> could be a great way to attract developers to a better API.
> 
> I've addressed those other concerns on the WhatWG thread.

No, gating HiDPI on rewriting your code into a more complex, and generally 
slower model seems like a great way to encourage developers to ignore high dpi.

--Oliver

> 
> -Darin
> 
>  
>> 
>> Regards,
>> -Darin
>> 
>> 
>> 
>> On Thu, Apr 12, 2012 at 6:17 PM, Dan Bernstein  wrote:
>> [This is actually an enhancement announcement to an existing feature]
>> 
>> Over at 
>> ,
>>  Edward O’Connor has proposed enhancements to CanvasRenderingContext2D to 
>> allow authors to take full advantage of high-resolution backing stores, when 
>> available (whereas the existing API hides the fact that the backing store 
>> resolution is not CSS pixel resolution, for compatibility with existing 
>> content). The enhancements include a backingStorePixelRatio attribute and 
>> {get,put}ImageDataHD functions on CanvasRenderingContext2D.
>> 
>> Through  and 
>> , I am making these 
>> enhancements, with the names prefixed with “webkit”.
>> 
>> There is no build-time option to disable these enhancements. Ports that 
>> don’t opt into ENABLE_HIGH_DPI_CANVAS get a working, albeit boring, version 
>> of the additional API. Ports that opt into high-DPI canvas need to enhance 
>> their ImageBuffer implementation to fully support the resolutionScale and 
>> CoordinateSystem parameters.
>> ___
>> 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] feature proposal: restricting window.blur/focus

[Oliver Hunt]

I am all for this change, but a not insubstantial part of that is my general 
hate for anything other than me ever changing the focused window and/or element.

--Oliver

On Apr 4, 2012, at 1:31 AM, Jochen Eisinger wrote:

> Hey,
> 
> Firefox restricts the use of window.blur() and window.focus() (by default). 
> window.blur() is just doing nothing, and window.focus() only works if the 
> caller is running in the same window.
> 
> Should we implement similar rules for WebKit? The purpose of this is to make 
> pop-unders more difficult to achieve.
> 
> I think this can be implemented in such a way the the chrome implementation 
> which is doing the actual focusing/bluring anyway has enough information to 
> let each port control what they want to do.
> 
> wdyt?
> 
> -jochen
> ___
> 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 Encrypted Media Extensions

[Oliver Hunt]

Last I saw, there hadn't been any attempt to actually define how the content is 
encrypted.  Has that changed?  If it hasn't how do we get interoperable 
implementations?  The only way for this spec to not break the openness of 
 and  is for the encryption algorithm to be completely defined in 
the spec.

--Oliver

On Apr 4, 2012, at 9:55 AM, David Dorwin wrote:

> Hi WebKit!
> 
> I plan to add the Encrypted Media Extensions to the media elements. The 
> extensions allow web applications using  and  to control key 
> exchange. The extensions will be behind the ENCRYPTED_MEDIA feature define. 
> The feature is tracked as https://bugs.webkit.org/show_bug.cgi?id=82968.
> 
> Implementation will be based on the draft proposal at 
> http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html,
>  which was published jointly by Google, Microsoft, and Netflix [1]. It 
> appears a Media Task Force will be taking this on to produce a Working Draft 
> [2]. Having an implementation will allow us to include implementation 
> experience in the development of the draft.
> 
> As described in the proposal, several new methods and events are added to 
> HTMLMediaElement and a new keySystem parameter and attribute are added to 
> canPlayType() and HTMLSourceElement, respectively. As with much of the media 
> stack, most of the functionality will be implemented within the various 
> ports. ENCRYPTED_MEDIA will be enabled for the Chromium port and covered by 
> its buildbot.
> 
> Regards,
> David
> 
> [1] http://lists.w3.org/Archives/Public/public-html/2012Feb/0273.html
> [2] http://lists.w3.org/Archives/Public/public-html/2012Apr/0007.html
> ___
> 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] UPDATED Re: Version control survey

[Oliver Hunt]

I do think that we should also be considering what the responders are doing -- 
eg. do you work mostly on the core engine (WebCore, JSC, etc) vs. platform 
specific engine work (eg. 
WebCore/platform/graphics/{cg,cairo,skia,backendofdoom}) vs. WebKit API stuff 
vs. release branching, etc

I think it would be worth tracking these differences for a number of reasons
* There are a number of reviewers who don't do substantial amounts of work 
directly in the repo anymore, longterm apple and google contributors who no 
longer work exclusively on webkit (on that note do we want to have some kind of 
reviewer expiration?)
* Fairly elitist, but surely the opinion of people who work on core engine tech 
should have more say than people working on the periphery: core engine work 
benefits _everyone_ so I feel more weight should be given there
* The needs of a contributor are fairly strongly influenced by what they're 
doing -- people working on build release branches, etc frequently want to do 
the sorts of things that git is far better at than svn, but people just working 
on single monolithic patches seem to prefer  svn.
* A problem we these kinds of survey is that they are inherently biased in 
favour of people who want change, people who don't tend to ignore them - I had 
basically been ignoring this thread because it was going on and on and on 
without actually adding any new information over the last git vs. svn debate, 
had done nothing to change my mind, etc - i feel that I am not alone in this 
kind of mental exhaustion (see 
http://webkitmemes.tumblr.com/post/19019677135/webkit-dev-this-week)

Finally: I use git-svn, it allows me to do everything that I want to do that 
git is meant to be good at, so I'm not sure why people keep saying that the 
choice is between sticking with svn, or making  everyone switch to git.  My 
counter argument to "git-svn is slow so we should all use git" is "git-svn is 
slow and this annoys me so i'm going to contribute patches to git to fix that".

--Oliver

On Mar 10, 2012, at 1:00 PM, Maciej Stachowiak wrote:

> 
> I will also post the results split out by contribution level once the survey 
> closes.
> 
> Regards,
> Maciej
> 
> On Mar 10, 2012, at 12:58 PM, Jon Lee wrote:
> 
>> Direct link to results: 
>> http://kwiksurveys.com/results-overview.php?surveyID=LODHNK_f6f04dad&mode=4
>> 
>> On Mar 10, 2012, at 12:49 PM, Maciej Stachowiak wrote:
>> 
>>> 
>>> Hi folks,
>>> 
>>> I made a bad choice of survey site. They want to charge me to see more than 
>>> 100 responses or to export the data, but they won't take my money. Sadness. 
>>> Please try this survey instead, it will run through the 17th.
>>> 
>>> http://kwiksurveys.com?s=LODHNK_f6f04dad
>>> 
>>> Regards,
>>> Maciej
>>> 
>>> On Mar 10, 2012, at 11:52 AM, Maciej Stachowiak wrote:
>>> 
 
 On Mar 10, 2012, at 10:56 AM, Ryosuke Niwa wrote:
 
> On Sat, Mar 10, 2012 at 10:05 AM, Maciej Stachowiak  
> wrote:
> 
> Unfortunately SurveyMonkey sucks and I can't give everyone access to live 
> responses without paying them money. Current results:
> 
> - 97 people have answered
> - About 67% use Git only (this has been consistent throughout the survey)
> - Aabout 20% use Subversion only
> - About 13% use Git and Subversion
> - No one checked "Other"
> 
> As far as contribution levels of the responders:
> 
> - 37% are WebKit reviewers
> - 25% are WebKit committers
> - 25% are WebKit contributors (but presumably not committers or reviewers 
> yet)
> - 13% are not WebKit contributors
> 
> Can we see the breakdown of git/svn users among reviewers & committers?
> 
> I'm not certain if it's really useful to consider votes casted by 
> non-contributors here since we're presumably not trying to decide which 
> version control system is more popular in general public.
 
 I would indeed like to get the contributor-only (and 
 reviewer/committer-only) statistics, but I'm having trouble upgrading to 
 the "pro" account that would enable this. I'll post the data once I have 
 it.
 
 I do think it is somewhat interesting to find out what non-contributors 
 who nontheless check out source are using to access the WebKit repository. 
 The fact that so many people use Git says to me that our basic checkout 
 instructions should include the relevant git instructions as an 
 alternative. SVN instructions are on the main site at 
  but Git instructions are 
 buried in the wiki.
 
 Regards,
 Maciej
 
 ___
 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.c

Re: [webkit-dev] (no subject)

[Oliver Hunt]

On Feb 27, 2012, at 5:56 PM, Dirk Pranke wrote:

> Hi all,
> 
> If you don't use webkit-patch and Git, you can stop reading now. Otherwise ...
> 
> Currently, webkit-patch -g has some special logic for figuring out
> what to diff against for Git checkouts.
> 
> Specifically, webkit-patch "-g commitish" gets translated to the git
> equivalent of 'git diff commitish^..commitish'. Then, we have an
> additional tweak that rewrites '-g HEAD' to '-g HEAD..' in order to
> pick up any uncommitted changes, and if nothing is specified, we will
> attempt to diff against the remote master/trunk version.
> 
> This is very useful if you typically want to just upload a single
> commit issue, but is a bit un-git-like, and actually thwarts some
> other use cases.
> 
> My questions are:
> 
> 1) Do you use "-g foo" to upload a single change? If so, would you be
> annoyed if I changed that syntax to a different argument, or
> eliminated it completely (so that you would have to type foo^..foo)?
> 
> 2) Do you object to changing the default to match what 'git diff'
> does? This would change the defaults so that:
>  a) instead of no arguments meaning "diff against remote master", it
> would mean "diff against what is staged for commit"

This would annoy me quite a lot -- Any delta including new files or anything 
implicitly staged (eg. by git stash apply) would not be included.

Or do you mean git diff HEAD ?

--Oliver

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

Re: [webkit-dev] JavaScriptCore Debugger - Non-Browser Implementation

[Oliver Hunt]

We actually want to kill the current debugging mechanisms as they're somewhat 
archaic in their current form (they require substantial [and fragile] work on 
the debugger side, and have a significant runtime cost).  I'd be hesistant to 
start building anything new on top of what's currently there, but we do want to 
improve the dev support in JSC itself so we wouldn't say no to any patches in 
that direction.

--Oliver

On Feb 13, 2012, at 11:39 AM, Maciej Stachowiak wrote:

> 
> On Feb 7, 2012, at 10:18 PM, Matt Veenstra wrote:
> 
>> Hello,
>> 
>> I am looking for a tool to help debug JavaScript code for
>> JavaScriptCore when NOT using a browser?  I did a bit of research and
>> did not find anything that seems to attach and debug at a code level
>> and ignore the DOM.
>> 
>> Is there something simple I missed?  Drosera seemed to exist in the past.
>> 
>> Is this the proper list for this question?
> 
> I don't believe there is a pre-made tool for debugging JavaScript code in JSC 
> outside of WebKit. The APIs exist, so it should be possible to make one, but 
> no one has done so at this time, so far as I know.
> 
> Regards,
> Maciej
> 
> ___
> 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] JavaScriptCore question

[Oliver Hunt]

On Dec 16, 2011, at 9:05 AM, Rolando Abarca wrote:

> Hi all,
> 
> I'm using JavaScriptCore for scripting purposes (isolated from webkit), and 
> I'm encountering the following problem:
> 
> I would like to store a reference to an anonymous function, and later to be 
> able to call it as a callback, something like this:
> 
> ---javascript
> node.schedule("some name", function () { ... });
> ---
> 
> What I'm doing right now is in the definition of node.schedule, I store the 
> context and the function (as a JSValueRef), then when I need to call code in 
> there, I'm doing this:
> 
> JSObjectRef func = JSValueToObject(storedContext, storedCallback, NULL);
> JSObjectCallAsFunction(cb->context, func, storedObject, 0, NULL, NULL)
> 
> It doesn't matter how I store the context/function, it always crashes when 
> trying to either convert the value to object or call the object as function. 
> At first I thought that the function was being garbage collected, but even 
> after protecting it, I still got the crash.
> 
> My guess is that the context is not the right one, so another question is: 
> what context should I be passing here?


This looks like you're storing the JSContextRef you receive when your callback 
is called.  That's incorrect as a given JSContextRef is only guaranteed to be 
valid within the callback.  All your functions should be from the same initial 
JSGlobalContextRef you created when initialising your environment, and you 
should just be using that GlobalContext rather than any per instance context.

You should also be protecting the function with JSValueProtect.

Hopefully this helps.

> 
> What would be the right way to do this?
> Thanks,
> -- 
> Rolando Abarca M.
> http://rolando.cl
> Phones: +1 (415) 655-1041
> +56 (2) 581-4591
> 
> ___
> 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] Timing attacks on CSS Shaders (was Re: Security problems with CSS shaders)

[Oliver Hunt]

On Dec 8, 2011, at 1:25 PM, Rik Cabanier wrote:

> This might no longer be true, but isn't it the case that shaders are designed 
> to take the same amount of time to execute, no matter what input they get?
> ie if you have an if/else block, the time of the shader would be whatever 
> block takes the longest. This was done so you can schedule many of them at 
> the same time without having to worry about synchronizing them.
> 
> Rik

That was only true in the early days of GLSL, etc when the hardware did not 
actually support branching.  Now the hardware does support branching so these 
timing attacks are relatively trivial (see 
http://www.contextis.co.uk/resources/blog/webgl/poc/index.html).

--Oliver

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

Re: [webkit-dev] Internal JSON Parsing

[Oliver Hunt]

It's not safe to use ScriptObject for values that are kept alive by JS objects 
as it leads to cycles in the collector.

Also the cached value for an attribute should be in the binding classes, not 
the implementation classes.  The easiest way to understand why is to ask 
yourself how a non-js (objc, gobject, etc) binding layer would use the same 
cached value.

I suspect you can probably just kill off the no custom getter+CachedAttribute 
check in the code generator as I think i was simply being conservative when i 
wrote that code.

--Oliver

On Dec 8, 2011, at 8:39 AM, Jarred Nicholls wrote:

> Hey webkittens,
> 
> I'm working on https://bugs.webkit.org/show_bug.cgi?id=73648 to support the 
> json response entity from XHR.response.  Unless I'm mistaken (the purpose of 
> this inquiry) we don't appear to have a VM-agnostic interface for internal 
> JSON parsing, i.e., straight to the parsers.  If so, what does everyone think 
> about adding in that basic interface?  What I'd like to avoid is preprocessor 
> branches directly in XHR talking to JSC and V8 directly; instead, what would 
> be ideal I think is an interface to parse and return a ScriptObject.
> 
> Any additional input is surely welcomed.
> 
> Thanks,
> Jarred
> ___
> 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] WebKit branch to support multiple VMs (e.g., Dart)

[Oliver Hunt]

On Dec 6, 2011, at 11:53 PM, Oliver Hunt wrote:

> 
> On Dec 6, 2011, at 11:49 PM, Dominic Cooney wrote:
>> 
>> Those bindings are different because the code that uses them is not 
>> activated from web pages. Looking at the specific posted patches, those 
>> changes seem necessary to support activating a different language from a 
>> page eg 

Re: [webkit-dev] WebKit branch to support multiple VMs (e.g., Dart)

[Oliver Hunt]

On Dec 6, 2011, at 11:49 PM, Dominic Cooney wrote:

> 
> 
> On Wed, Dec 7, 2011 at 1:44 AM, Oliver Hunt  wrote:
> 
> On Dec 6, 2011, at 2:55 AM, Anton Muhin wrote:
> 
> > Good day, everyone!
> >
> > I am sorry if it didn't sound clear enough in our original message,
> > but we're not proposing a new language support, but we're proposing a
> > patch which allows others runtimes to run along with JS in the
> > browser.
> >
> > Of course, we're doing this because of our work on Dart, but our
> > intent was to solicit a feedback from the WebKit community if there is
> > any interest in supporting runtimes additional to JS (and not JS +
> > Dart) in the first place.
> As I have already said, we already support multiple bindings being in use at 
> the same time.
> 
> Those bindings are different because the code that uses them is not activated 
> from web pages. Looking at the specific posted patches, those changes seem 
> necessary to support activating a different language from a page eg 

Re: [webkit-dev] WebKit branch to support multiple VMs (e.g., Dart)

[Oliver Hunt]

On Dec 6, 2011, at 2:55 AM, Anton Muhin wrote:

> Good day, everyone!
> 
> I am sorry if it didn't sound clear enough in our original message,
> but we're not proposing a new language support, but we're proposing a
> patch which allows others runtimes to run along with JS in the
> browser.
> 
> Of course, we're doing this because of our work on Dart, but our
> intent was to solicit a feedback from the WebKit community if there is
> any interest in supporting runtimes additional to JS (and not JS +
> Dart) in the first place.
As I have already said, we already support multiple bindings being in use at 
the same time.  Continuing to claim that is your goal is not helpful.  Your 
goal is to allow additional non-standard languages to be provided by 
webcontent.  This is an academic exercise as it doesn't match webkit's goal of 
being a standards compliant engine, and also has dubious advantage even when 
supported -- as Vijay said multiple languages already compile to EcmaScript, 
there is no reason that Dart can't as well.

So even if it turns out that this can be implemented without regressing 
performance of those parts of webkit responsible for supporting open standards, 
it has a maintenance burden required to support a "feature" that has no 
business being in webkit.

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

Re: [webkit-dev] WebKit branch to support multiple VMs (e.g., Dart)

[Oliver Hunt]

No.  People are using EcmaScript on the web.

They have languages that compile to EcmaScript as an intermediate language.  
Dart could also do this (emscripten demonstrates that raw C can be compiled to 
EcmaScript), so if people wished they could do that.  These are also not a 
significant proportion of websites at all.  If we were to decide to support one 
of these natively it would make sense to support the most popular and widely 
used languages, but currently none of the languages that compile to ES have 
made any significant headway -- mostly because ES is actually a pretty good 
language (yes it has rough edges, but the same is true of _all_ languages).

Adding direct and exposed support for a non-standard language is hostile to the 
open-web by skipping any form "consensus" driven language development that 
might happen (say the path taken by json2.js -> the native JSON object), and 
foisting whatever language we want on the web instead.
This implicitly puts any browser that supports additional proprietary 
extensions in the same position as a browser supporting something like 
vbscript, and has the same effect: breaking the open web by making content that 
only works effectively in a single product.

For example back in the 90s Netscape had a feature called "layers" any browser 
could display the pages, but they would only look "good" in netscape.  If we 
were to natively support some other language on the web say 
OliversAwesomeWebLanguage, and provided a tool to compile OAWL to ES any site 
that used OAWL would perform significantly worse on other browsers than on our 
own (this is a given as the only argument in favour of native support vs. 
compilation to JS is that native support is meant faster than going through JS).

If OAWL did become a big enough platform then other vendors _might_ end up 
reversing engineering it and reimplementing it themselves, put us back in the 
position of the 90s browsers and the many variants of what is now called 
EcmaScript.

On Dec 5, 2011, at 10:43 PM, Vijay Menon wrote:

> On Mon, Dec 5, 2011 at 7:28 PM, Oliver Hunt  wrote:
>> 
>> The issue here isn't "can we make multiple vms live in webkit" it's "can we
>> expose multiple languages to the web", to the former i say obviously as we
>> already do, to the latter I say that we don't want to.
> 
> People are already using multiple languages on the web.  E.g.,
> https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS.
> Native runtime support is a natural next step.
> 
> WebKit does support multiple VMs, but it does not support them
> concurrently at runtime.  That is essentially what we want to enable.

WebKit does support multiple bindings concurrently at runtime -- a lot of mac 
clients make use of the obj-c dom bindings while JS is executing, some also 
make use of the JS<->ObjC bridge so that you have two different sets of 
bindings for the same objects at the same time, being used together in 
beautiful harmony ;)

> 
> Cheers,
> 
> Vijay

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

Re: [webkit-dev] WebKit branch to support multiple VMs (e.g., Dart)

[Oliver Hunt]

I think there needs to be a compelling reason for a branch to exist (see the 
'not an academic exercise'(or whatever) rule).
Let's say we have a feature X, where X would be a sufficiently complex feature 
to make working in trunk risky, and maybe even not possible (for example you 
could try to allow developers to provide paint routines of an element in JS 
*shudder*).

Because we believe the feature might actually be valuable, In that case the 
branch exists to allow the implementer to bring up the feature and verify that 
it's possible, and no one else will have to work around them.  At the end of 
branch dev. it's possible to look at the branch and decide if the feature is 
worth the cost the implementation has demonstrated and merge, to reimplement in 
trunk using the knowledge gained in branch dev, or to throw out the feature.

In this case the feature is exposing additional programming languages to the 
web, something without any real benefit to anyone other than fans of the 
current "most awesome" language (not too long ago that might have been Go, a 
year or so ago this would have been ruby, before than python, i recall i brief 
surge in haskell popularity not that long ago as well, Lua has been on the 
verges for a long time, in this case it's Dart -- who's to say there won't be a 
completely different language in vogue in 6 months?), but as a cost it 
fragments the web and adds a substantial additional maintenance burden -- just 
maintaining the v8 and jsc bindings isn't trivial and they're for the same 
language.

The issue here isn't "can we make multiple vms live in webkit" it's "can we 
expose multiple languages to the web", to the former i say obviously as we 
already do, to the latter I say that we don't want to.

Unless we want to turn webkit into the engine that everyone hates because of 
all its unique "features" that break the open web, a la certain browsers in the 
late 90s.

--Oliver

On Dec 5, 2011, at 7:11 PM, Ryosuke Niwa wrote:

> On Mon, Dec 5, 2011 at 7:01 PM, Oliver Hunt  wrote:
> As the 90s demonstrated such "features" are bad for developers, and bad for 
> the open web.  This may not be apparent to people who have not spent years 
> working in the environment but random additions frequently cause significant 
> pain down the road, even in the cases where the overall result was a "good" 
> thing -- such as canvas - for the subsequent standardisation caused us quite 
> a bit of compatibility problems, even though it was a very compact and 
> contained api.
> 
> I can't agree more.
> 
> On the other hand, I feel bad to push back people from doing new experiments 
> especially on branches. Do you have an alternative suggestion for Vijay and 
> others to do (potentially) controversial experiments?
> 
> - Ryosuke

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

Re: [webkit-dev] WebKit branch to support multiple VMs (e.g., Dart)

[Oliver Hunt]

Previous branches have been used to bring up interestingly complicated 
features, or features that had the potential to cause dramatic stability issues 
during their early work (such as the old svg-experimental branch).  This 
project appear to be largely a make work project as it's already possible to 
have bindings for multiple languages (as the C++, GLib, ObjC, V8 and JSC 
bindings demonstrate).

It seems an academic exercise to see if we can create a general architecture to 
make more bindings, as is exporting support for proprietary extensions like 
vbscript, python or dart to the web.  As the 90s demonstrated such "features" 
are bad for developers, and bad for the open web.  This may not be apparent to 
people who have not spent years working in the environment but random additions 
frequently cause significant pain down the road, even in the cases where the 
overall result was a "good" thing -- such as canvas - for the subsequent 
standardisation caused us quite a bit of compatibility problems, even though it 
was a very compact and contained api.

--Oliver

On Dec 5, 2011, at 6:09 PM, Ryosuke Niwa wrote:

> I agree with Peter here. It appears to me that having a WebKit branch to 
> experiment a new feature will help us making an informed decision as to 
> whether we want to accept patches or not for the feature better than looking 
> at two giant patches posted on chromium.org.
> 
> Preferably, Vijay also file a bug and possibly post a patch on 
> bugs.webkit.org.
> 
> - Ryosuke
> 
> On Mon, Dec 5, 2011 at 5:39 PM, Peter Kasting  wrote:
> On Mon, Dec 5, 2011 at 5:22 PM, Geoffrey Garen  wrote:
> > We're creating a branch in order to demonstrate that it's useful and that 
> > it does not negatively impact hackability or performance.
> 
> It hadn't occurred to me to view the goals of the WebKit project as applying 
> only to trunk, and not to branches. I'd be interested in hearing from other 
> WebKit engineers: Do you think that the goals of the WebKit project apply to 
> trunk alone, or to branches as well?
> 
> It sounds from the quote above like Vijay is not trying to change what the 
> goals are, only to obtain an environment where it's possible to demonstrate, 
> by practical experience, that some set of changes is indeed consistent with 
> WebKit's goals.   In principle a branch seems appropriate for that to me 
> unless there is widespread agreement that the entire idea of these patches is 
> so contrary to what we want that no one should have ever even thought about 
> doing them in the first place.  I'm not sure things are that clear-cut, so 
> seeing a more fleshed-out system might be useful.
> 
> PK
> 
> ___
> 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] WebKit branch to support multiple VMs (e.g., Dart)

[Oliver Hunt]

What is the benefit to the project in exposing an additional (non standardized) 
language to the web?  All the bindings that webkit currently provides to are 
either standardized EcmaScript or platform specific bindings used by native 
code developers embedding webkit.

Adding an additional web facing language (that isn't standardized) doesn't seem 
beneficial to the project, if anything it seems harmful (cf. VBScript in IE).

Anyway if we were to add an additional language the language people have been 
asking for for years is Python which is already extremely popular and well 
known so it seems that it would be a much better choice to expose, but even 
then it seems like a bad idea.

--Oliver

On Dec 5, 2011, at 1:22 PM, Vijay Menon wrote:

> Hi Per,
> 
> At a high-level, the idea is pretty simple.  We want to be able to run 
> another VM along a JS one.  For example, if we see a Dart script on a web 
> page, we want the Dart VM to be able to handle it.  If we see a JS script, we 
> want the JS one to handle it.  Similarly, if an event listener on a page is 
> triggered, we want to forward to the appropriate VM to run the user listener 
> code.
> 
> The changes here are mostly about refactoring some classes (e.g., 
> ScriptController, ScheduledAction) to add that extra dispatch.
> 
> I'm not familiar enough with the JavaFX model, but this may be useful if you 
> want to provide direct access from Java to the DOM via Java bindings.  Do you 
> have a pointer on how you're handling multiple VMs in WebKit today?
> 
> Cheers,
> 
> Vijay
> 
> 
> On Mon, Dec 5, 2011 at 12:50 PM, Per Bothner  wrote:
> On 12/05/2011 09:26 AM, Vijay Menon wrote:
> We’re planning to create a multi-vm branch on webkit.org
>  to experiment with this idea.  Our goal with this
> 
> branch is to (a) demonstrate the above points and (b) show that we can
> do this without degrading JavaScript performance or the WebKit
> development experience.  If successful, we’d like to submit these
> changes to WebKit trunk.  We welcome your feedback.
> 
> What is there to provide feedback on?  Asking people to provide feedback
> on a huge patch dump seems unreasonable.
> 
> Why did you choose the approach you did?
> Is there a planning document or white-paper?
> What changes did you make at a *high* level - not a set of patches?
> Did you run into problems or have to decide between alternative solutions?
> 
> This may be interesting to the webnode portion of Oracle's JavaFX. We
> already have to deal with multiple VMs: The JSC JavaScript VM and the Java VM.
> Having a standard and more efficient way of combining them might be helpful.
> Likewise more direct access from Java to the WebKit core might be helpful,
> though the standard DOM bindings don't require JavaScript.
> 
> I don't know if a WebKit port using Nashorn (Oracle's next-generation 
> JavaScript
> implementation on the JVM) will be helped by a multi-VM WebKit, or make it
> irrelevant (from Oracle's point of view, of course).
> -- 
>--Per Bothner
> per.both...@oracle.com   p...@bothner.com   http://per.bothner.com/
> 
> ___
> 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] What is the reason for changing JavaScript parser from bison parser(LR) to Top-To-Down Recursion parser?

[Oliver Hunt]

The handwritten parser has numerous benefits over the old bison generated one, 
the most basic being:
 * It's more than 2 times faster than the bison parser
 * It doesn't require complete duplication of the grammar to support strict 
mode (and can identify strict mode in the first place)
 * It fixes a number of bugs inherent in the bison parser due to the way 
automatic semicolon insertion was implemented.

There are a number of other benefits, but those are the most obvious.

--Oliver

On Nov 29, 2011, at 11:38 PM, PandaCanFly wrote:

> Hello everyone,
> I am researching WEBKIT and coming up against difficulty about Javascript 
> parser。As I Know, WEBKIT of old version uses the bison parser to interpret 
> javascript code. But WEBKIT of recently version doesn't uses bison parser. 
> Instead, WEBKIT of recently version uses Top-To-Down Recursion parser.
> I have some details to add. 1) WEBKIT using bison parser has a source 
> file named "Grammar.cpp". 2) I know WEBKIT with 38688 version number uses 
> bison parser.
> I hope someone can give me some explanation, thanks.
> 
> 
> 
> ___
> 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] starting implementation of postMessage tranferables

[Oliver Hunt]

On Sep 22, 2011, at 7:46 PM, Ian Hickson wrote:

> On Thu, 22 Sep 2011, David Levin wrote:
>> 
>> *Summary*: Implementing postMessage with transferable support as
>> webkitPostMessage.
>> 
>> *Details*:
>> *Spec*:
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#posting-messages
>> 
>> This describes window.postMessage and the same is true for Message Ports and
>> Worker Context. It doesn't mention Array Buffers but that will be mentioned
>> soon and is in the spec that talks about Array Buffers.
>> 
>> Tracking bug: https://bugs.webkit.org/show_bug.cgi?id=64629
>> 
>> *Plan*:
>> 1. Add webkitPostMessage to all of these places to isolate us from possible
>> spec changes. It will have the same functionality as postMessage.
>> 2. Add the ability to transfer Message Ports.
>> 3. Add the ability to transfer Array Buffers.
> 
> After step 2, webkitPostMessage can be renamed to postMessage quite 
> safely. The spec isn't going to change in a way that breaks you.

I think we should wait and see -- spec changes have caused issues for us in the 
past (eg. localStorage :-/ )

There is not any substantive harm in prefixing, whereas there can be real 
problems down the road if we don't prefix.

--Oliver

> 
> -- 
> Ian Hickson   U+1047E)\._.,--,'``.fL
> http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
> ___
> 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] run-bindings-tests

[Oliver Hunt]

On Sep 8, 2011, at 7:21 PM, Alexey Proskuryakov wrote:

> 
> 08.09.2011, в 12:25, Darin Adler написал(а):
> 
>> I find the bindings tests quite helpful. Because the perl script is so hard 
>> to read, it’s the changes in bindings script test results that I look at 
>> when reviewing changes to the bindings scripts. The fact that the results 
>> are checked in helps me review patches.
> 
> OK, then they are valuable indeed.
> 
> However, I still feel that there is a disconnect between the desired effect 
> (provide a diff in a patch for review) and the implementation (tests that can 
> pass or fail). This also puts the burden of maintaining the results on people 
> who needn't care about them - for example, Oliver's patch clearly didn't need 
> someone look over generated code changes.

I think the argument is that it _did_ need someone -> the reviewer didn't have 
any "nice" way to see the difference in output that would have been visible had 
i included updates to the expected output.

My problem with the test is that it isn't run as part of run-webkit-tests 
(which is what we say you must run), the test output is fairly awful, and the 
test script doesn't support --help, or --reset (it turns out it does have an 
equivalent to --reset, but why use a different argument in one tool from what 
we use in the main one?)

--Oliver

> 
> I'm not sure what the better solution would be though. Perhaps a bot could 
> provide a diff of DerivedSources for any patch that touches code generators, 
> but I'm not volunteering to implement one :-)
> 
> - WBR, Alexey Proskuryakov
> 
> ___
> 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] run-bindings-tests

[Oliver Hunt]

On Sep 8, 2011, at 11:55 AM, James Robinson wrote:
> 
> We used to not run these tests on the bots.  This meant that people would 
> change the bindings code and not update the expected results, so the expected 
> results were always massively out of date.  This meant when patching the 
> bindings scripts you could not rely on run-bindings-tests at all, because the 
> expectations were already broken before you made any changes!  This it not 
> theoretical, it happened to be multiple times and I know I'm not the only one.
> 
> The real problem here is that people check in without looking at the bots and 
> then do not respond when the bots go red.  That's a people problem.

The real problem is that we have a test suite: run-webkit-tests, that everyone 
runs (it's even mentioned at step 4 on 
http://www.webkit.org/coding/contributing.html , which is apparently not 
running all the tests.

I run-webkit-tests before i commit (new-run-webkit-tests has ensured that any 
prior complains about time taken no longer exist, so kudos to those folk \o/ ), 
and yet I end up breaking the build in a way that would show up locally if the 
tests were simply run.  run-webkit-tests should run all of the webkit tests -- 
not some subset, all of them.  If failing a cross platform test can turn the 
bots red, then that test should be covered by run-webkit-tests.

The other problem is "people check in without looking at the bots".  I do try 
to watch the bots, but the time between me landing and the bots actually going 
red can literally be hours.  Of course i'm away from irc/email whatever when I 
land a patch at 4pm and it turns the bots red at 11pm.

I appreciate this isn't as much of a problem for people who don't work on code 
for which all changes heralds a world rebuild and effect (apparently) every 
single test that exists in the repository, but it's certainly frustrating for 
those of us who do.

(This is ignoring the overly aggressive rollouts of large patches the break 
only single platforms due to platform specific code that is difficult for 
anyone outside of that platform to fix)

--Oliver

> - James
> 
> 
> 
> - WBR, Alexey Proskuryakov
> 
> ___
> 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] WebCL Release

[Oliver Hunt]

On Aug 24, 2011, at 3:20 PM, Tasneem Brutch - Samsung wrote:

> Khronos WebCL is not yet a specification, and the WebCL API has not yet been 
> standardized.  The WebCL members are currently discussing the security and 
> interoperability issues in the WebCL Working Group.  Samsung would like to 
> introduce a WebCL patch at this time, to follow the ongoing specification 
> activity in the Khronos WebCL working group.
>  
> WebCL would not be enabled in the browser by default, and users will have the 
> choice to enable it in the browser.

That's not really a great consolation -- defining a spec where there's is the 
assumption it will be disabled by default doesn't seem like a good plan in the 
long term.  In all honesty "disabled by default" is only a bit better than 
"asking the user's permission" in terms of security.

> The WebGL security concerns previously raised, related to the following 
> aspects:
>  
> 1) Cross domain image access  - timed loop attack.
> 2) Issues related to general hardening.
>  
> In response to item 1), WebGL and HTML specs have been updated, mandating 
> CORS (Cross Origin Resource Sharing) for video, images and audio, and servers 
> have to grant cross domain access to media resources.
> Item 2) was addressed by the WebGL working group, through ARB_ROBUSTNESS 
> extensions, which provide additional protection being mandated.  The new 
> robustness specification limits the side-effects of a GPU reset after a 
> Denial of Service attack.  In addition the ANGLE shader validator was 
> improved. 

The hardening policies for WebGL work because WebGL is built on a heavily 
restricted version of GLSL.  My understanding was that OpenCL had access to 
pointers and arrays provided by the host application, but did not guarantee 
memory safety.  Given all kernels provided to WebCL are untrusted code that is 
clearly unsafe, to what extent does the WebCL spec (or draft spec as the case 
may be) limit illegal memory operations?

ARB_ROBUSTNESS is specifically a GPU flag (mostly needed due to the absence of 
any memory protection on GPU), but one of the goals of OpenCL was to provide a 
uniform interface to CPU and GPU compute resources so is not particularly 
relevant to the discussion of WebCL security.

Now I will say I have no real development experience with OpenCL (essentially I 
have read the documentation and looked at the pretty demos), but it is my 
understanding that I can provide OpenCL with a specific piece of memory, in 
WebCL I assume an ArrayBuffer or similar,  and then the kernel can compute an 
arbitrary index into that storage -- is that understanding correct?  If so how 
does WebCL ensure that this behaviour is safe?

> In the short term, browser vendors would maintain white and black lists, so 
> that the compromised system can have WebGL disabled until mitigation is 
> developed.  In the longer term, GPUs would provide increasingly robust 
> security and tasking, to allow GPU to become a first-class computing platform 
> alongside CPU.
As I said above WebGL already introduces a large number of restrictions on the 
possible operations performed by a shader _without_ any support from the 
ARB_ROBUSTNESS.  OpenCL however explicitly allows a lot of the memory access 
that WebGL deliberately prevents.

> As the WebCL standardization effort progresses, the WebCL API would be 
> defined with security as the highest priority, with provisions for both short 
> term, and longer term security and robustness solutions, similar to the 
> approach taken by the WebGL working group.

WebGL deliberately removed a number of features, and introduced a range of type 
safety requirements not originally present in GLES, does the WebCL WG have a 
table of attack surfaces and hardening solutions that have been taken?

--Oliver

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

Re: [webkit-dev] WebCL Release

[Oliver Hunt]

How has the WebCL spec dealt with the inherent security problems of OpenCL in 
the face of untrusted content?  In the WebGL working group we spent a lot of 
time working on how to adequately restrict GLSL|ES to prevent security 
vulnerabilities, and I haven't really heard anything about what approach the 
WebCL WG has been taking.  My concern is that OpenCL is far less restrictive 
than GLSL, and yet we had to clamp down on what was possible even then.

--Oliver


On Jul 5, 2011, at 10:41 AM, Won Jeon wrote:

> Dear Simon,
> 
> Thanks for your interest in our WebCL prototype in WebKit. 
> 
> Currently, it's integrated with WebKit r78407 and hasn't been checked with
> WebKit's coding style guidelines. It's tested on Mac with Nvidia GPU which
> supports OpenCL support. Updating the code to a newer WebKit and Porting the
> code to other platforms should be straightforward because the only
> platform-dependent part is OpenCL support.
> 
> WebGL is not needed for WebCL itself, but it would be better for
> interoperability between WebCL and WebGL, so that's why we started this work
> on Mac first.
> 
> 
> Regards,
> Won
> 
> -Original Message-
> From: Simon Fraser [mailto:simon.fra...@apple.com] 
> Sent: Tuesday, July 05, 2011 8:12 AM
> To: Gyuyoung Kim
> Cc: webkit-dev@lists.webkit.org; Simon Gibbs; Won Jeon - SISA;
> jinwoo7.s...@samsung.com
> Subject: Re: [webkit-dev] WebCL Release
> 
> On Jul 3, 2011, at 6:28 PM, Gyuyoung Kim wrote:
> 
>> Hello WebKit Developers,
>> 
>> Samsung has just open sourced an implementation of "WebCL" for WebKit. 
>> This is a prototype of a proposed WebCL standard that aims to define
>> JavaScript APIs for OpenCL.
>> The code is located at http://code.google.com/p/webcl/ and some demo
> videos
>> at http://www.youtube.com/user/SamsungSISA.
>> We're interested in any feedback on the prototype and how it can be better
>> integrated with WebKit.
> 
> Perhaps you can summarize here how it works now, and what directions you see
> for closer integration
> with WebKit?
> 
> Simon
> 
> 
> ___
> 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] Writing a new XML parser with no external libraries

[Oliver Hunt]

I think considerable effort should be put into building up a suite of 
performance tests in advance of the new parser (probably culled from xml 
encountered in the wild, but also a number of extreme edge cases wouldn't go a 
miss either).

We should also put effort into reducing any/all recursion in the parser as 
stack depth guards are not the most efficient mechanism to prevent stack 
overflows.

--Oliver


On Jun 28, 2011, at 6:12 PM, Jeffrey Pfau wrote:

> Currently, WebCore uses libxml2, or, if available, QtXml to parse incoming 
> XML. However, QtXml isn't always available, and using libxml2 exposes its own 
> share of problems. As such, I'm undertaking writing an XML parser that uses 
> no external libraries.
> 
> The first step to doing this is to add a new flag that switches off the other 
> two parsers. As the parsers are already independent and can be switched 
> between by checking USE(QXMLSTREAM), I am adding USE(LIBXML2) checks, 
> replacing the #else conditionals, and also a new ENABLE check, tentatively 
> called NEW_XML (although names such as NATIVE_XML or XML_NATIVE, etc, may be 
> more appropriate).
> 
> As there will probably be a new slew of files pertaining to XML parsing, I 
> will put these files in WebCore/xml/parser, and move the existing 
> XMLDocumentParser* file into this new directory. As far as I know, the 
> placement of these files in WebCore/dom/ is legacy, and, assuming the build 
> on each platform is changed, it makes sense to move them.
> 
> Once all the files are in a logical place, I plan to make a new file for a 
> skeleton of the new XMLDocumentParser, at least to get it to link until a 
> real one is in place, even if the XML parser at that point is just a data 
> sink.
> 
> From there, I plan to copy and modify a good chunk of the lower level HTML 
> tokenization and parsing code, and make changes as necessary to make it work 
> on generalized XML, at least until I can generalize the common code in such a 
> way that the HTML and XML tokenizers can be subclasses and use common code. 
> I'd probably do the refactoring at the end.
> 
> I'm still exploring the existing parsing code, but I'd probably work my way 
> up from there. I've read a lot of the XML 1.0 spec in preparation, as well, 
> but it doesn't have much on implementation itself. If QtWebKit or parsing 
> people have any comments, concerns, or help, I'd be more than willing to 
> listen--I'm just starting here, and I'm not completely familiar with the 
> codebase.
> 
> Although no code is checked in so far, I've started on this list already and 
> have gotten as far as the new flags, a skeleton XMLDocumentParserNew.cpp, and 
> making a tokenizer that compiles and links, but is completely untested.
> 
> Jeffrey Pfau
> ___
> 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] Extra review requirement for web-facing API? (Was: Re: Spellcheck API for WebKit)

[Oliver Hunt]

On Jun 22, 2011, at 11:38 AM, Eric Seidel wrote:

> I think it's better for our reviewers to review only things they're
> comfortable with.
A good reviewer shouldn't be reviewing things they aren't comfortable with 
anyway -- the whole point of a review is to have someone who has appropriate 
domain knowledge ensure that the patch is correct.  Reviewing is about ensuring 
as much as possible the new code is correct and safe, if you aren't able to do 
that for a specific patch, you shouldn't be reviewing that patch (at least not 
for r+ purposes, anyone can r- if they see something obviously wrong).

--Oliver

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

Re: [webkit-dev] Are roll-outs getting a little out of hand?

[Oliver Hunt]

> 
> http://trac.webkit.org/changeset/89192
For reference this rollout was fine, i'd swear i ran all the layout tests and 
yet this caused failures for me when i tested locally just now.

*boggles*

--Oliver



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

Re: [webkit-dev] Are roll-outs getting a little out of hand?

[Oliver Hunt]

On Jun 18, 2011, at 12:24 PM, Darin Adler wrote:

> I noticed these three roll-outs:
> 
> http://trac.webkit.org/changeset/89190
> http://trac.webkit.org/changeset/89191


In the case of these first two patches was any attempt made to actually fix the 
qt build?  Every other build was apparently happy with the change so it seems 
like a Qt engineer (like Ossy_) could have attempted to fix the Qt build 
themselves, rather than just rolling out the patch and requiring someone else 
without familiarity with Qt to fix the Qt build through the slow and painful 
EWS process.

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

Re: [webkit-dev] Public APIs for accessing the Javascript debugger

[Oliver Hunt]

It depends on what you mean by "official"

I would probably r- any patch that attempted to create such an API, but it's 
conceivable that a sensible API could be made that masked the current craziness 
sufficiently to allow the craziness to be removed later.  But any API would 
need to be very carefully thought out, and would probably require multiple 
iterations to get to the point where we'd consider the API sufficiently good.

--Oliver

On Jun 14, 2011, at 9:12 AM, demallien wrote:

> Is that an official response?
> 
> On 14 Jun, 2011,at 06:03 PM, Oliver Hunt  wrote:
> 
>> The current debugging mechanism is not particularly pleasant to use, nor is 
>> it very future proof, it has significant performance costs, and it requires 
>> the user to have significant knowledge of the inner workings of JSC.
>> 
>> Before we started considering exposing JS debugging through API (and 
>> therefore introducing additional binary compatibility requirements) we would 
>> need to have an improved debugging mechanism that resolved these issues.
>> 
>> --Oliver
>> 
>> On Jun 14, 2011, at 7:38 AM, demallien wrote:
>> 
>> > Hi,
>> > 
>> > I'm interested in providing a public C API for accessing debugger 
>> > functionality in JavascriptCore. Ideally I would like the code to be 
>> > merged into webkit, so I wanted to know if there is a policy reason for 
>> > not already having debugger APIs available in the public JavascriptCore 
>> > APIs? If so, my work will obviously not be compatible with the policy, and 
>> > I won't bother trying to conform to webkit coding standards, as the code 
>> > will clearly not be accepted into webkit. Othwerwise I'll make an effort 
>> > to make it fit in with the rest of the system.
>> > 
>> > So, is there a reason for there not being a publically accessible debugger 
>> > API?
>> > 
>> > Alli
>> > ___
>> > 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] Public APIs for accessing the Javascript debugger

[Oliver Hunt]

The current debugging mechanism is not particularly pleasant to use, nor is it 
very future proof, it has significant performance costs, and it requires the 
user to have significant knowledge of the inner workings of JSC.

Before we started considering exposing JS debugging through API (and therefore 
introducing additional binary compatibility requirements) we would need to have 
an improved debugging mechanism that resolved these issues.

--Oliver

On Jun 14, 2011, at 7:38 AM, demallien wrote:

> Hi,
> 
> I'm interested in providing a public C API for accessing debugger 
> functionality in JavascriptCore.  Ideally I would like the code to be merged 
> into webkit, so I wanted to know if there is a policy reason for not already 
> having debugger APIs available in the public JavascriptCore APIs?  If so, my 
> work will obviously not be compatible with the policy, and I won't bother 
> trying to conform to webkit coding standards, as the code will clearly not be 
> accepted into webkit.  Othwerwise I'll make an effort to make it fit in with 
> the rest of the system.
> 
> So, is there a reason for there not being a publically accessible debugger 
> API?
> 
> Alli
> ___
> 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] JSC bindings in the Qt bridge

[Oliver Hunt]

A common problem the we're hitting when working on JSC is that the Qt bridge 
bindings are implemented in terms of JSC internals.  This keeps causing us 
problems as no one working on JSC really knows anything about Qt or the API the 
bridge objects are intended to provide, and yet we are required to keep them 
running when making significant changes.

Given there seems to be little focus on these bindings from Nokia it seems that 
the best path forward is to have them rewritten in terms of the JSC API rather 
than the JSC internals.  This will insulate the bindings from future changes 
and make life a little easier for everyone.  I've filed 
https://bugs.webkit.org/show_bug.cgi?id=60842 to track this change.

If during the conversion people find any short comings in the JSC API that's 
useful too, as it's likely that those problems would impact other users of the 
JSC API and we would welcome bugs being filed on those them (CC'ing me :) ).

Thanks,
  Oliver
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Optional parameter in IDL and undefined JS value

[Oliver Hunt]

An alternative would be to generate code for optional args along the lines of 
(pseudo code):
void foo(Arg1Type arg1, [Optional] Arg2Type arg2);
=>
Arg1Type arg1 = toArg1Type(arguments[0]);
if (arguments.length < 2)
return impl->foo(arg1);
Arg2Type arg2 = toArg2Type(arguments[1]);
return impl->foo(arg1, arg2);


This would allow the C++ impl to use overloading to resolve things correctly.

--Oliver

On Apr 21, 2011, at 10:16 PM, Jian Li wrote:

> One other way is to write custom binding code to handle this case specially.
> 
> 
> On Thu, Apr 21, 2011 at 10:07 PM, Maciej Stachowiak  wrote:
> 
> On Apr 21, 2011, at 6:29 PM, Jian Li wrote:
> 
>> I've pinged the spec author to make it clear in the spec. What is meant in 
>> the spec is really that we want Blob.slice to have the same exact behavior 
>> as Array.slice defined in ECMAScript 5, 15.4.4.10. That is, 
>> Blob.slice(start) has the same result as Blob.slice(start, undefined).
>> 
>> The current code generator scripts will convert undefined value to 0. But we 
>> really want to use the custom default value for Blob.slice. Do we want to 
>> consider adding "DefaultValue=" extended attribute support to IDL?
> 
> I'd prefer if we can find a way to solve it that does not require diverging 
> our IDL dialect further from Web IDL, especially since this is the only 
> method likely to need the feature. Are there any other practical solutions?
> 
> Regards,
> Maciej
> 
>> 
>> Thanks,
>> 
>> Jian
>> 
>> 
>> On Thu, Apr 21, 2011 at 3:38 AM, Maciej Stachowiak  wrote:
>> 
>> On Apr 21, 2011, at 12:14 AM, Jian Li wrote:
>> 
>> > The current File API spec says that:
>> > If the end parameter is not provided (undefined), let relativeEnd be 
>> > size.
>> 
>> That seems like loose wording. Parameter not provided and parameter provided 
>> with a value of undefined are in general not the same thing. The spec should 
>> be explicit about which cases it's talking about.
>> 
>> Regards,
>> Maciej
>> 
> 
> 
> ___
> 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] [webkit-changes] [83955] trunk

[Oliver Hunt]

Indeed, i missed the gtk release one, but the point stands that just rolling 
out a patch (which should not roll out the changelogs) without providing any 
information about the crash doesn't help anyone.

--Oliver

On Apr 15, 2011, at 10:30 AM, Adam Roben wrote:

> On Apr 15, 2011, at 1:19 PM, Oliver Hunt wrote:
> 
>> Don't roll out patches that don't break any core builders, without making 
>> some attempt to diagnose the problem or providing information that will make 
>> it possible to fix the problem.
> 
> The GTK bots are core builders.
> 
> -Adam
> 

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

Re: [webkit-dev] Single location for people wanting to learn to use dev tools WAS: Blog post draft: dealing with exceptions using Web Inspector

[Oliver Hunt]

On Apr 13, 2011, at 2:06 PM, Ojan Vafai wrote:

> Do we have a single page to point people to for learning to use the 
> inspector? Would be nice if there were a page that just linked to all the 
> blog posts.
> 
> On Wed, Apr 13, 2011 at 2:02 AM, Yury Semikhatsky  wrote:
> 
> 
> 
I don't see this stack trace in the inspector when i try it :-/
> Note that for more information on the recent features of the Web Inspector, 
> you can visit the Chrome DevTools documentation page.
> 
It seems like it would be good to get inspector details onto webkit.org

--Oliver

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

Re: [webkit-dev] bugid in ChangeLog

[Oliver Hunt]

If you use webkit-patch everything just magically works (yay!!)

--Oliver

On Mar 26, 2011, at 11:30 AM, Brent Fulgham wrote:

> 
> On Mar 26, 2011, at 10:41 AM, Darin Adler wrote:
> 
>> On Mar 26, 2011, at 3:24 AM, Patrick Gansterer wrote:
>> 
>>> Sometimes folks commit changes without bug numbers. If those changes breaks 
>>> things it's hard to find the correct context for the change.
>>> Can we make the bug number a requirement for a commit when it has a 
>>> corresponding bug?
>>> IMHO it would be great if the style bot and the reviewer complain about 
>>> missing bug numbers.
>> 
>> I don’t think we should require a bug report for every commit.
> 
> I don't want to have a bug report for everything either, but I do agree that 
> my failure to include it in the changelog for the FontPlatformData change was 
> a stupid oversight.
> 
> I'll make sure to avoid that mistake in the future!
> 
> -Brent
> ___
> 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] Canvas backing resolution

[Oliver Hunt]

WebKit's canvas implementation has always scaled the backing buffer according 
to actual screen resolution,  i suspect it doesn't pay any attention to zoom 
however :-/

Arguably that's a bug.

--Oliver

On Mar 4, 2011, at 10:08 AM, Charles Pritchard wrote:

> In the future?
> 
> 
> 
> On Mar 4, 2011, at 8:51 AM, Oliver Hunt  wrote:
> 
>> For reference desktop webkit implementations will automatically increase the 
>> canvas backing store resolution as the device:css pixel ratio increases.
>> 
>> --Oliver
>> 
>> On Mar 4, 2011, at 1:44 AM, Charles Pritchard wrote:
>> 
>>> On 3/4/2011 1:35 AM, Kenneth Rohde Christiansen wrote:
>>>> Hi again,
>>>> 
>>>>> I'm trying to keep the canvas bitmap at the same pixel resolution as the
>>>>> device,
>>>>> otherwise it is blurry.
>>>> OK, I see.
>>>> 
>>>>> This, for example, works if the pixel ratio is 2.
>>>>> >>>> height="200">
>>>>> 
>>>>> Yes, when the user has a zoom level set, I'd like to paint to match the
>>>>> pixel ratio,
>>>>> so that, a zoomed in user still receives crisp output, instead of blurry
>>>>> output.
>>>> -webkit-device-pixel-ratio does not change when the user scaled the
>>>> content; it is a device value.
>>>> 
>>>> On old iPhone it is 1.0, on Android it can be 0.5, 1.0 and 1.5
>>>> depending on it being a low, medium (160) or high dpi (240) device. On
>>>> the iPhone 4 and the new iPod Touch it is 2.0.
>>>> 
>>>> On Android devices, with for instance, a device-pixel-ratio of 1.5,
>>>> you can disable the upscaling by adding target-densitydpi=device-dpi
>>>> to the viewport meta tag.
>>>> 
>>>> What you can do is to disable user scaling (add user-scaling=no to the
>>>> viewport meta tag) and then handle zooming in your app using the touch
>>>> events. This only works on mobile devices though.
>>> 
>>> I haven't debugged with enough tablet devices, such as the color kindle, to 
>>> know how many webkit distros it works with.
>>> What should I do about user zoom on the desktop (and possibly, the kindle) ?
>>> 
>>> Drawing in high res, just-in-case, makes for a poorer experience for users 
>>> at a 1.0 ratio,
>>> and asking users to slide a "sharpen" slider is a little awkward.
>>> 
>>> Mozilla, in their implementation, has setup device-pixel-ratio to scale 
>>> when the user scales content;
>>> they directly expose window css pixel ratio value to trusted scripts, but 
>>> not to web content; requiring
>>> web content to use css device-pixel-ratio.
>>> 
>>> Microsoft has exposed the values through window.screen.
>>> 
>>> 
>>> 
>>> -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] Canvas backing resolution

[Oliver Hunt]

For reference desktop webkit implementations will automatically increase the 
canvas backing store resolution as the device:css pixel ratio increases.

--Oliver

On Mar 4, 2011, at 1:44 AM, Charles Pritchard wrote:

> On 3/4/2011 1:35 AM, Kenneth Rohde Christiansen wrote:
>> Hi again,
>> 
>>> I'm trying to keep the canvas bitmap at the same pixel resolution as the
>>> device,
>>> otherwise it is blurry.
>> OK, I see.
>> 
>>> This, for example, works if the pixel ratio is 2.
>>> >> height="200">
>>> 
>>> Yes, when the user has a zoom level set, I'd like to paint to match the
>>> pixel ratio,
>>> so that, a zoomed in user still receives crisp output, instead of blurry
>>> output.
>> -webkit-device-pixel-ratio does not change when the user scaled the
>> content; it is a device value.
>> 
>> On old iPhone it is 1.0, on Android it can be 0.5, 1.0 and 1.5
>> depending on it being a low, medium (160) or high dpi (240) device. On
>> the iPhone 4 and the new iPod Touch it is 2.0.
>> 
>> On Android devices, with for instance, a device-pixel-ratio of 1.5,
>> you can disable the upscaling by adding target-densitydpi=device-dpi
>> to the viewport meta tag.
>> 
>> What you can do is to disable user scaling (add user-scaling=no to the
>> viewport meta tag) and then handle zooming in your app using the touch
>> events. This only works on mobile devices though.
> 
> I haven't debugged with enough tablet devices, such as the color kindle, to 
> know how many webkit distros it works with.
> What should I do about user zoom on the desktop (and possibly, the kindle) ?
> 
> Drawing in high res, just-in-case, makes for a poorer experience for users at 
> a 1.0 ratio,
> and asking users to slide a "sharpen" slider is a little awkward.
> 
> Mozilla, in their implementation, has setup device-pixel-ratio to scale when 
> the user scales content;
> they directly expose window css pixel ratio value to trusted scripts, but not 
> to web content; requiring
> web content to use css device-pixel-ratio.
> 
> Microsoft has exposed the values through window.screen.
> 
> 
> 
> -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] A tip for committers

[Oliver Hunt]

webkit-patch could be made aware of them -- how does the commit-queue handle 
it?  If a patch doesn't include mime type info i would imagine it's doing 
something to prevent the annoying diff spew.

--Oliver

On Mar 3, 2011, at 8:42 AM, Adam Roben wrote:

> On Mar 3, 2011, at 11:40 AM, Oliver Hunt wrote:
> 
>> Can the style bot be made aware of .png at least and complain if you don't 
>> set the right flags?
> 
> Subversion properties aren't captured in patches, so the style bot is too 
> early in the process. We could add a pre-commit hook to check for the right 
> properties, though.
> 
> -Adam
> 

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

Re: [webkit-dev] A tip for committers

[Oliver Hunt]

Can the style bot be made aware of .png at least and complain if you don't set 
the right flags?

--Oliver

On Mar 3, 2011, at 6:45 AM, Adam Roben wrote:

> All committers are encouraged to follow the instructions I just added to 
> :
> 
>> Subversion has a handy feature called auto-props that will ensure that new 
>> binary files you add to the repository are given the correct MIME type. To 
>> set this up, find the following two lines in ~/.subversion/config and 
>> uncomment them:
>> 
>> enable-auto-props = yes
>> 
>> *.png = svn:mime-type=image/png
>> 
>> Note that this will work even if you use git-svn to commit changes to WebKit.
> 
> This will prevent your webkit-changes emails from being filled with 
> gobbledy-gook like this:
> 
>> +\x89PNG
>> +
>> +
>> +IHDR X'bKGD\xFF\xFF\xFF\xA0\xBD\xA7\x93 
>> IDATx\x9C\xED\xDD{\x90\x95\xE5}\xC0\xF1\xF7\xC8\xCBeq\x97\x8B\x90%q) 
>> \xC2RASk:8\x89\xB9\xD0L\xB5Tt'\xEB0:\xA3i
>> +4b\xA3S#"SsA\x89Q[\xB0x

>> jiA#7\x89\xB2Fv\xB9(7Yݷ\x9C\x99\x9D\xCD^\xEF.?\xF4\xF3\xF9\xEBx\xF6}\xDF\xE7y\xDEs\x8E\xFB\x9D\xF7\xCE\xE6\xD24M\x88sډ\x9E\xC0g\x8D\xC0&\xB0\x82
>>,\x80` \x98\xC0&\xB0\x82,\x80` 
>> \x98\xC0Vt,;\xEF޽\xFB\xE0\xC1\x83EEE\xBD{\xF7nx\xBBUy\xF7\xDDw\xB7o\xDF>lذ\xAE]\xBB6\xFDiuuummmII\xC9駟ު\xC3VUU%Iҽ{\xF7Ν;\xB7j\xC7cת\xA1\xDB|\xDEZ\xA5ͧ\xB1\x91\x96f\xBBgϞ\xB4k׮O\x9F>Y\xB6\xCF\xE2\xFD\xF7\xDF?t\xE8P\xA7N\x9Dz\xF4\xE8\xD1\xDA}[\x9Aϧ\xE0x<\xA0Q\x9F\x9ALW\xB0\xDE{\xEF\xBD\xFA\xA7z\xE6\x99gݿ}\xFB\xF6\xDBn\xBB\xED\xE2\x8B/nt;\xBB|\xF0_\xFE\xE5_fϞ\xFD\xEC\xB3\xCF6\xBB\xC1\xBAu뮸⊟\xFC\xE4'\xAD:l\x92$/\xBF\xFC\xF2\xC0\x81\xFB\xDB߶v\xC7cת\xA1\xDBv\xDEZ\xABͧ\xB1\x91\x96f\xFB\xCE;\xEF\xFC\xE8G?>|x\xC6\xED\xB3ضm\xDB5\xD7\\xF3\xDD\xEF~\xB7\xF0f\xCF?\xFF\xFC\xFC\xC7d\x9COk5{\xF0Ž\xC7Z\xE0\xE1k\xC3
>> 
\xF8d
>> +\xAC_\xFF\xFA\xD7s\xE7\xCE\xFD\xE7\xFE\xE7F\xF7\x8F1\xE2K_\xFAR\xD3\xDB> +\xDA0C>\x99\xEB\x99g\x9E\xB9\xFB\xEE\xBB_}\xF5\xD5\xD7_=p\xEC\xED۷\xF8\xE1\x87%%%\xA5\xA5\xA5\x8D~\x95>\xF9\xE4\x933g\xCE<\xF6!N;\xED\x84}\xC8\xEC\xFD\xB9\xF2\x8B_\xFCbݺu\x81l\xF8܋=xk\x9F\xD5Y\xB6_>!\x8E\xFE\xACu\xEB\xD6UTT\{\x{DD77}\xDCr˜9s~\xFAӟ\xB6a\x98Ç?\xF5\xD4Suuu\xDF\xFAַ:u\xEA\x94$ɞ={\xF2o>\xF9䓝;w\xBE\xFA\xEA\xABs\xB9\~\xE3-[\xB6\xDCy\xE7\x9DÆ
>> +{\xEC\xB1\xC7ƍ\x97$I\xBBv\xED֮]\xFB\xEC\xB3\xCFv\xEC\xD8qҤIݺu\xCBo\xB9{\xF7\xEEy\xF3\xE6%Ir\xDDuםq\xC6M\xC7ݷo\xDF̙3kkk'L\x98PVVV`>\xAF\xBE\xFA\xEA\xE6͛\x93$\xE9ٳ\xE7\xF0\xE1ß{\xEE\xB9$I*++\xCF?\xFF\xFCfڱc\xC7c\x8F=\xF6\xC1\x9Cs\xCE9\xD7_}\xFE
>>  
>> Y\x86>ꜛ\xCE\x{DDFF}\xFDm]]]\x92$\x83\xBE\xE0\x82\xEA\xB7|\xF7\xDDwW\xAE\\x99$\xC9СC
> 
> (My hat is off to those brave souls who keep the bots green by rebaselining 
> tests. My hat will be even more off to you if you follow this tip!)
> 
> -Adam
> 
> ___
> 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] Sharing the OpenGL GraphicsContext3D implementation

[Oliver Hunt]

I agree.  My hope was always that the OpenGL backend could be shared among all 
the webkit ports, my only suggestion is that rather than having a separate 
OpenGLExtensionsFunctions class, I think we probably want something like

GraphicsContext3DOpenGL.{h,cpp} for all the common logic

and then

GraphicsContext3DOpenGL{Gtk, Mac, Wx, Posix, ...}.cpp

etc

To implement the functions that can't be shared.

This would be in keeping with our normal design approach for using system 
platform specific APIs.

--Oliver


On Feb 22, 2011, at 12:53 PM, Zan Dobersek wrote:

> Hi,
> 
> I'm writing this mail in order to propose changes that would make the OpenGL 
> implementation of the GraphicsContext3D a lot easier to share between the Mac 
> and Gtk port.
> 
> Currently the mentioned implementation is only used by the Mac port. The Gtk 
> port is also interested in using this implementation and there is already a 
> patch available in bug #31517[1] by Martin Robinson that brings the WebGL 
> functionality to daylight.
> 
> There is, however, the issue of the OpenGL extensions functions. Current 
> OpenGL implementation is Mac-only, and Mac port has a specific set of 
> extensions functions available. The same cannot be said for the Gtk port, 
> which can end up having extensions functions available that do not have the 
> same extension suffix as the Mac port's functions (EXT vs ARB). Because of 
> that the current proposed implementation acquires addresses of the OpenGL 
> extensions functions and then uses shims to make the GraphicsContext3D work.
> 
> I recommend a new class to be created for these two ports to use, named 
> something like OpenGLExtensionsFunctions. Extensions-specific functions in 
> the GraphicsContext3D class would then be replaced with calls to the 
> corresponding functions in this class, for example 
> OpenGLExtensionsFunctions::blitFramebuffer instead of current 
> ::glBlitFramebufferEXT. Implementation for the Mac port would be simple, 
> passing arguments on to functions that are currently used in the 
> GraphicsContext3D class. Gtk port's implementation would simply call the 
> functions that were acquired, with no need to depend on shims.
> 
> Modifying the OpenGL implementation of the GraphicsContext3D class in this 
> way would ease the use of it for the Gtk port and perhaps any other port that 
> would go on to use this implementation with no damage to the Mac port.
> 
> I'd like to hear what Mac folks think of this approach and if there are any 
> other ideas that address this problem.
> 
> Regards,
> Zan Dobersek
> 
> [1] https://bugs.webkit.org/show_bug.cgi?id=31517
> ___
> 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] code review tool changes

[Oliver Hunt]

I just discovered that the review tool doesn't save the general comments, only 
inline ones (http://webkit.org/b/54121).  This just got me when I clicked on 
the style bot to see what style checks had failed and lost my feedback :(

This was particularly annoying as i had command-clicked the link (to open in a 
new tab) and the link actually forced the current page to navigate instead - 
http://webkit.org/b/54113

--Oliver

On Feb 8, 2011, at 2:39 PM, Ojan Vafai wrote:

> On Wed, Feb 9, 2011 at 7:59 AM, Kenneth Russell  wrote:
> On Tue, Feb 1, 2011 at 6:02 PM, Kenneth Russell  wrote:
> > On Tue, Feb 1, 2011 at 5:09 PM, Ojan Vafai  wrote:
> >> There's been a slew of changes to the code review tool. It's probably a 
> >> good
> >> time to send a summary now that I don't intend to add significant new
> >> features.
> >> -Side-by-side diffs: You can view the entire diff or individual files in
> >> side-by-side diff. If you change the entire diff, we'll store that in
> >> localstorage and load diffs in side-by-side by default.
> >> -Comments and diff navigation: n/p keys will navigate to the next/previous
> >> comment. j/k will navigate to the next/previous diff.
> >> -Draft comments persist: draft comments are now stored in localstorage, so
> >> they will persist across reloads, crashes, etc. Since it's in localstorage
> >> it's stored per-machine.*
> >
> > Thank you for this in particular. Several times I've accidentally
> > navigated away from a review and lost work.
> 
> I just temporarily lost Internet connectivity while uploading a
> (large) review and when I came back to the review (same browser, etc.)
> all of my comments were lost. Is this functionality expected to work
> with Chrome 9 stable?
> 
> When you click the publish button, we clear all the saved drafts. :( 
> Otherwise we'd continue showing the draft comments alongside the published 
> ones. I suppose I should find a way to make that happen when the publish 
> actually succeeds instead. 
>  
> 
> Thanks,
> 
> -Ken
> 
> > -Ken
> >
> >> -Expand diff context: You can expand the lines above/below a diff to see
> >> more context.**
> >> Hope this works well for you all. Obviously, file bugs if something isn't
> >> working.
> >> Ojan
> >> * Taking the next step and storing them online for non-security bugs (e.g.
> >> in S3 or appengine) would be a simple and welcome addition if someone feels
> >> moved.
> >> ** This currently only works if the patch includes the svn revision it was
> >> created at (i.e. it was created with SVN) or applies cleanly to trunk.
> >> Including the SVN revision in git diffs shouldn't be too hard. Again, if 
> >> you
> >> feel moved to fix this, ping me.
> >> ___
> >> 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] code review tool changes

[Oliver Hunt]

I just discovered that the review tool doesn't save the general comments, only 
inline ones (http://webkit.org/b/54121).  This just got me when I clicked on 
the style bot to see what style checks had failed and lost my feedback :(

This was particularly annoying as i had command-clicked the link (to open in a 
new tab) and the link actually forced the current page to navigate instead - 
http://webkit.org/b/54113

--Oliver

On Feb 8, 2011, at 2:39 PM, Ojan Vafai wrote:

> On Wed, Feb 9, 2011 at 7:59 AM, Kenneth Russell  wrote:
> On Tue, Feb 1, 2011 at 6:02 PM, Kenneth Russell  wrote:
> > On Tue, Feb 1, 2011 at 5:09 PM, Ojan Vafai  wrote:
> >> There's been a slew of changes to the code review tool. It's probably a 
> >> good
> >> time to send a summary now that I don't intend to add significant new
> >> features.
> >> -Side-by-side diffs: You can view the entire diff or individual files in
> >> side-by-side diff. If you change the entire diff, we'll store that in
> >> localstorage and load diffs in side-by-side by default.
> >> -Comments and diff navigation: n/p keys will navigate to the next/previous
> >> comment. j/k will navigate to the next/previous diff.
> >> -Draft comments persist: draft comments are now stored in localstorage, so
> >> they will persist across reloads, crashes, etc. Since it's in localstorage
> >> it's stored per-machine.*
> >
> > Thank you for this in particular. Several times I've accidentally
> > navigated away from a review and lost work.
> 
> I just temporarily lost Internet connectivity while uploading a
> (large) review and when I came back to the review (same browser, etc.)
> all of my comments were lost. Is this functionality expected to work
> with Chrome 9 stable?
> 
> When you click the publish button, we clear all the saved drafts. :( 
> Otherwise we'd continue showing the draft comments alongside the published 
> ones. I suppose I should find a way to make that happen when the publish 
> actually succeeds instead. 
>  
> 
> Thanks,
> 
> -Ken
> 
> > -Ken
> >
> >> -Expand diff context: You can expand the lines above/below a diff to see
> >> more context.**
> >> Hope this works well for you all. Obviously, file bugs if something isn't
> >> working.
> >> Ojan
> >> * Taking the next step and storing them online for non-security bugs (e.g.
> >> in S3 or appengine) would be a simple and welcome addition if someone feels
> >> moved.
> >> ** This currently only works if the patch includes the svn revision it was
> >> created at (i.e. it was created with SVN) or applies cleanly to trunk.
> >> Including the SVN revision in git diffs shouldn't be too hard. Again, if 
> >> you
> >> feel moved to fix this, ping me.
> >> ___
> >> 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] Renaming directories

[Oliver Hunt]

On Dec 21, 2010, at 1:49 PM, Maciej Stachowiak wrote:
> And we have JavaScriptCore API tests which are not run automated.

The JSC API tests run as part of run-javascript-tests, which the build bots do 
execute

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

Re: [webkit-dev] Should we recommend explicit constructors as part of WebKit style?

[Oliver Hunt]

On Sep 28, 2010, at 4:26 PM, David Levin wrote:

> This came up before: 
> https://lists.webkit.org/pipermail/webkit-dev/2010-May/012873.html but I'd 
> like to understand it a bit better.
> 
> It feels there were two points of view:
> Use explicit only when necessary to prevent an undesirable implicit 
> conversion like int to vector.
> Use explicit except when it is desirable to allow an implicit conversion that 
> makes the code simpler. For example, the String <-> AtomicString makes the 
> bindings generator code simpler since it doesn't need to know which the 
> underlying method takes.
> Are there any reasons beyond personal preference to select either of these?
> 
> Starting list:
> 
> Pro's for #1
>   It is a pain to remember to put explicit every time you have a constructor 
> with one argument.

Could check-webkit-style be beaten into forcing this for us?

> 
> Pro's for #2
>It would prevent accidental mistakes that happen with implicit 
> constructors.
> 
> dave
> 
> ___
> 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] Review tool changes

[Oliver Hunt]

I really would like to be able to select some text and add a comment that uses 
the selection as context, a single line of context is frequently insufficient, 
this is about the only thing that still makes the new review tool less 
effective than the old review mechanism (for me at least).

--Oliver

On Sep 20, 2010, at 11:32 AM, Darin Adler wrote:

> On Sep 20, 2010, at 10:22 AM, Darin Fisher wrote:
> 
>> How about this?
>> 
>> If any annotations were made to the patch, then "the button" gets named 
>> Preview.  Else, the button is named "Publish" and when clicked performs its 
>> work in one shot.
>> 
>> Was there a strong outcry for removing the preview step?  I only found it 
>> bothersome when I wanted to issue a quick r=me on a patch that didn't 
>> require any additional changes.
> 
> Good idea. Here’s another idea:
> 
> The button starts out named Preview and works with a preview.
> 
> If the review or commit-queue flag is altered then the button is changed to 
> “Publish” and works without a preview.
> 
> Thus if I like the preview work flow, I don’t set those flags until I get to 
> the preview page. If I like the faster work flow, I can set a flag and then 
> push Publish.
> 
> One type of person who is not served by my proposal is someone who wants to 
> add comments only and not set a flag but wants the faster work flow.
> 
>-- Darin
> 
> ___
> 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] Blob scheme implementation

[Oliver Hunt]

On Sep 14, 2010, at 5:56 PM, David Levin wrote:

> On Tue, Sep 14, 2010 at 5:42 PM, Adam Barth  wrote:
> What do you think of the idea of having a re-useable BlobCore module
> that all the ports can share?
> 
> I don't think this is a good idea. This "re-usable module" would only be used 
> by the Safari WebKit port. As I understand it, Chromium wouldn't be able to 
> re-use it due to not re-using WebKit types in general. With only one port 
> using it, the module seems like it would not be able to have a good design.

What about Gtk, Qt, Wx, Efl...?  Where possible these days we seem to implement 
a single impl in webcore that is used by everyone

--Oliver

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

Re: [webkit-dev] Changes to line-by-line code reviews

[Oliver Hunt]

It would be nice if you could select a block of code and have the comment be 
for that block -- last i looked the line by line review basically loses context 
for reviews as it pushes the comments to the bottom and only includes a single 
line of context.

--Oliver

On Aug 29, 2010, at 11:13 AM, Adam Barth wrote:

> Based on some feedback, I'm going to try to improve the line-by-line
> review tool.  I've landed the first iteration of the new design, which
> should be usable and have roughly the same functionality as the old
> design.  I'll be adding new features shortly.
> 
> The main difference is you now access the line-by-line review feature
> using the "Formatted Diff" link in bugs.webkit.org instead of the
> "Review Patch" link.  I made this change so that folks who like the
> old "Review Patch" tool won't be bothered by the new tool.  If you
> have feature requests, let me know.  I'll post an update once the tool
> is awesomified.
> 
> Thanks,
> Adam
> ___
> 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] Canvas performance and memory usage

[Oliver Hunt]

The reason ImageBuffer::image() makes a copy (be it a deep copy, or CoW) is 
almost exclusively for the purpose of ensuring correct behaviour in the case 
where a canvas is drawn onto itself, eg.

context = myCanvas.getContext("2d");
context.drawImage(myCanvas, 0, 0);

Off hand I can think of no other case where this would be necessary, so it 
seems like the best solution would be to make the default behaviour for image() 
be to return a reference to a potentially mutable image, and to give the canvas 
a distinct method for getting a copied image in the case where it's actually 
necessary.

--Oliver

On Aug 4, 2010, at 2:45 PM, Christophe Public wrote:

> Hi,
> 
> Actually, I was questioning also the necessity of this extra buffer.
> I'll just give an update and some numbers. We have a very large canvas (few 
> MB) and our updates are very frequent but very small (clip area is for 
> example 3x3 pixels), it takes about 25ms for our system to handle the expose. 
> Once the double buffer is removed, the expose takes less than 1ms.
> 
> We applied our change to image(). When the BitmapImage is created, we now 
> pass the m_data.m_surface after increasing its reference count through 
> cairo_surface_reference and removed the copy.
> 
> Our tests didn't detect any issue after this change.
> 
> Christophe
> 
> On Wed, Aug 4, 2010 at 11:07 AM, David Hyatt 
> 
>  wrote:
> I'm confused why a special method is needed though.  Can't image() just avoid 
> the full copy?  Given how we use image() in WebKit, I don't think there's any 
> reason to be concerned if image() continues to reflect the contents of the 
> ImageBuffer.  I think we should just switch to that model for the CG port 
> also anyway, since I'm unconvinced we're truly avoiding a copy, and return an 
> image with a custom data provider that feeds the current contents of the 
> ImageBuffer to the image.
> 
> dave
> (hy...@apple.com)
> 
> On Aug 3, 2010, at 8:55 PM, Martin Robinson wrote:
> 
> > Resent from the proper address:
> >
> > On Tue, Aug 3, 2010 at 6:00 PM, Martin Robinson
> >  wrote:
> >>> I notice that Qt added imageForRendering() and felt they could not use
> >>> image() for some reason.  I'd be curious if a Qt expert could weigh in on
> >>> that, since maybe with a redesign a separate call would not be needed.
> >
> > I'm not a Qt expert, but just based on a quick look, it seems that
> > imageForRendering  avoids the full QPixmap copy. Christophe,
> > when you open a bug for this issue,  please CC me, as I have a
> > small patch in my tree which has the same imageForRendering
> > pecialization, but for Cairo.
> >
> > Martin
> > ___
> > 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] Handling IME composition events

[Oliver Hunt]

On Jul 28, 2010, at 8:45 AM, Joone Hur wrote:

> Hello all,
> 
> I’m working on a Hangul(Korean alphabet) composition issue in WebKit.
> https://bugs.webkit.org/show_bug.cgi?id=40518
> By the way, I noticed that WebKit based browsers are inconsistent with
> IME composition events.
> 
> According to the W3C DOM Level 3 events(http://bit.ly/bM7YVQ),
> 1) A browser should fire compositionstart, compositionupdate, and
> compositionend event during a composition.
> 2) The textEvent event should be dispatched after a compositionend
> event if the composition has not been canceled.
> 3) While a composition session is active, keyboard events should not
> be dispatched to the DOM (i.e., the text composition system "swallows"
> the keyboard events), and only compositionupdate events may be
> dispatched to indicate the composition process.
The DOM Level 3 event model for input composition does not match the 
requirements of actual web content.  This is unfortunate, but will hopefully be 
fixed in future.

> 
> However, all ports of WebKit handle composition events in inconsistent
> ways. Even keyboard events are still dispatched to the DOM during a
> composition.
> 
> Therefore, it is necessary to fix those problems as follows:
> 1) IME Composition events should be handled consistently in all ports of 
> WebKit.
I'm not sure this can be achieved as it depends (to an extent) on the platform 
IME system, and the active IME -- different IMEs have completely different 
behaviours making consistent behaviour across multiple platforms is an exercise 
in futility.

However if you're seeing different behaviour with the same IME on a single 
platform that's a bug.

> 2) The textInput event should be dispatched after a compositionend event.
Unsure of the specifics of this.

> 3) Keyboard events should not be dispatched during a composition.
Key events must be sent while an IME is active otherwise sites break.  IIRC you 
get keydown and keyup events, but not keypress.  The keydown event when an IME 
is active has charCode 229 in order to be compatible with IE.

--Oliver

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

Re: [webkit-dev] A Parallel Webkit?

[Oliver Hunt]

> Shared-state parallel scripting (and concurrent DOM) seem inevitable
I don't know why you believe this -- there is no intention of having shared 
state threading in ES, nor is there any desire in the ES technical committee to 
add any for of concurrency primitives to the language.

--Oliver


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

Re: [webkit-dev] A Parallel Webkit?

[Oliver Hunt]

On Jul 23, 2010, at 4:50 PM, Leo Meyerovich wrote:

> 
>> I wasn't entirely sure what OP was after of if the reply below
>> adequately addressed his interests.
> 
> WebKit2 seems to have little to do with taking advantage of parallel hardware 
> in browser algorithms like lexing, parsing, selectors, JS compilation, JS 
> execution, layout, DOM interactions, fonts, rendering, etc.

JS execution and DOM manipulation are single threaded, and that thread is the 
UI thread, this fact cannot be changed.  JS compilation is also done lazily in 
webkit so we don't ever end up with multiple pieces of code to compile 
concurrently.

--Oliver

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