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
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
On Mon, Feb 7, 2011 at 12:32 PM, Adam Barth 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
On Mon, Feb 7, 2011 at 12:18 PM, Silvio Ventres 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 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 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 >>> 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. >>> > >>> > 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. HTML/CSS/JS (text) from CDNs >>> > 3. 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@lis
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 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 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 >> 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. >> > >> > 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. HTML/CSS/JS (text) from CDNs >> > 3. 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 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 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 > 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. > > > > 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. HTML/CSS/JS (text) from CDNs > > 3. 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
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 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. > > 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. HTML/CSS/JS (text) from CDNs > 3. 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] Announcing a clutter port of WebKit
On Mon, Feb 7, 2011 at 9:08 AM, Gustavo Noronha Silva 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
[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. 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. HTML/CSS/JS (text) from CDNs 3. 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] Implementing the 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 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 b
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
[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 Collabora Ltd. ___ 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
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
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
