[webkit-dev] NPOT Textures
Hello. In WebGLRenderingContext::setupFlags() there is a line: m_isGLES2NPOTStrict = !m_context-getExtensions()-isEnabled(GL_OES_texture_npot); My question is: why is this negation? Now NPOT textures doesn't work in WebKit but without this negation NPOT textures works fine. Is this disabling of NPOT textures intentionally? Thanks for reply, Przemek ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Use BlinkMergeCandidate to merge/back port Blink changes
En 21/05/13 06:06, Ryosuke Niwa escribiu: Hi, We’ve added BlinkMergeCandidate keyword to Bugzilla to track any Blink changes we might want to merge. Please add this keyword when you’re filing a bug or posting a patch to merge a Blink change. There is an interesting question about merging fixes from Blink. Should we keep the original author in the ChangeLog appending the name of the merger maybe? BR ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Use BlinkMergeCandidate to merge/back port Blink changes
On May 23, 2013, at 8:42 AM, Sergio Villar Senin svil...@igalia.com wrote: There is an interesting question about merging fixes from Blink. Should we keep the original author in the ChangeLog appending the name of the merger maybe? Generally speaking, the person committing to WebKit is responsible for the content of the patch. I prefer not to think of that person as the “merger”. Their name should still be on the patch. And yes, I think it’s handy to cite the name of the author of the Blink patch in the change log. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Use BlinkMergeCandidate to merge/back port Blink changes
On May 23, 2013, at 6:26 PM, Darin Adler da...@apple.com wrote: On May 23, 2013, at 8:42 AM, Sergio Villar Senin svil...@igalia.com wrote: There is an interesting question about merging fixes from Blink. Should we keep the original author in the ChangeLog appending the name of the merger maybe? Generally speaking, the person committing to WebKit is responsible for the content of the patch. I prefer not to think of that person as the “merger”. Their name should still be on the patch. And yes, I think it’s handy to cite the name of the author of the Blink patch in the change log. That’s along the lines of the approach I’ve been taking. For patches that meet both of these criteria: - Either trivial, or in my area of expertise. - Merges cleanly without much/any modification ...I put on my reviewer hat and pretend it’s a WebKit patch, review it and land it. Example: http://trac.webkit.org/changeset/149734 For patches I’m less comfortable with, or that just need more work to fit into WebKit, I put on my committer hat, wrap it into a new patch, and add it to the review queue. Example: http://trac.webkit.org/changeset/149110 In both cases, I credit the Blink author and provide a URL to the Blink change-set. -Andreas___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] LAST CALL: Re: Unprefixing Page Visibility
On May 20, 2013, at 6:28 PM, Simon Fraser simon.fra...@apple.com wrote: Does anyone object to supporting the Page Visibility API unprefixed? https://bugs.webkit.org/show_bug.cgi?id=102340 Should we keep support for the prefixed version? I hear no requests to keep the prefixed version. Does any port want it? If not, I will simply unprefix without preserving the prefixed behavior. In unprefixing, there will be a minor API change. We have a preview state that, theoretically, can be returned from document.visibilityState (but I don't think we ever did). That was replaced in 2011 by a unloaded state, which the document passes into when it's being unloaded. I will add the string, but support for this in the spec is optional; I don't intend to hook this up at this time. See https://bugs.webkit.org/show_bug.cgi?id=116645 The unprefixing bug is https://bugs.webkit.org/show_bug.cgi?id=102340. Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Use BlinkMergeCandidate to merge/back port Blink changes
I always post patches as my patch saying I'm merging some patch with a chromium.googlesource.com URL as in: http://trac.webkit.org/changeset/150416 In a lot of cases, I find myself fixing the patch or rewriting the patch because either the patch is wrong, doesn't conform to the WebKit style, or it can be improved. - R. Niwa On Thu, May 23, 2013 at 9:49 AM, Andreas Kling akl...@apple.com wrote: On May 23, 2013, at 6:26 PM, Darin Adler da...@apple.com wrote: On May 23, 2013, at 8:42 AM, Sergio Villar Senin svil...@igalia.com wrote: There is an interesting question about merging fixes from Blink. Should we keep the original author in the ChangeLog appending the name of the merger maybe? Generally speaking, the person committing to WebKit is responsible for the content of the patch. I prefer not to think of that person as the “merger”. Their name should still be on the patch. And yes, I think it’s handy to cite the name of the author of the Blink patch in the change log. That’s along the lines of the approach I’ve been taking. For patches that meet both of these criteria: - Either trivial, or in my area of expertise. - Merges cleanly without much/any modification ...I put on my reviewer hat and pretend it’s a WebKit patch, review it and land it. Example: http://trac.webkit.org/changeset/149734 For patches I’m less comfortable with, or that just need more work to fit into WebKit, I put on my committer hat, wrap it into a new patch, and add it to the review queue. Example: http://trac.webkit.org/changeset/149110 In both cases, I credit the Blink author and provide a URL to the Blink change-set. -Andreas ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding new entries to TestExpectations can be harmful
I may be missing context, or just slow, but how does that link illustrate things being harmful ? It looks like you're mostly adding the bug numbers inline and/or taking skipped tests and making them flaky ? -- Dirk On Wed, May 22, 2013 at 6:11 PM, Ryosuke Niwa rn...@webkit.org wrote: And there is an overwhelming evidence: http://trac.webkit.org/changeset?reponame=new=150559%40trunk%2FLayoutTests%2Fplatform%2Fmac%2FTestExpectationsold=150476%40trunk%2FLayoutTests%2Fplatform%2Fmac%2FTestExpectations - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
