Re: [webkit-dev] Making browsers faster: Resource Packages
On Tue, Nov 17, 2009 at 9:58 PM, Steve Souders st...@souders.org wrote: I like the option of putting the manifest in the HTML. That was the main suggestion I was going to make. You don't *have* to do it, but if you really care about performance you could choose to do it. James mentions: The page-specific resources end up getting blocked behind all of the manifest downloads. I would expect that if I have: script src=a.js/script script src=b.js/script link rel=resource-package type=application/zip href=site-resources.zip / The browser should start downloading a.js and b.js before site-resources.zip. Therefore, as a developer, if I have page-specific resources, I have some ability to get those downloading before the manifest-blocking issue of resource packages. I'm not totally clear on how this works today, so this might be groundless, but doesn't this present a potential problem? a.js gets included early in the page, the browser finishes loading it, it starts getting used, and then the browser encounters a resource bundle that contains a different a.js. I can also imagine scripts doing a document.write that adds a link to a resource bundle, causing similar potential issues with various already-loaded resources. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] jit for arm
From http://lists.webkit.org/: ListDescription webkit-help [no description available] Hmmm, yes, there would seem to be some scope to make that a little more descriptive! ;-) G. On Nov 17, 2009, at 11:46 PM, Zoltan Herczeg wrote: Hi, seems the original mail was sent to both webkit-dev and webkit-help. My reply was on webkit-help, and the discussion continued there. https://lists.webkit.org/pipermail/webkit-help/2009-November/000380.html Perhaps we should clarify better the purpose of these mailing lists, since if people can't decide which list is better for them, they do double posts. Zoltan On Nov 4, 2009, at 8:37 AM, ll Jefferry wrote: Hi, when i reading the jit for arm source code, i am not very clear the functionality of the flowing functions: ctiTrampoline This code is used when entering from the C runtime into JIT generated code. JIT generated code does not necessarily respect C calling conventions, so this routine sets up the stack frame, preserves registers, etc, as necessary to allow the JIT code to be run. ctiVMThrowTrampoline To perform certain operations the JIT will call back into C code. Usually the C callback can just return in a perfectly normal fashion and continue execution once it has completed, however in the case that an exception is thrown special handling is required to change the control flow. The return address of the C callback is instead changed to point to this, and this piece of code handles looking up the exception handler at which execution will be resumed. ctiOpThrowNotCaught This is used to from within cti_op_throw, which implements the 'throw' keyword in JavaScript. The cti_op_throw method will attempt to look up a handler routine that catches the exception. However if the exception is not caught it is necessary to force an early termination of JIT execution. The cti_op_throw C callback always modifies its return address, either to point to the code for the appropriate exception handler to catch the exception, or to ctiOpThrowNotCaught if no handler is found. could you explain to me? and another question is that: in cacheFlush function, why the system call number is 0xf0002? if it is defined by the toolchain? Zoltan, Gabor? thanks! BR, Jeff ___ 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] Staging WebSocket protocol deployment
I think 3 sounds best. 4 seems reasonable. If we need to go with 1 or 2, we should talk to Mozilla to decide whether to standardize on the x or use our own prefixes. If we go with option 3, I think a WebKit blog post would be a good way to make out intentions for WebSockets clear. On Wed, Nov 18, 2009 at 4:38 AM, Fumitoshi Ukai (鵜飼文敏) u...@chromium.orgwrote: On Wed, Nov 18, 2009 at 6:08 AM, Maciej Stachowiak m...@apple.com wrote: On Nov 15, 2009, at 5:18 PM, Yuzo Fujishima wrote: Hi, I'm against prefixing with webkit- because of the following reasons. Reason 1: It connotes that the feature is experimental. That means there will be less developers seriously use that feature. Without serious use, we'll have less serious feedbacks from the real world. If the Web Socket has serious flaws, we should rather know them sooner than later. I'd say only serious uses can help us find the flaws faster. I think this captures the root of the disagreement. Personally, I would like to do something to send the message that WebSocket is still somewhat experimental. It's true that the spec has been in development for a long time. But we are only now seeing the first client-side and server-side implementations. A number of issues were discovered in that process, and I'd personally like to see some more experimental implementations before we lose the ability to make incompatible changes. See below for some specific suggestions. Reason 2: What should other browser vendors do? Should they use chrome-ws, firefox-ws, ie-ws, opera-ws, ..., etc? I believe at least developers will not happy with that. If the vendors need to reach the consensus on the common experimental name, say prelim-ws, then why not just use ws instead? Historically, we haven't had a problem with WebKit-prefixed features - it seems that other browser vendors implement under their own prefix and content adapts to deal. Anyway, getting back to the suggestions... I think it's reasonable at this point to indicate that the WebSocket protocol is somewhat experimental (probably more so than the API). I will recommend doing something along those lines for the next release of Safari. If we can get rough consensus within the WebKit community that we should label the protocol experimental, and how we should do so, then we can just make the change in WebKit and vendor releases will follow along. Here is an extended list of ideas (ones that I think are practically doable): 1) Change the URI schemes to webkit-ws and webkit-wss - the vendor prefix strategy. 2) Change the URI schemes to x-ws and x-wss - a vendor-independent experimental prefix. 3) Don't change the URI schemes at all, but communicate in some public way that the protocol is not completely locked down yet, and we are largely looking for early adopter feedback. We could do this in the form of a WebKit blog post, for example. And we could reinforce that in developer documentation for WebKit-based products. 4) Support both unprefixed and prefixed URI schemes, and in addition publicize that we will maintain compatibility for the prefixed URI scheme but the unprefixed version may have to change (combo of 3 and either 1 or 2). 5) Make the feature runtime switchable (using some semi-hidden UI) and off by default. I'd like to hear opinions on which of these is best. I vote option (3). Even if we keep current protocol stack with prefixed URI, I'm wondering any websocket server implementation will keep compatibility with procotol of our prefixed URI.. Or, if some websocket server implementation keeps compatible with prefixed URI, I believe it's worse situation for future. -- ukai I'd also like to hear if anyone feels that we should send the message that the WebSocket Protocol is production quality and we promise full compatibility going forward. Does anyone truly feel this way? 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] Making browsers faster: Resource Packages
Alexander Limi wrote: Good people of Webkit! We'd all like for the web to be faster, and therefore I'd love your feedback on my proposal — it would be great to see support for this in additional browsers, not just Firefox: http://limi.net/articles/resource-packages/ Summary: What if there was a backwards compatible way to transfer all of the resources that are used on every single page in your site — CSS, JS, images, anything else — in a single HTTP request at the start of the first visit to the page? This is what Resource Package support in browsers will let you do. Looking forward to hear your thoughts on this. I happened to open a bug on this, early this morning: https://bugs.webkit.org/show_bug.cgi?id=31621 WebKit already supports something similiar - webarchive's. Main difference being that webarchives contain the main resource as well as the sub-resources. Perhaps some of the same machinery can be reused there though. Though ... makes me wonder ... why not have a mode of supporting the main resource as well? Go from two downloads down to one. You'd just need a convention for specifying the main resource in the .zip file ... -- Patrick Mueller - http://muellerware.org ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit on the server side
Sergiy Temnikov wrote: Hi, We are working on a new application server that uses WebKit for server-side JavaScript execution (and remote JavaScript debugging too). ... For example, the first thing we had to deal with is the JS debugger. Debugger interface is defined in JavaScriptCore but its implementation lives in WebCore. Most of the debugger's implementation is abstract except for the part which sends event notifications to pages and frames objects which are GUI dependent and so can not be used in a faceless server application. So we basically copied the source of the existing debugger, commented out GUI related calls and added some stuff to transform it into a debugger which can be controlled remotely over the network. I would be happy to contribute to the WebKit project to add a layer of abstraction to the existing debugger implementation to cut its dependence on GUI and move it to JavaScriptCore from WebCore's inspector. It would be interesting to see this. Open a bug and contribute a patch. There's two reasons I think this is interesting: - would be useful for embedded clients. For instance, if this is the current state-of-the-art for debugging Palm's WebOS apps, which are (in my understanding) running in WebKit - http://is.gd/4RKuh - then a remote debug interface would be incredibly useful, assuming you had a nice client. - just cleaning up the interfaces between the debugger and debugging clients to begin with would probably be useful. -- Patrick Mueller - http://muellerware.org ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Made a debug build of WebKit.Framework. GDB ignores breakpoints?
Hi guys, I recently found a potential bug in WebKit: https://bugs.webkit.org/show_bug.cgi?id=31607 https://bugs.webkit.org/show_bug.cgi?id=31607 It's fairly crucial for me that this feature should work as advocated (or that there is at least a possible workaround for it), so I thought I'd take a shot a finding the bug myself. I've checked out the most recent WebKit sources, and made a debug build. I then linked my program against the resulting WebKit.Framework, and used the headers in the corresponding WebKit.Framework/Headers directory. I can now set breakpoints in my own code, and then do a stack trace to see which WebKit source file I came from. Problem is, next I tried setting breakpoints in these source files, but these seem to be completely ignored by GDB altogether. It stops execution just fine on the breakpoints in my own source file, just not on those in the WebKit source files (even though these functions are part of the stack trace, and are therefore definitely being called). Without any way of setting breakpoints in the WebKit source code I have no realistic hope of ever finding the problem myself, so I hope you guys can help me out here. Is there anything obvious that I'm doing wrong here? I'm fairly new at debugging external libraries, so maybe I am overlooking something. Cheers, Eddy ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] descriptions of mailing lists
On Nov 18, 2009, at 12:40 AM, Gavin Barraclough wrote: From http://lists.webkit.org/: ListDescription webkit-help [no description available] Hmmm, yes, there would seem to be some scope to make that a little more descriptive! ;-) http://webkit.org/contact.html describes the lists. webkit-help is for requests for help with building webkit, using WebKit's APIs, embedding WebKit, porting WebKit, and so forth. webkit-dev is for discussion of WebKit development. We should get those same descriptions visible at lists.webkit.org, and, I suppose, get more strict about sending people to webkit-help instead of webkit-dev when they arrive in the wrong place. And refine those descriptions if they are not specific enough. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] normalizing namespace indenting
16.11.2009, в 19:54, Chris Jerdonek написал(а): Second, do people prefer nested namespace blocks to end with the fully-qualified name (e.g. // namespace JSC::WREC) or just the final name (e.g. // namespace WREC)? I have seen both. I actually prefer no comment after the namespace ending brace. If I have any concerns about namespaces not being properly closed, I won't believe the comment anyway, and will check by double-clicking on the closing brace to select the block. And if I trust that the namespace structure is correct, then it's just visual noise. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] normalizing namespace indenting
On Nov 18, 2009, at 10:03 AM, Alexey Proskuryakov wrote: I actually prefer no comment after the namespace ending brace. If I have any concerns about namespaces not being properly closed, I won't believe the comment anyway, and will check by double-clicking on the closing brace to select the block. And if I trust that the namespace structure is correct, then it's just visual noise. I agree with Alexey on this point. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Made a debug build of WebKit.Framework. GDB ignores breakpoints?
18.11.2009, в 9:06, Eddy Bruël написал(а): I've checked out the most recent WebKit sources, and made a debug build. I then linked my program against the resulting WebKit.Framework, and used the headers in the corresponding WebKit.Framework/Headers directory Did you try the steps in http://webkit.org/building/debug.html? There is no need to rebuild your application against a local WebKit build. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] how to run mozilla test cases one by one using JSC
I had to do this same thing as I didn't have perl on our platform. I found modifying the perl script to output just the commands instead of actually running them was helpful. I could then just grab this output and run it wherever. Regards, Jason. -Original Message- From: webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of Oliver Hunt Sent: Tuesday, November 17, 2009 3:47 PM To: ll Jefferry Cc: WebKit Development Subject: Re: [webkit-dev] how to run mozilla test cases one by one using JSC You should simply copy the entire command line you see in the run-javascriptcore-tests output, eg. /path/to/jsc -s -f ./ecma/shell.js -f ./ecma/Date/15.9.5.17.js --Oliver On Nov 6, 2009, at 12:14 AM, ll Jefferry wrote: Hi, I bring up webkit with jit on my stb box. I want to test the jit if it is fine. When i run the mozilla test cases, i found that it need the perl tools. But my platform has not the perl environment, my question is that: can i run the test cases one by one under shell environment? such us ./jsc -f .js and can you tell me how to do this? when i run ./jsc -f ./emac/array/15-4.1.js, it always exit with code 3. That means it get error. BR, Jeff ___ 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] Making browsers faster: Resource Packages
On Tue, Nov 17, 2009 at 5:56 PM, Alexander Limi l...@mozilla.com wrote: On Tue, Nov 17, 2009 at 5:53 PM, James Robinson jam...@google.com wrote: Yes, actual numbers would be nice to have. Steve Souders just emailed me some preliminary numbers from a bunch of major web sites, so that should be on his blog shortly. Numbers are up: http://www.stevesouders.com/blog/2009/11/18/fewer-requests-through-resource-packages/ -- Alexander Limi · Firefox User Experience · http://limi.net ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Making browsers faster: Resource Packages
Overall, I think the general idea. I'm concerned about the head-of-line blocking that it introduces. If an administrator poorly constructs the bundle, he could significantly hurt perf. Instead of using gzip, you could use a framer which chunked items before gzipping. This might be more trouble than it is worth. Inside the browser, the caching is going to be kind of annoying. Example: Say foo.zip contains foo.gif and baz.gif, and foo.zip expires in one week. When the browser downloads the manifest, it needs to unfold it and store foo.gif and baz.gif in the cache. Then, a week later, if the browser tries to use foo.gif, it will be expired; does the browser fetch foo.zip? or just foo.gif? Obviously, either will work. But now you've got an inconsistent cache. If you hit another page which references foo.zip next, you'll download the whole zip file when all you needed was bar.gif. This is probably a minor problem - I can't see this being very significant in practice. Did you consider having the resources for a bundle be addressed such as: http://www.foo.com/bundle.zip/foo.gif ? This would eliminate the problem of two names for the same resource. Maybe this was your intent - the spec was unclear about the identity (URL) of the bundled resources. I think it is a good enough idea to warrant an implementation. Once we have data about performance, it will be clear whether this should be made official or not. Mike On Wed, Nov 18, 2009 at 11:56 AM, Alexander Limi l...@mozilla.com wrote: On Tue, Nov 17, 2009 at 5:56 PM, Alexander Limi l...@mozilla.com wrote: On Tue, Nov 17, 2009 at 5:53 PM, James Robinson jam...@google.comwrote: Yes, actual numbers would be nice to have. Steve Souders just emailed me some preliminary numbers from a bunch of major web sites, so that should be on his blog shortly. Numbers are up: http://www.stevesouders.com/blog/2009/11/18/fewer-requests-through-resource-packages/ -- Alexander Limi · Firefox User Experience · http://limi.net ___ 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] Making browsers faster: Resource Packages
On Wed, Nov 18, 2009 at 2:47 PM, Mike Belshe m...@belshe.com wrote: Overall, I think the general idea. I meant to say Overall I like the general idea I'm concerned about the head-of-line blocking that it introduces. If an administrator poorly constructs the bundle, he could significantly hurt perf. Instead of using gzip, you could use a framer which chunked items before gzipping. This might be more trouble than it is worth. Inside the browser, the caching is going to be kind of annoying. Example: Say foo.zip contains foo.gif and baz.gif, and foo.zip expires in one week. When the browser downloads the manifest, it needs to unfold it and store foo.gif and baz.gif in the cache. Then, a week later, if the browser tries to use foo.gif, it will be expired; does the browser fetch foo.zip? or just foo.gif? Obviously, either will work. But now you've got an inconsistent cache. If you hit another page which references foo.zip next, you'll download the whole zip file when all you needed was bar.gif. This is probably a minor problem - I can't see this being very significant in practice. Did you consider having the resources for a bundle be addressed such as: http://www.foo.com/bundle.zip/foo.gif ? This would eliminate the problem of two names for the same resource. Maybe this was your intent - the spec was unclear about the identity (URL) of the bundled resources. I think it is a good enough idea to warrant an implementation. Once we have data about performance, it will be clear whether this should be made official or not. Mike On Wed, Nov 18, 2009 at 11:56 AM, Alexander Limi l...@mozilla.com wrote: On Tue, Nov 17, 2009 at 5:56 PM, Alexander Limi l...@mozilla.com wrote: On Tue, Nov 17, 2009 at 5:53 PM, James Robinson jam...@google.comwrote: Yes, actual numbers would be nice to have. Steve Souders just emailed me some preliminary numbers from a bunch of major web sites, so that should be on his blog shortly. Numbers are up: http://www.stevesouders.com/blog/2009/11/18/fewer-requests-through-resource-packages/ -- Alexander Limi · Firefox User Experience · http://limi.net ___ 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] Making browsers faster: Resource Packages
Cool, thanks for the feedback. It does seem like most people (well, outside of this list ;) like the direction a lot. The one issue that I agree with, and would like to find an elegant solution to, is how to specify the manifest in the HTML instead of in the zip file to reduce blocking and start parsing earlier. I can't say that I know enough about HTML specifics to have an immediately useful answer here, I assume the link tag can't have content inside of it that could serve as the manifest? -- Alexander Limi · Firefox User Experience · http://limi.net On Wed, Nov 18, 2009 at 2:47 PM, Mike Belshe m...@belshe.com wrote: Overall, I think the general idea. I'm concerned about the head-of-line blocking that it introduces. If an administrator poorly constructs the bundle, he could significantly hurt perf. Instead of using gzip, you could use a framer which chunked items before gzipping. This might be more trouble than it is worth. Inside the browser, the caching is going to be kind of annoying. Example: Say foo.zip contains foo.gif and baz.gif, and foo.zip expires in one week. When the browser downloads the manifest, it needs to unfold it and store foo.gif and baz.gif in the cache. Then, a week later, if the browser tries to use foo.gif, it will be expired; does the browser fetch foo.zip? or just foo.gif? Obviously, either will work. But now you've got an inconsistent cache. If you hit another page which references foo.zip next, you'll download the whole zip file when all you needed was bar.gif. This is probably a minor problem - I can't see this being very significant in practice. Did you consider having the resources for a bundle be addressed such as: http://www.foo.com/bundle.zip/foo.gif ? This would eliminate the problem of two names for the same resource. Maybe this was your intent - the spec was unclear about the identity (URL) of the bundled resources. I think it is a good enough idea to warrant an implementation. Once we have data about performance, it will be clear whether this should be made official or not. Mike On Wed, Nov 18, 2009 at 11:56 AM, Alexander Limi l...@mozilla.com wrote: On Tue, Nov 17, 2009 at 5:56 PM, Alexander Limi l...@mozilla.com wrote: On Tue, Nov 17, 2009 at 5:53 PM, James Robinson jam...@google.comwrote: Yes, actual numbers would be nice to have. Steve Souders just emailed me some preliminary numbers from a bunch of major web sites, so that should be on his blog shortly. Numbers are up: http://www.stevesouders.com/blog/2009/11/18/fewer-requests-through-resource-packages/ -- Alexander Limi · Firefox User Experience · http://limi.net ___ 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] Making browsers faster: Resource Packages
Hi All, As a game developer with interests in mobile, I'd like to say overall, I think the idea sucks. Incorrectly implemented clients will end up downloading large resources multiple times, and web masters are sure to start adding every resource to pages that don't need them. As I see it, the load time issue only occurs on first load anyway, as properly implemented clients and servers should use cache directives to avoid unnecessary connections. If the first load case is a major concern (as in mobile), web masters should optimise their pages so that resources are amalgamated wherever possible. If you truly want better interactive performance from websites, add a streaming connectionless facility atop UDP, rather than complicating matters with an ad-hoc application level HTML hack. Regards, Steve 2009/11/18 Mike Belshe m...@belshe.com On Wed, Nov 18, 2009 at 2:47 PM, Mike Belshe m...@belshe.com wrote: Overall, I think the general idea. I meant to say Overall I like the general idea I'm concerned about the head-of-line blocking that it introduces. If an administrator poorly constructs the bundle, he could significantly hurt perf. Instead of using gzip, you could use a framer which chunked items before gzipping. This might be more trouble than it is worth. Inside the browser, the caching is going to be kind of annoying. Example: Say foo.zip contains foo.gif and baz.gif, and foo.zip expires in one week. When the browser downloads the manifest, it needs to unfold it and store foo.gif and baz.gif in the cache. Then, a week later, if the browser tries to use foo.gif, it will be expired; does the browser fetch foo.zip? or just foo.gif? Obviously, either will work. But now you've got an inconsistent cache. If you hit another page which references foo.zip next, you'll download the whole zip file when all you needed was bar.gif. This is probably a minor problem - I can't see this being very significant in practice. Did you consider having the resources for a bundle be addressed such as: http://www.foo.com/bundle.zip/foo.gif ? This would eliminate the problem of two names for the same resource. Maybe this was your intent - the spec was unclear about the identity (URL) of the bundled resources. I think it is a good enough idea to warrant an implementation. Once we have data about performance, it will be clear whether this should be made official or not. Mike On Wed, Nov 18, 2009 at 11:56 AM, Alexander Limi l...@mozilla.comwrote: On Tue, Nov 17, 2009 at 5:56 PM, Alexander Limi l...@mozilla.comwrote: On Tue, Nov 17, 2009 at 5:53 PM, James Robinson jam...@google.comwrote: Yes, actual numbers would be nice to have. Steve Souders just emailed me some preliminary numbers from a bunch of major web sites, so that should be on his blog shortly. Numbers are up: http://www.stevesouders.com/blog/2009/11/18/fewer-requests-through-resource-packages/ -- Alexander Limi · Firefox User Experience · http://limi.net ___ 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 -- Steve Tickle sixteenk - Refined software development for mobile and web t: +44 151 324 2816 m: +44 7950 052 976 w: sixteenk.com ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Making browsers faster: Resource Packages
On Wed, Nov 18, 2009 at 3:54 PM, Dirk Pranke dpra...@chromium.org wrote: Another caching-related issue involves versioning of the archives. If version 2 of a zip contains only a few files modified since version 1, and I have version 1 cached, is there some way to take advantage of that? This is a specific case of my more general question, One of your stated goals is to avoid downloading resources you already have, but even with manifests, I see no way to do this, since the client can't actually tell the server 'only send items x, y, and z'. This was the one point Alexander didn't copy in his reply mail. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] normalizing namespace indenting
On Tue, Nov 17, 2009 at 10:39 PM, Darin Adler da...@apple.com wrote:
On Nov 16, 2009, at 7:54 PM, Chris Jerdonek wrote:
So, I was wondering if we can clarify the rule to apply only to the
outermost namespace declaration.
Yes, I think we can.
(Consecutive declarations like namespace JSC { namespace WREC { would be
treated as a single declaration for the purpose of this rule.)
Neat idea, I think.
Thanks. The idea stems from a syntactic sugar for using blocks in
C# (different meaning of using from C++). Instead of doing this--
using (Resource resource1 = new Resource())
{
using (Resource resource2 = new Resource())
{
...
}
}
You can do this:
using (Resource resource1 = new Resource())
using (Resource resource2 = new Resource())
{
...
}
--Chris
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] function RecordSpan() in JavaScriptCore/wtf/FastMalloc.cpp
Hi all, I am using WebKit-r51075, the lastest WebKit version. now the question: 1, line 1354 of RecordSpan() in JavaScriptCore/wtf/FastMalloc.cpp : if (span-length 1) 2, span-length is type uintptr_t, while 1 is int, are there any error potentials for this compare? 3, I run GtkLauncher on my embedded linux platform and got signal SIGBUS here 4, the error comes from byte-padding mostly, so, would the expression bring such issue here? 5, if it is, how to fix then? Thanks in Advance, Tony Wang ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
