[webkit-dev] Making performance tests in WebKit more useful
Hi, Three major problems with existing WebKit performance tests are: 1. There are too many tests to run 2. Some tests have variances that are too high to be of any use 3. Some tests are too specific to be of any general use To address them, I’m going to segregate the tests into 3 tiers: 1. Reliable tests that should be run on bots and locally when testing patches. 2. Supplemental tests that could be ran optionally. 3. Skipped tests. In addition, I’m going to add a forth category between 1 and 2 for new tests that have just been added since deciding whether a test is reliable or not is hard unless we have some data. This forth category is very important because while perf.webkit.org has an ability to aggregate results for each suite (e.g. for the entire DOM) by arbitary functions (e.g. arithmetic means, geometric means, etc…), letting everyone add arbitary tests to any suite will undermine our ability to monitor the results of reliable tests due to the added noise and means skewed by new tests. In an essense, we need a way to determine whether new tests can be added to tier 1 “test suites”. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Making performance tests in WebKit more useful
On Fri, Mar 8, 2013 at 2:15 AM, Ryosuke Niwa rn...@webkit.org wrote: Three major problems with existing WebKit performance tests are: 1. There are too many tests to run 2. Some tests have variances that are too high to be of any use 3. Some tests are too specific to be of any general use If you find what differentiate the good tests from the bad tests, it would be good to create a wiki page explaining what to be careful about to make a good test. One thing that have bitten my ass in the past is the JIT being smart and removing some dead test code because it has no side effect. I am sure there are plenty of mistake like this to be avoided. Cheers, Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Making performance tests in WebKit more useful
On Fri, Mar 8, 2013 at 2:24 AM, Benjamin Poulain benja...@webkit.orgwrote: On Fri, Mar 8, 2013 at 2:15 AM, Ryosuke Niwa rn...@webkit.org wrote: Three major problems with existing WebKit performance tests are: 1. There are too many tests to run 2. Some tests have variances that are too high to be of any use 3. Some tests are too specific to be of any general use If you find what differentiate the good tests from the bad tests, it would be good to create a wiki page explaining what to be careful about to make a good test. Yeah. We need to spend more time analysing tests in categories 2 3. One thing that have bitten my ass in the past is the JIT being smart and removing some dead test code because it has no side effect. I am sure there are plenty of mistake like this to be avoided. I was always curious about this. I wonder if there’s a good way to amortize the effect so that we can measure relialistic number. The last thing I want is to introduce a lot of measurement biases to lower the variance and end up measuring something unrealistic. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] DnD Help Please with WebKit
My Fellow Community - I am in some need of assistance here. I am certain this is something simple, but am just missing the mark. So please help. Scenario: On Mac OS X 10.7 or greater, I have a webview as a browser. In that webview I navigate to Gmail. In Gmail I compose a message and then drag and drop one or more files into the compose box. Actual Results: The pasteboard has NSURL object(s) and the webview simply takes the absolute string value and pastes it into the composed message body. For other edit areas like the search bar and such this behavior is accepted. Desired Results: It is desired that the drag triggers the HTML5 when mousing over and the drop will trigger the proper javascript to upload the files. This behavior is consistent with how FireFox, Safari, and OmniWeb perform. How do I get this same consistent behavior / What do I need to implement? What I have tried so far: * Using the WebView Editing Delegate I tried replacing the markup in the DOMRange * I subclassed WebView to override performDragging: and modify the DraggingSource pasteboard * Turned on LocalStorage using the WebView preferences private methods Note: The app will be sandboxed and currently is not code signed. So what am I missing or better yet where do I start and end? P.S. I have tried so many things, I didn't want to clutter this question up with the useless code snippets I have tried thus far. However, if solved I will post my results for all others. Q Posted here too: http://stackoverflow.com/questions/15296633/cocoa-webview-and-html5-drag-and -drop -- Arvin Bhatnagar http://careers.stackoverflow.com/ArvinB ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] DnD Help Please with WebKit
I don't want to be a pain but webkit-help is the appropriate mailing list for these kind of questions. webkit-dev is for the development of WebKit itself. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] About USE(CROSS_PLATFORM_CONTEXT_MENUS)
Hi, 2013/2/25 Adam Roben aro...@webkit.org: I was having a look at our Context Menu design when this USE flag got my attention. Can someone help me clarify the motivation for it? The motivation is explained pretty well in the ChangeLog for r73802, which introduced this flag. I'll try to give a little explanation here too. Yes, thanks for the explanation. I got mislead by another revision... Indeed it provides a good clean up for the ContextMenu code in WebCore so I have filled https://bugs.webkit.org/show_bug.cgi?id=111874. Also, is there any other port using it? I don't believe so. But if you look at ContextMenu[Item].h, it looks like CHROMIUM and EFL could very easily switch over to it; they've already implemented something very similar by abusing the PlatformMenuItemDescription typedef. Yes, I've already uploaded a patch for EFL. I will give it a try for Chromium as well. Cheers, jesus -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] -khtml- and -apple- CSS prefixes
I've posted a patch to limit the -apple- and -khtml- CSS vendor prefixes to ENABLE(DASHBOARD_SUPPORT): https://bugs.webkit.org/show_bug.cgi?id=111890 My understanding is that I also need to add a runtime flag in order to fully hide these prefixes from the web because Safari and Dashboard share the same WebCore binary on Mac OS X. I found the following entry in Settings.in: usesDashboardBackwardCompatibilityMode initial=false, conditional=DASHBOARD_SUPPORT However, some of the paces we need to check this flag do not have easy access to the Page and therefore have trouble finding the Settings object. Would it be possible to use a global static flag to hide these prefixes from the web? I don't understand the details of how Safari and Dashboard share WebCore to know if a global static flag would work correctly. Thanks, Adam On Fri, Mar 1, 2013 at 4:57 PM, Maciej Stachowiak m...@apple.com wrote: I think we'll want to take these out for Apple ports as soon as we can check prevalence in older Apple-specific content (e.g. Dashboard widgets). On Fri, Mar 1, 2013 at 9:11 AM, David Hyatt hy...@apple.com wrote: I agree with you that this would be pretty terrible. We definitely don't want developers doing that. On Feb 28, 2013, at 6:02 PM, Adam Barth aba...@webkit.org wrote: I noticed this comment on the Hacker News thread about Paul Irish's recent blog post: ---8--- CSS parsing is the same, though. Slurping up your CSS and turning it into CSSOM’s pretty standard. Yeah, though Chrome accepts just the -webkit- prefix whereas Apple and other ports accept legacy prefixes like -khtml- and -apple-. Using this information, can you target Chrome with the webkit- prefix and Safari with the apple- prefix? Specifying the apple- prefix after webkit- will ensure that Safari uses that one, right? ---8--- http://news.ycombinator.com/item?id=5302150 If developers start using this technique, it might be harder to remove these prefixes in the future. Chromium's experience removing these prefixes has been quite positive. We ran into one compatibility problem on apple.com, which Apple was gracious enough to fix. I'd recommend that the rest of the ports disable ENABLE(LEGACY_CSS_VENDOR_PREFIXES) to remove support for the -khtml- and -apple- CSS prefixes before it's too late. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] LLInt without JIT
LowLevelInterpreter.asm is processed to create LLIntAssembly.h for the built platform. It appears that if there is no jitting configured[1], this will always create the C Loop. Is there any way of using the assembly backends to create LLIntAssembly.h when not jitting? [1]: Source/WTF/wtf/Platform.h:815 /* If the jit is not available, enable the LLInt C Loop: */ ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] for command
How to download webkit on linux ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] for command
This question is more appropriate for webkit-help. Having said that, there is no such thing as WebKit on Linux. There are WebKit's GTK+, EFL, and Qt ports and you build on Linux. See: http://trac.webkit.org/wiki/WebKitGTK http://trac.webkit.org/wiki/EFLWebKit http://trac.webkit.org/wiki/QtWebKit You may also use Chromium Linux port but I'll note that Chromium port only provides a test runner program (DumpRenderTree), not a full browser: http://trac.webkit.org/wiki/Chromium - R. Niwa On Fri, Mar 8, 2013 at 8:37 PM, Vinay Pathak vinaypatha...@gmail.comwrote: How to download webkit on linux ___ 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] LLInt without JIT
Yes. You can use the assembly LLInt backend without using the JIT. That's how I was running it when I first wrote it. I think that the code in Platform.h is being conservative, in the sense that it assumes that if ENABLE(JIT) is not set then you're compiling for a target that the LLInt wouldn't have a backend for. This makes sense, if you think about it: ENABLE_JIT is defined to 1 if we detect that we are on a hardware/OS configuration that the JIT knows how to handle, and the LLInt has backends for strictly fewer platforms than the JIT has backends for: JIT supports x86 (32 and 64), ARM (traditional and THUMB2), MIPS, and SH4; while the LLInt currently only supports x86 (32 and 64), ARM THUMB2, and MIPS. In short, requiring the JIT to use LLInt assembly backends is not a strong requirement of the LLInt; it's just an artifact of Platform.h's logic. On hardware/OS configurations where ENABLE(JIT) is set, and the LLInt is compiled to assembly, it is still possible to run with the JIT disabled. The JIT ends up being disabled at run-time in that case. We often use this for testing - you can set the JSC_useJIT environment variable to 'false' and then you're running in a LLInt-only mode. This allows for quickly checking if a bug is due to the JITs, or not. But I would also note that the purpose of the LLInt assembly backends is _not_ performance of the LLInt itself, but for performance of the triple-tier system as a whole. What those assembly backends give us is the ability to run the LLInt using the same ABI that the JSC JITs use; this in turn allows us to do two things: (1) zero-cost OSR from the LLInt to the baseline JIT, and (2) perform every JS function call assuming opportunistically that the callee has been JITed; if it isn't then the machine code entrypoint that the callee reports is just the shared LLInt entrypoint. That entrypoint, in turn, doesn't really have to do anything special - it just loads the callee from the callee stack frame, loads the bytecode pointer from the callee, and indirect-jumps into the first bytecode instruction. We wouldn't be able to do either (1) or (2) easily with a C (or C++) interpreter. I mean, we could do it, but JIT-interpreter calls would be more expensive (because of the need to set up a C interpreter stack frame). And OSR would take more effort - it wouldn't be possible for the LLInt to just jump straight into JITed code like it does now. In summary, I don't expect the LLInt cloop backend to be any slower than the LLInt assembly backends. Last I checked, it wasn't slower. I would assume that a decent C compiler will take the LLInt cloop code and do sufficient optimizations that it ends up generating roughly the same assembly code that the LLInt assembly backends generate. So, I wouldn't devote too much effort to switching from the cloop to the assembly backends unless you had evidence that (a) it would actually be faster on the benchmarks you care about; or (b) you wanted to take advantage of the LLInt's ability to rapidly tier-up to one of the JSC JITs. It is because of (b), not (a), that JSC's triple tier configuration uses the LLInt assembly backends instead of cloop. But if you have reason to believe that the LLInt assembly backends will be better for your purposes then I think all it will take is hacking Platform.h appropriately. If this turns out to be hard, then you should file a bug, or even better, I would love to see a patch from you to improve the logic in Platform.h to make this use case easier. Hope this helps! -Filip On Mar 8, 2013, at 4:59 PM, Fritz Koenig frkoe...@google.com wrote: LowLevelInterpreter.asm is processed to create LLIntAssembly.h for the built platform. It appears that if there is no jitting configured[1], this will always create the C Loop. Is there any way of using the assembly backends to create LLIntAssembly.h when not jitting? [1]: Source/WTF/wtf/Platform.h:815 /* If the jit is not available, enable the LLInt C Loop: */ ___ 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
