gmane.os.opendarwin.webkit.devel

Re: Why is the team list in two places?

Bem Jones-Bey — 2013-05-24T21:07:44

On May 24, 2013, at 12:08 , Benjamin Poulain <benjamin< at >webkit.org<mailto:benjamin< at >webkit.org>> wrote:

On Fri, May 24, 2013 at 8:07 AM, Bem Jones-Bey <bjonesbe< at >adobe.com<mailto:bjonesbe< at >adobe.com>> wrote:
I happened to notice today that we have a team list at http://www.webkit.org/team.html as well as the one at http://trac.webkit.org/wiki/WebKit%20Team. It looks like the team.html one is generated from contributors.json. Any reason why we couldn't just put the "Areas of knowledge" into contributors.json and then have those listed in team.html so we can get rid of the one on the Wiki and only have one place for this info?

Looks like you just volunteered to fix that ;)

Looks like it. Do you want to volunteer to review it? ;-)
https://bugs.webkit.org/show_bug.cgi?id=116737

- Bem

_______________________________________________
webkit-dev mailing list
webkit-dev< at >lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: Why is the team list in two places?

Benjamin Poulain — 2013-05-24T19:08:06


Looks like you just volunteered to fix that ;)

Benjamin
_______________________________________________
webkit-dev mailing list
webkit-dev< at >lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: Implement Deferred Rendering in WebKitGTK+

Benjamin Poulain — 2013-05-24T18:36:22


A few questions:

What kind of modifications are needed for your implementation?
Since you do that on top of a rasterizer instead of inside the rasterizer,
how do you deal with Images, Canvas, etc?

Benjamin
_______________________________________________
webkit-dev mailing list
webkit-dev< at >lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Why is the team list in two places?

Bem Jones-Bey — 2013-05-24T15:07:07

Hi all,

I happened to notice today that we have a team list at http://www.webkit.org/team.html as well as the one at http://trac.webkit.org/wiki/WebKit%20Team. It looks like the team.html one is generated from contributors.json. Any reason why we couldn't just put the "Areas of knowledge" into contributors.json and then have those listed in team.html so we can get rid of the one on the Wiki and only have one place for this info?

- Bem

Implement Deferred Rendering in WebKitGTK+

Jae Hyun Park — 2013-05-24T09:43:02

Hi, webkit folks.

Our team is planning on upstreaming Deferred Rendering in GTK+ port.

Deferred Rendering is a parallelization technique to perform rasterization
on a dedicated thread to improve performance.

We have published our design document in the link below:
https://docs.google.com/document/d/1K4q7KtPzsm6c7qUnHqW0NtAv7uItxgs35QZJvHsfLjY/pub

We have also created meta bug in WebKit bugzilla.
https://bugs.webkit.org/show_bug.cgi?id=116713

Any comments/concerns are appreciated.

Best regards,
Jae Hyun Park
_______________________________________________
webkit-dev mailing list
webkit-dev< at >lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: Adding new entries to TestExpectations can beharmful

Dirk Pranke — 2013-05-24T00:41:18

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 ?

Re: Use BlinkMergeCandidate to merge/back port Blinkchanges

Ryosuke Niwa — 2013-05-23T17:52:19

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 <akling< at >apple.com> wrote:

_______________________________________________
webkit-dev mailing list
webkit-dev< at >lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

LAST CALL: Re: Unprefixing Page Visibility

Simon Fraser — 2013-05-23T17:05:36


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

Re: Use BlinkMergeCandidate to merge/back port Blink changes

Andreas Kling — 2013-05-23T16:49:43



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< at >lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: Use BlinkMergeCandidate to merge/back port Blink changes

Darin Adler — 2013-05-23T16:26:41


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.

Re: Use BlinkMergeCandidate to merge/back port Blink changes

Sergio Villar Senin — 2013-05-23T15:42:33

En 21/05/13 06:06, Ryosuke Niwa escribiu:

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

NPOT Textures

SzymanskiPrzemyslaw — 2013-05-23T07:14:31

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< at >lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Adding new entries to TestExpectations can be harmful

Ryosuke Niwa — 2013-05-23T01:11:28

And there is an overwhelming evidence:
http://trac.webkit.org/changeset?reponame=&new=150559%40trunk%2FLayoutTests%2Fplatform%2Fmac%2FTestExpectations&old=150476%40trunk%2FLayoutTests%2Fplatform%2Fmac%2FTestExpectations

- R. Niwa
_______________________________________________
webkit-dev mailing list
webkit-dev< at >lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: Ref counting questions

Maciej Stachowiak — 2013-05-22T19:38:18

