Re: [webkit-dev] Fonts for WebKit tests on OS X?

2016-03-13 Thread Darin Adler
I don’t think the size of the font files in the repository is a significant 
issue; are the sizes particularly huge compared to the total size of all the 
layout tests including expected results? If this was a problem, we could come 
up with some other way of having the test machinery download the fonts, but I 
think the complexity of that is not justified to solve a problem that may be a 
non-problem.

Aside from the size of the font files, it seems like we have at least three 
separate issues:

1) To make MathML work really well, platforms need to include appropriate 
fonts. As you said, this is not a WebKit decision, but a decision made by 
platform owners. If we want to advise them about the importance of this, it 
would be good to draft something explaining how we, the WebKit project, see 
this requirement and give advice on what to do. Someone should write a draft of 
this recommendation so we can put it somewhere on webkit.org, and also so we 
can discuss and make sure we agree on this advice. I’d like to see this written 
in the form of a recommendation so we can see if this is really a practical 
request. To give one example, “please use STIX Math, but version 2 which is not 
out yet” isn’t a great recommendation.

2) Since many people will be using WebKit on existing systems, it also seems 
important to design and to test what MathML does when these fonts are not 
present. It’s not enough to say “they should include the fonts”; we need to 
figure out what behavior we want, and test that the implementation does what we 
want. This means that we do *not* want to run all tests with these extra fonts. 
We need to test what will actually happen for users. I don’t think it’s right 
for the WebKit project to just take the stance, “it will look wrong when the 
fonts are not there”. Lets figure out what we are trying to do in that case. I 
could even imagine deciding something radical like deciding that the browser 
should not even expose the MathML elements if suitable fonts aren’t present.

3) For OS X and also iOS, we would like to test MathML with fonts that are 
currently not included with the OS; testing the “best case” version of MathML 
even if it’s not available in practice to OS X and iOS users at this time. The 
test runners for OS X and iOS already have code to activate fonts provided in 
font files for testing purposes. That’s done by the activateFonts function in 
ActivateFontsCocoa.mm, and the activateTestingFonts and activateFontsIOS 
functions in DumpRenderTree.mm. Currently this turns the fonts on 
unconditionally for all tests and so would get in the way (2) above. Note that 
there is also a mechanism alongside this called PLATFORM_FONT_LOOKUP, increases 
consistency of regression test results by blocking all fonts except for the 
ones on a whitelist, and so if the font is not listed in that whitelist it will 
be blocked.

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


Re: [webkit-dev] [Block Pointer] Deterministic Region Based Memory Manager

2016-03-13 Thread Timothy Hatcher

> On Mar 13, 2016, at 10:06 AM, Phil Bouchard  wrote:
> 
> I just thought you might be interested in this benchmark.


Please stop email this list until you provide benchmark results replacing 
JavaScriptCore’s GC. The benchmarks you are providing are irrelevant to 
JavaScriptCore’s needs. We are not interested.

— Timothy Hatcher



smime.p7s
Description: S/MIME cryptographic signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] [Block Pointer] Deterministic Region Based Memory Manager

2016-03-13 Thread Phil Bouchard

On 03/11/2016 09:56 PM, Phil Bouchard wrote:

On 03/06/2016 10:57 PM, Phil Bouchard wrote:


True but if block_ptr<> is 10x faster than the Mark & Sweep GC then I
think we got something perhaps worth investigating.



- For the record, now block_ptr<> is 600% times faster than shared_ptr<>
so it's a good start:

new:
auto_ptr:   23174753 ns
shared_ptr: 49726615 ns
block_ptr:   7812659 ns


Sorry for the confusion but the real benchmark of the pointers is:

unique_ptr (new): 47.7686
unique_ptr (make_unique): 46.8545
shared_ptr (new): 77.8261
shared_ptr (make_shared): 50.8072
shared_ptr (make_shared_alloc_noinit): 33.021
block_ptr (new): 69.6554

But block_ptr<> handles cyclic references as well.  I just thought you 
might be interested in this benchmark.



Regards,
-Phil

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