Re: [webkit-dev] More information for crashing tests now available on build.webkit.org
On Fri, Feb 04, 2011 at 02:25:10PM -0500, Adam Roben wrote: Hi all- [...] Please file any bugs you find with this feature on bugs.webkit.org, and CC me. Please also file bugs for any ideas you have for making this more useful! Nice, we have been running this crash service for the two gtk+ debug bots for some time now, it has stacks and core files, maybe it is a good idea if we could also integrate it the same way, if possible: http://webkit-bots.igalia.com/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] More information for crashing tests now available on build.webkit.org
On Feb 7, 2011, at 7:20 AM, Alejandro Garcia Castro wrote: On Fri, Feb 04, 2011 at 02:25:10PM -0500, Adam Roben wrote: Hi all- [...] Please file any bugs you find with this feature on bugs.webkit.org, and CC me. Please also file bugs for any ideas you have for making this more useful! Nice, we have been running this crash service for the two gtk+ debug bots for some time now, it has stacks and core files, maybe it is a good idea if we could also integrate it the same way, if possible: http://webkit-bots.igalia.com/ You can see how the Mac/Windows ports do it by looking at captureSavedCrashLog($) in old-run-webkit-tests. -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] precompiled headers
Hi, I'm working on a CMake based Windows port and have some problems with the precompiled headers. At the moment it's not possible to build the Windows port without them. Other ports don't require PCH. [1], [2] and [3] will make it work without PCH, but this patches raised up a general discussion about the PCH requirement. [4] says: The project should be able to build without this header, although we rarely test that. What does this mean? it should be possible to build the existing Mac and Windows ports without this prefix header, or it should be possible to construct a port that builds without this prefix header [5] says: ... This guarantees that each header's completeness is tested. This also assures that each header can be compiled without requiring any other header files be included first. Does header completeness include PCH? Should it be possible to build all ports without using precompiled headers? - Patrick [1] http://webkit.org/b/53881 [2] http://webkit.org/b/53883 [3] http://webkit.org/b/53885 [4] http://trac.webkit.org/browser/trunk/Source/WebCore/WebCorePrefix.h#L25 [5] http://webkit.org/coding/coding-style.html ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Announcing a clutter port of WebKit
Hey! I just finished pushing the current version of a new port of WebKit based on the Clutter library. Being also based on GObject it shares a lot of infrastructure with the GTK+ port - almost all of the public API is shared, much of the WebCore-WebKit glue code, GStreamer, Cairo and Soup backends. You can find it here: http://gitorious.org/webkit-clutter/webkit-clutter I have discussed this new port with the other WebKitGTK+ people during our hackfest, so they are aware of its existence for a bit now, though the code was not yet available. The work is being done on behalf of my employer Collabora. We are not yet going to upstream it because at this point in time we are still figuring out how long-term maintenance would work, and we are aware the WebKit project doesn't like ports that end up requiring lots of work and are then left bit-rotting in the tree (neither do we). As soon as we can figure this out, we'll let you know. For now I'd like to let anyone who might be interested in this work know it's publicly available =). Let me know of any questions! Cheers, -- Gustavo Noronha Silva gustavo.noro...@collabora.co.uk Collabora Ltd. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] precompiled headers
My understanding is that it is supposed to be possible to build all ports without PCH support. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Implementing the device element
Hi, On 2011-02-04 19:21, Leandro Graciá Gil wrote: This is good news! Especially for the situations where WebCore can't directly access the hardware. One existing case of this we should keep in mind are the sandboxed environments, where both the probing and the connections must be requested to somewhere outside the sandbox. Usually this will require to communicate with another process, and in this case asynchronous messages are preferred to avoid delays and to make inter-process communication simpler. However I have to disagree in one point. The specification doesn't say anywhere that we should always present a dialog, only that the device element represents a device selector. The UI has been a central part of the discussions that lead up to the device element proposal. The reason for that is that it should enforce security. See the thread UI for enabling webcam use from untrusted content: http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/0149.html especially http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/0194.html You're right that we shouldn't limit ourselves by referring to the device selector as a dialog. I've renamed ChromeClient::runDeviceDialog to runDeviceSelector and the corresponding client interface accordingly. Consider this completely valid use case: instead of asking repeatedly the user to select a device, a UA might decide to create some kind of internal device settings configuration panel to select a set of default devices. Later when visiting a page and clicking the device element the UA will automatically use the preferred devices from its internal settings if they are available and the page is trusted. Where is the dialog here? Couldn't you just see the internal device settings configuration panel, you mention, as the device selector that produces a device list that's reused several times? In that case you would skip the dialog and simply apply the predefined selections (similar to the case where a remember my choices check box would be available in the device dialog). I agree that the device should perform selection, as the spec says. However as I've already explained I don't think we need for example a selection dialog for all use cases. Considering that we don't explicitly need a dialog to perform the selection, the only reason to bring lists of available devices back to WebCore is to send them again to a client, probably the same one we asked for probing. Also, if we consider the possibility of sandboxed environments then the device connection operation cannot be a synchronous operation as commented before. As mentioned above, I see a point in sending the list of available devices to WebCore to determine if a new Stream (or other device handler) should be created since this behavior should be consistent across platforms, regardless if the device is of type media or fishtank. The device connection operation is not handled by the device element. The device element is used to simply select devices (similar to how you select a file with input type=file and get a File object which is just a handle to the actual file). The connection takes place when you use the device, e.g., when you play a Stream in a video element; and that will happen asynchronously. Reviewing the design with all these factors leaves us the following scheme: - Request device selection asynchronously to the client (not necessarily using a dialog). - Retrieve the available device list. - Forward the list to a client (probably the same that a moment ago probed the devices) to connect them. Do it asynchronously to keep compatibility with sandboxed environments. - Receive the connection request result and some device specific data. So, the available device lists are being sent back to the device element not for making any specific use of them, but for forwarding them to a connection client in an asynchronous model. Wouldn't it be simpler if we refactor the process in this way? - Request device selection asynchronously to a client. - Receive the connection request result and some device specific data. This is exactly what our model proposes. The same goal can be performed by handling connections to devices instead to actual device lists, especially when we're likely to give back the list to the same client that provided it to us. It also avoids any list handling code outside the clients and to implement an intermediate selection/connection element state. To make our proposal clearer, we have uploaded a patch with most of our WebCore implementation. It can be found here: https://bugs.webkit.org/show_bug.cgi?id=53777 This patch it's not intended to be reviewed (it's too big for that) but to serve as an implementation example of our proposed model. Our original plan was to upload it in small, easy to review pieces. This patch would be intended to be the second of them, after introducing
[webkit-dev] Question regarding priorities of subresource content retrieval
Hello. Can someone point where in the source code is the implementation of the subresources loading and some documentation regarding its implementation - as a queue or just child-threads or async functions? The reason is that the current subresource loading seems to lack any prioritization and it often occurs that some external 1x1 pixel tracker or other similarly unimportant page resources block the rendering of the page completely, and the user is left starting at contacting ads.doubleclick.com with a blank page. This is very frustrating as the page render as a whole then depends on the slowest part and cannot be possibly done faster by any optimizations in hardware or software on the part of the page owner. Thus, the proposition is this: 1. Render should only wait for the main HTML/CSS to load from the main page domain (a page in tumblr.com domain should wait for html/css files from *.tumblr.com, but not from *.doubleclick.com). 2. Other content load except HTML/CSS should be prioritized as follows, with placeholders shown until the load is complete - possibly adding one or more extra render passes, but increasing interactivity. So, basic priorities: 10 = Highest: HTML/CSS from main domain (sites.tumblr.com/some_site.html) 9: JS/XHR from main domain 8: HTML/CSS/JS from subdomains in the same domain (ads.tumblr.com/ad_serve.js) 7. Reserved for future use 6. IMG/media from main domain (sites.tubmlr.com/header.png) 5. IMG/media from subdomains in the same domain (ads.tubmlr.com/banner1.png) 4. Optional* HTML/CSS/JS (text) from CDNs 3. Optional* IMG/media from CDNs 2. HTML/CSS/JS from other domains (*.doubleclick.com/link_210986cv3.php?refer=2323424) 1=Lowest. IMG from other domains (*.doublclick.com/images/track_1x1.gif) *4 and 3 are optional and would need some kind of a whitelist of well-known CDN domains. This prioritization will reduce the latency between the page load start and a usable render, so even if some external-domain subresource is nonresponsive, interactivity will not suffer. Maybe the priorities should be moved to a user-controllable setting, where more fine-grained rules can be defined. Otherwise, maybe HTML standard can be extended to provide hints to the browser regarding the preferred subresource loading order, which should of course be user-overridable. Thank you for reading. This might be a big undertaking but the benefit for the user will be seen instantly. -- silvio ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Announcing a clutter port of WebKit
On Mon, Feb 7, 2011 at 9:08 AM, Gustavo Noronha Silva gustavo.noro...@collabora.co.uk wrote: You can find it here: http://gitorious.org/webkit-clutter/webkit-clutter In case anyone else is curious what is changed, you can do this in your WebKit git tree: $ git remote add clutter git://gitorious.org/webkit-clutter/webkit-clutter.git $ git fetch clutter $ git diff origin...clutter/master ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Question regarding priorities of subresource content retrieval
There is already some amount of code that's involved with prioritizing subresource loads. See http://trac.webkit.org/browser/trunk/Source/WebCore/loader/ResourceLoadScheduler.h and http://trac.webkit.org/browser/trunk/Source/WebCore/loader/cache/CachedResourceLoader.h. I suspect the prioritization algorithm could be improved. A good first step is to create a benchmark illustrating the performance issues and then write patches that optimize the benchmark. Please consider putting your performance test in http://trac.webkit.org/browser/trunk/PerformanceTests/ so that it's easy for others to work on as well. Adam On Mon, Feb 7, 2011 at 11:23 AM, Silvio Ventres silvio.vent...@gmail.com wrote: Hello. Can someone point where in the source code is the implementation of the subresources loading and some documentation regarding its implementation - as a queue or just child-threads or async functions? The reason is that the current subresource loading seems to lack any prioritization and it often occurs that some external 1x1 pixel tracker or other similarly unimportant page resources block the rendering of the page completely, and the user is left starting at contacting ads.doubleclick.com with a blank page. This is very frustrating as the page render as a whole then depends on the slowest part and cannot be possibly done faster by any optimizations in hardware or software on the part of the page owner. Thus, the proposition is this: 1. Render should only wait for the main HTML/CSS to load from the main page domain (a page in tumblr.com domain should wait for html/css files from *.tumblr.com, but not from *.doubleclick.com). 2. Other content load except HTML/CSS should be prioritized as follows, with placeholders shown until the load is complete - possibly adding one or more extra render passes, but increasing interactivity. So, basic priorities: 10 = Highest: HTML/CSS from main domain (sites.tumblr.com/some_site.html) 9: JS/XHR from main domain 8: HTML/CSS/JS from subdomains in the same domain (ads.tumblr.com/ad_serve.js) 7. Reserved for future use 6. IMG/media from main domain (sites.tubmlr.com/header.png) 5. IMG/media from subdomains in the same domain (ads.tubmlr.com/banner1.png) 4. Optional* HTML/CSS/JS (text) from CDNs 3. Optional* IMG/media from CDNs 2. HTML/CSS/JS from other domains (*.doubleclick.com/link_210986cv3.php?refer=2323424) 1=Lowest. IMG from other domains (*.doublclick.com/images/track_1x1.gif) *4 and 3 are optional and would need some kind of a whitelist of well-known CDN domains. This prioritization will reduce the latency between the page load start and a usable render, so even if some external-domain subresource is nonresponsive, interactivity will not suffer. Maybe the priorities should be moved to a user-controllable setting, where more fine-grained rules can be defined. Otherwise, maybe HTML standard can be extended to provide hints to the browser regarding the preferred subresource loading order, which should of course be user-overridable. Thank you for reading. This might be a big undertaking but the benefit for the user will be seen instantly. -- silvio ___ 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] Question regarding priorities of subresource content retrieval
The default prioritization is found here: http://trac.webkit.org/browser/trunk/Source/WebCore/loader/cache/CachedResource.cpp#L51. There are cases where we override this (e.g., I'm pretty sure we load favicons at a lower priority than other images) On Mon, Feb 7, 2011 at 11:44 AM, Adam Barth aba...@webkit.org wrote: There is already some amount of code that's involved with prioritizing subresource loads. See http://trac.webkit.org/browser/trunk/Source/WebCore/loader/ResourceLoadScheduler.h and http://trac.webkit.org/browser/trunk/Source/WebCore/loader/cache/CachedResourceLoader.h . I suspect the prioritization algorithm could be improved. A good first step is to create a benchmark illustrating the performance issues and then write patches that optimize the benchmark. Please consider putting your performance test in http://trac.webkit.org/browser/trunk/PerformanceTests/ so that it's easy for others to work on as well. Adam On Mon, Feb 7, 2011 at 11:23 AM, Silvio Ventres silvio.vent...@gmail.com wrote: Hello. Can someone point where in the source code is the implementation of the subresources loading and some documentation regarding its implementation - as a queue or just child-threads or async functions? The reason is that the current subresource loading seems to lack any prioritization and it often occurs that some external 1x1 pixel tracker or other similarly unimportant page resources block the rendering of the page completely, and the user is left starting at contacting ads.doubleclick.com with a blank page. This is very frustrating as the page render as a whole then depends on the slowest part and cannot be possibly done faster by any optimizations in hardware or software on the part of the page owner. Thus, the proposition is this: 1. Render should only wait for the main HTML/CSS to load from the main page domain (a page in tumblr.com domain should wait for html/css files from *.tumblr.com, but not from *.doubleclick.com). 2. Other content load except HTML/CSS should be prioritized as follows, with placeholders shown until the load is complete - possibly adding one or more extra render passes, but increasing interactivity. So, basic priorities: 10 = Highest: HTML/CSS from main domain ( sites.tumblr.com/some_site.html) 9: JS/XHR from main domain 8: HTML/CSS/JS from subdomains in the same domain ( ads.tumblr.com/ad_serve.js) 7. Reserved for future use 6. IMG/media from main domain (sites.tubmlr.com/header.png) 5. IMG/media from subdomains in the same domain ( ads.tubmlr.com/banner1.png) 4. Optional* HTML/CSS/JS (text) from CDNs 3. Optional* IMG/media from CDNs 2. HTML/CSS/JS from other domains (*.doubleclick.com/link_210986cv3.php?refer=2323424) 1=Lowest. IMG from other domains (*.doublclick.com/images/track_1x1.gif) *4 and 3 are optional and would need some kind of a whitelist of well-known CDN domains. This prioritization will reduce the latency between the page load start and a usable render, so even if some external-domain subresource is nonresponsive, interactivity will not suffer. Maybe the priorities should be moved to a user-controllable setting, where more fine-grained rules can be defined. Otherwise, maybe HTML standard can be extended to provide hints to the browser regarding the preferred subresource loading order, which should of course be user-overridable. Thank you for reading. This might be a big undertaking but the benefit for the user will be seen instantly. -- silvio ___ 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] Question regarding priorities of subresource content retrieval
The function doesn't seem to get any information regarding domain the resource is hosted at. Calling some kind of setResourceDomainType() to set DOMAIN_TYPE to enum(0=main domain, 1=subdomain within same domain, 2=CDN, 3=external domain) and then providing that as an additional parameter to defaultPriorityForResourceType() seems logical. Trying to see where this domain-sensing function can be called at earliest. Regarding the performance test, since it depends on multiple resources with highly differing latency, it would depend on an external resource. Does the PerformanceTest framework have some kind of latency simulator? Thanks for swift replies, btw! -- silvio On 2/7/11, Nate Chapin jap...@google.com wrote: The default prioritization is found here: http://trac.webkit.org/browser/trunk/Source/WebCore/loader/cache/CachedResource.cpp#L51. There are cases where we override this (e.g., I'm pretty sure we load favicons at a lower priority than other images) On Mon, Feb 7, 2011 at 11:44 AM, Adam Barth aba...@webkit.org wrote: There is already some amount of code that's involved with prioritizing subresource loads. See http://trac.webkit.org/browser/trunk/Source/WebCore/loader/ResourceLoadScheduler.h and http://trac.webkit.org/browser/trunk/Source/WebCore/loader/cache/CachedResourceLoader.h . I suspect the prioritization algorithm could be improved. A good first step is to create a benchmark illustrating the performance issues and then write patches that optimize the benchmark. Please consider putting your performance test in http://trac.webkit.org/browser/trunk/PerformanceTests/ so that it's easy for others to work on as well. Adam On Mon, Feb 7, 2011 at 11:23 AM, Silvio Ventres silvio.vent...@gmail.com wrote: Hello. Can someone point where in the source code is the implementation of the subresources loading and some documentation regarding its implementation - as a queue or just child-threads or async functions? The reason is that the current subresource loading seems to lack any prioritization and it often occurs that some external 1x1 pixel tracker or other similarly unimportant page resources block the rendering of the page completely, and the user is left starting at contacting ads.doubleclick.com with a blank page. This is very frustrating as the page render as a whole then depends on the slowest part and cannot be possibly done faster by any optimizations in hardware or software on the part of the page owner. Thus, the proposition is this: 1. Render should only wait for the main HTML/CSS to load from the main page domain (a page in tumblr.com domain should wait for html/css files from *.tumblr.com, but not from *.doubleclick.com). 2. Other content load except HTML/CSS should be prioritized as follows, with placeholders shown until the load is complete - possibly adding one or more extra render passes, but increasing interactivity. So, basic priorities: 10 = Highest: HTML/CSS from main domain ( sites.tumblr.com/some_site.html) 9: JS/XHR from main domain 8: HTML/CSS/JS from subdomains in the same domain ( ads.tumblr.com/ad_serve.js) 7. Reserved for future use 6. IMG/media from main domain (sites.tubmlr.com/header.png) 5. IMG/media from subdomains in the same domain ( ads.tubmlr.com/banner1.png) 4. Optional* HTML/CSS/JS (text) from CDNs 3. Optional* IMG/media from CDNs 2. HTML/CSS/JS from other domains (*.doubleclick.com/link_210986cv3.php?refer=2323424) 1=Lowest. IMG from other domains (*.doublclick.com/images/track_1x1.gif) *4 and 3 are optional and would need some kind of a whitelist of well-known CDN domains. This prioritization will reduce the latency between the page load start and a usable render, so even if some external-domain subresource is nonresponsive, interactivity will not suffer. Maybe the priorities should be moved to a user-controllable setting, where more fine-grained rules can be defined. Otherwise, maybe HTML standard can be extended to provide hints to the browser regarding the preferred subresource loading order, which should of course be user-overridable. Thank you for reading. This might be a big undertaking but the benefit for the user will be seen instantly. -- silvio ___ 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] Question regarding priorities of subresource content retrieval
On Mon, Feb 7, 2011 at 12:18 PM, Silvio Ventres silvio.vent...@gmail.com wrote: The function doesn't seem to get any information regarding domain the resource is hosted at. Calling some kind of setResourceDomainType() to set DOMAIN_TYPE to enum(0=main domain, 1=subdomain within same domain, 2=CDN, 3=external domain) and then providing that as an additional parameter to defaultPriorityForResourceType() seems logical. Trying to see where this domain-sensing function can be called at earliest. Regarding the performance test, since it depends on multiple resources with highly differing latency, it would depend on an external resource. Does the PerformanceTest framework have some kind of latency simulator? There is no PerformanceTest framework that deals with network latency. Please feel encouraged to build one. :) Adam On 2/7/11, Nate Chapin jap...@google.com wrote: The default prioritization is found here: http://trac.webkit.org/browser/trunk/Source/WebCore/loader/cache/CachedResource.cpp#L51. There are cases where we override this (e.g., I'm pretty sure we load favicons at a lower priority than other images) On Mon, Feb 7, 2011 at 11:44 AM, Adam Barth aba...@webkit.org wrote: There is already some amount of code that's involved with prioritizing subresource loads. See http://trac.webkit.org/browser/trunk/Source/WebCore/loader/ResourceLoadScheduler.h and http://trac.webkit.org/browser/trunk/Source/WebCore/loader/cache/CachedResourceLoader.h . I suspect the prioritization algorithm could be improved. A good first step is to create a benchmark illustrating the performance issues and then write patches that optimize the benchmark. Please consider putting your performance test in http://trac.webkit.org/browser/trunk/PerformanceTests/ so that it's easy for others to work on as well. Adam On Mon, Feb 7, 2011 at 11:23 AM, Silvio Ventres silvio.vent...@gmail.com wrote: Hello. Can someone point where in the source code is the implementation of the subresources loading and some documentation regarding its implementation - as a queue or just child-threads or async functions? The reason is that the current subresource loading seems to lack any prioritization and it often occurs that some external 1x1 pixel tracker or other similarly unimportant page resources block the rendering of the page completely, and the user is left starting at contacting ads.doubleclick.com with a blank page. This is very frustrating as the page render as a whole then depends on the slowest part and cannot be possibly done faster by any optimizations in hardware or software on the part of the page owner. Thus, the proposition is this: 1. Render should only wait for the main HTML/CSS to load from the main page domain (a page in tumblr.com domain should wait for html/css files from *.tumblr.com, but not from *.doubleclick.com). 2. Other content load except HTML/CSS should be prioritized as follows, with placeholders shown until the load is complete - possibly adding one or more extra render passes, but increasing interactivity. So, basic priorities: 10 = Highest: HTML/CSS from main domain ( sites.tumblr.com/some_site.html) 9: JS/XHR from main domain 8: HTML/CSS/JS from subdomains in the same domain ( ads.tumblr.com/ad_serve.js) 7. Reserved for future use 6. IMG/media from main domain (sites.tubmlr.com/header.png) 5. IMG/media from subdomains in the same domain ( ads.tubmlr.com/banner1.png) 4. Optional* HTML/CSS/JS (text) from CDNs 3. Optional* IMG/media from CDNs 2. HTML/CSS/JS from other domains (*.doubleclick.com/link_210986cv3.php?refer=2323424) 1=Lowest. IMG from other domains (*.doublclick.com/images/track_1x1.gif) *4 and 3 are optional and would need some kind of a whitelist of well-known CDN domains. This prioritization will reduce the latency between the page load start and a usable render, so even if some external-domain subresource is nonresponsive, interactivity will not suffer. Maybe the priorities should be moved to a user-controllable setting, where more fine-grained rules can be defined. Otherwise, maybe HTML standard can be extended to provide hints to the browser regarding the preferred subresource loading order, which should of course be user-overridable. Thank you for reading. This might be a big undertaking but the benefit for the user will be seen instantly. -- silvio ___ 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] Question regarding priorities of subresource content retrieval
On Mon, Feb 7, 2011 at 12:32 PM, Adam Barth aba...@webkit.org wrote: There is no PerformanceTest framework that deals with network latency. Please feel encouraged to build one. :) Note that http://code.google.com/p/web-page-replay/ was created with this goal (to simulate realistic network behavior). http://calendar.perfplanet.com/2010/benchmark-the-network/ has a few more details, and Tony Gentilcore (one of its authors) is on this list. Mihai ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Question regarding priorities of subresource content retrieval
IE/Opera are delaying only for 4 seconds, same as Mobile Safari The reason looks to be the url for the script/css. If the url is the same twice, Chrome/Firefox serializes the requests, while IE/Opera/MobileSafari launches both requests simultaneously. Of course, requesting simultaneously doesn't fix anything, as you can see by trying a link-stuffed version at http://solid.eqoppa.com/testlag2.html This one has 45 css and 38 javascript links. It hangs all browsers nicely. The main point here is that it might be acceptable if it's coming from the webpage domain itself. But the links are coming from a completely different place. This is exactly what makes browsing pages with any third-party analytics, tracking or ad addons so slow and frustrating. Fixing priorities in subresource download should make experience considerably more interactive and fun. -- silvio ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Question regarding priorities of subresource content retrieval
I'm reasonably sure that javascript in the header must be loaded synchronously, as it might affect the rest of the load. This is why tools like YSlow advise Web designers to move javascript loads that are not needed for rendering until after the rest of the page loads. Blocking on loading the css is less clear-cut, as in some cases it could mean several seconds of ugly page. I don't know if it's right or wrong, but a lot of pages out there rely on the CSS being loaded before the page starts to render to avoid terrible layout and the appearance of items meant to be hidden for the seconds it takes the css to load. In general, while things could certainly be improved, it's up to the owner of the page to not rely on a a slow ad server, or build the page so the ads load after the primary content. Jerry Seeger On Feb 7, 2011, at 5:47 PM, Silvio Ventres wrote: IE/Opera are delaying only for 4 seconds, same as Mobile Safari The reason looks to be the url for the script/css. If the url is the same twice, Chrome/Firefox serializes the requests, while IE/Opera/MobileSafari launches both requests simultaneously. Of course, requesting simultaneously doesn't fix anything, as you can see by trying a link-stuffed version at http://solid.eqoppa.com/testlag2.html This one has 45 css and 38 javascript links. It hangs all browsers nicely. The main point here is that it might be acceptable if it's coming from the webpage domain itself. But the links are coming from a completely different place. This is exactly what makes browsing pages with any third-party analytics, tracking or ad addons so slow and frustrating. Fixing priorities in subresource download should make experience considerably more interactive and fun. -- silvio ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
