[webkit-dev] Performing paint events last (blocking paint events)
I would like to modify the webkit source so that the the downloading of a webpage occurs first and only when all content has been downloading will webkit then paint the nodes in the dom tree. I have looked into the source and have seen the code WebViewCore.removeMessages(WebView.EventHub.WebKit_Draw) that blocks pending draw events from occurring. I was wondering if anybody could shed some light on whether this would work. -- View this message in context: http://mac-os-forge.2317878.n4.nabble.com/Performing-paint-events-last-blocking-paint-events-tp194652.html Sent from the Webkit mailing list archive at Nabble.com. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] SH4, MIPS, and legacy-ARM assemblers in JavaScriptCore
Hi, Just wanted to note, that there is a working MIPS buildslave again: http://build.webkit.org/buildslaves/mips-1 It only does builds, no tests yet, we are working on that. Thank you everyone for your help! Unfortunately, the MIPS build is still red, because the following patch was not yet accepted to trunk (we bounced off of the commit bot the first time because the patch was malformed, but the current one should be fine now): https://bugs.webkit.org/show_bug.cgi?id=97243 We also have a MIPS DFG and LLINT implementation which passes the JSC testsuite and common benchmark suits (sunspider, v8). We are working on cleaning them up for submission. Best Regards, Gergely On Fri, Sep 14, 2012 at 3:01 AM, Gergely Kis gerg...@homejinni.com wrote: Hi, Submitted the patch for enabling the MIPS slave in build.webkit.org. https://bugs.webkit.org/show_bug.cgi?id=96713 Who should I send the buildbot password for the slave? Thanks, Gergely On Thu, Aug 30, 2012 at 9:52 AM, Holger Freyther ze...@selfish.orgwrote: On 08/30/2012 12:10 AM, Gergely Kis wrote: Would this be acceptable for you? sure, an actively and publicly maintained MIPS build would be great. We have some documentation on how to setup a build slave in the wiki[1] and the slave configuration files are maintained in SVN[2]. The configuration file changes follow the normal WebKit contribution procedure. holger [1] http://trac.webkit.org/wiki/BuildBot [2] http://trac.webkit.org/browser/trunk/Tools/BuildSlaveSupport/build.webkit.org-config ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] New Feature: Canvas Path object
On Sep 22, 2012, at 9:21 PM, Elliott Sprehn espr...@chromium.org wrote: On Fri, Sep 21, 2012 at 6:34 AM, Dirk Schulze dschu...@adobe.com wrote: I would like to ask if there are objections to implement the canvas Path object. Do we have metrics on how often people already have things named Path? All other canvas objects have a prefix like CanvasGradient and CanvasPattern, this thing seems inconsistent and more likely to break existing pages. Dirk, given the fact that you quite logically referred to this as “the canvas Path object” when mentioning it to us, and the fact that both CanvasGradient and CanvasPattern objects exist, CanvasPath sure does seem like a nice name for this. Someone should make that suggestion on the WebApps mailing list! -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] New Feature: Canvas Path object
On Mon, Sep 24, 2012 at 10:27 AM, Darin Adler da...@apple.com wrote: On Sep 22, 2012, at 9:21 PM, Elliott Sprehn espr...@chromium.org wrote: On Fri, Sep 21, 2012 at 6:34 AM, Dirk Schulze dschu...@adobe.com wrote: I would like to ask if there are objections to implement the canvas Path object. Do we have metrics on how often people already have things named Path? All other canvas objects have a prefix like CanvasGradient and CanvasPattern, this thing seems inconsistent and more likely to break existing pages. Dirk, given the fact that you quite logically referred to this as “the canvas Path object” when mentioning it to us, and the fact that both CanvasGradient and CanvasPattern objects exist, CanvasPath sure does seem like a nice name for this. Someone should make that suggestion on the WebApps mailing list! A difference though is that the path object doesn't have to be associated with a canvas. It is/will be useful with other features such as SVG as well. I feel uneasy with the generic name too; maybe a DOM/HTML/JS prefix is better. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] New Feature: Canvas Path object
On Sep 24, 2012, at 12:03 PM, Rik Cabanier caban...@gmail.commailto:caban...@gmail.com wrote: On Mon, Sep 24, 2012 at 10:27 AM, Darin Adler da...@apple.commailto:da...@apple.com wrote: On Sep 22, 2012, at 9:21 PM, Elliott Sprehn espr...@chromium.orgmailto:espr...@chromium.org wrote: On Fri, Sep 21, 2012 at 6:34 AM, Dirk Schulze dschu...@adobe.commailto:dschu...@adobe.com wrote: I would like to ask if there are objections to implement the canvas Path object. Do we have metrics on how often people already have things named Path? All other canvas objects have a prefix like CanvasGradient and CanvasPattern, this thing seems inconsistent and more likely to break existing pages. Dirk, given the fact that you quite logically referred to this as “the canvas Path object” when mentioning it to us, and the fact that both CanvasGradient and CanvasPattern objects exist, CanvasPath sure does seem like a nice name for this. Someone should make that suggestion on the WebApps mailing list! I am interested in the feature, not the name. I am fine with naming it CanvasPath. Remember that Path is not limited to Canvas, other then for instance SVGPathElement. I just want to avoid that people come to the impression that this can just be used for Canvas. A difference though is that the path object doesn't have to be associated with a canvas. It is/will be useful with other features such as SVG as well. I feel uneasy with the generic name too; maybe a DOM/HTML/JS prefix is better. DOM and HTML will lead to the same wrong conclusions IMO. And JS seems unusual as prefix. Greetings Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] New Feature: Canvas Path object
I'm not hung up on the name. But if we are worried about name collision, we could do data gathering on use of Path or other candidate names instead of just guessing. - Maciej On Sep 24, 2012, at 12:22 PM, Dirk Schulze dschu...@adobe.com wrote: On Sep 24, 2012, at 12:03 PM, Rik Cabanier caban...@gmail.com wrote: On Mon, Sep 24, 2012 at 10:27 AM, Darin Adler da...@apple.com wrote: On Sep 22, 2012, at 9:21 PM, Elliott Sprehn espr...@chromium.org wrote: On Fri, Sep 21, 2012 at 6:34 AM, Dirk Schulze dschu...@adobe.com wrote: I would like to ask if there are objections to implement the canvas Path object. Do we have metrics on how often people already have things named Path? All other canvas objects have a prefix like CanvasGradient and CanvasPattern, this thing seems inconsistent and more likely to break existing pages. Dirk, given the fact that you quite logically referred to this as “the canvas Path object” when mentioning it to us, and the fact that both CanvasGradient and CanvasPattern objects exist, CanvasPath sure does seem like a nice name for this. Someone should make that suggestion on the WebApps mailing list! I am interested in the feature, not the name. I am fine with naming it CanvasPath. Remember that Path is not limited to Canvas, other then for instance SVGPathElement. I just want to avoid that people come to the impression that this can just be used for Canvas. A difference though is that the path object doesn't have to be associated with a canvas. It is/will be useful with other features such as SVG as well. I feel uneasy with the generic name too; maybe a DOM/HTML/JS prefix is better. DOM and HTML will lead to the same wrong conclusions IMO. And JS seems unusual as prefix. Greetings Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