We could probably phase out TreeShared if we were really careful to avoid refcount thrash during tree construction/manipulation. I believe this can be done with careful use of PassRefPtr and swap() and it would likely be easier to understand if Nodes normally had a refcount of 1 instead of 0.

On May 22, 2013, at 10:41 AM, Antti Koivisto <koivisto< at >iki.fi> wrote:


_______________________________________________
webkit-dev mailing list
webkit-dev< at >lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: Ref counting questions

Antti Koivisto — 2013-05-22T17:41:30

TreeShared is essentially an implementation detail of the DOM tree (the
only other client besides Node is SVGElementInstance).  It shouldn't be
used for anything else.

TreeShared keeps Nodes alive when they are part of a tree (have a parent
node) even when they have zero refcount. This way nodes don't need to
explicitly ref and deref their children.


  antti


On Wed, May 22, 2013 at 7:26 PM, Bem Jones-Bey <bjonesbe< at >adobe.com> wrote:

_______________________________________________
webkit-dev mailing list
webkit-dev< at >lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Ref counting questions

Bem Jones-Bey — 2013-05-22T16:26:34

Hey all,

I've read the document at http://www.webkit.org/coding/RefPtr.html, but I still have some questions about using RefPtrs.

The first one is listed in the "Improving this document" section of the aforementioned documentation:
• Perils of programming with TreeShared.
What does that mean? What gotchas should I be aware of? (Heck, more details on any of the things in "improving this document" would be helpful, and I'll do my best to update the document with anything I learn if that's desired.)

Also, I've noticed that there's both TreeShared and RefCounted, and they seem fairly similar to my uninitiated eye. What's the difference between the two and when should one use one or the other? Also, are there other templates/classes that I should be aware of?

Thanks,
Bem

Re: Moving WebCore/accessibility codeintoWebCore/platform/

Mario Sanchez Prada — 2013-05-22T09:06:06

Hi Maciej,

[.]

That's absolutely right. When I sent the email I was thinking more of the
platform specific nature of the accessibility layer and its adaptation to
each port (the wrappers), but it's true that the relationship with those
other trees is so tight that moving it into platform (as it is now) would be
a problem.


Agreed on this too. 

Thanks for the feedback,
Mario

Re: Moving WebCore/accessibility codeintoWebCore/platform/

Maciej Stachowiak — 2013-05-21T19:05:08

On May 21, 2013, at 7:34 AM, Mario Sanchez Prada <mario.prada< at >samsung.com> wrote:


I think the main problem with this change is that the current WebCore/accessibility code has lots of knowledge of the DOM and render tree. Making WebCore/platform depend on these Web-specific concepts is a layering violation - imagine how it would work if it was a top-level directory Platform that was a peer of WebCore, and built before it without access to its headers. That is logically how it should operate.

If the accessibility code could be redesigned to have a good abstraction between the parts that are tightly tied to Web-specific classes and concepts, and the part that is platform-specific, then the second part could be moved to WebCore/platform. A refactoring like that could be a good improvement, but is likely hard to do.

Regards,
Maciej

_______________________________________________
webkit-dev mailing list
webkit-dev< at >lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: Moving WebCore/accessibility code into WebCore/platform/

Darin Adler — 2013-05-21T18:17:54


Again, I think in theory this is good, if it drives people to create the abstractions we need to keep our code from being littered with too literal #ifdefs.

But instead the style checker warning is pushing at least some folks to move classes into the platform directory that do not belong there, just to avoid the warning, likely creating layering violations and misusing the platform library.

Further, I am seeing this warning often when I do refactoring patches.

I think what we did in the style checker is not a good enough way to communicate the nuance of how we do this. We need a document with a statement of principles about the platform approach to refer people to. And perhaps an approach that gives a warning rather than a style error that points to that document.

— Darin_______________________________________________
webkit-dev mailing list
webkit-dev< at >lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: Moving WebCore/accessibility code intoWebCore/platform/

Jessie Berlin — 2013-05-21T18:15:57

I rolled it out in http://trac.webkit.org/changeset/150457


On Tue, May 21, 2013 at 10:58 AM, Sam Weinig <weinig< at >apple.com> wrote:

_______________________________________________
webkit-dev mailing list
webkit-dev< at >lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: Moving WebCore/accessibility code intoWebCore/platform/

Benjamin Poulain — 2013-05-21T18:14:12


For me that rule was more about asking people to think twice and add the
proper abstraction when possible.
We do not want style checker warnings, which becomes a motivation for
creating better abstractions.

For example, recently a second implementation of some of DOMFileSystemBase
was added for blackberry (most if it is an exact copy of the common code).
With a style checker warning, the author would have had to justify this
kind of decision (and hopefully fix the code instead).

Benjamin
_______________________________________________
webkit-dev mailing list
webkit-dev< at >lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev