On Tuesday, January 08, 2013 02:57:53 PM Sam Weinig wrote:
Hello webkit-dev,
We are making some changes to the development process for WebKit2. These
changes were announced to reviewers in advance, and I'd like to share them
with you now.
WebKit2 has a core set of functionality that is
On Wed, Jan 9, 2013 at 11:32 AM, Simon Hausmann
simon.hausm...@digia.com wrote:
On Tuesday, January 08, 2013 02:57:53 PM Sam Weinig wrote:
Hello webkit-dev,
We are making some changes to the development process for WebKit2. These
changes were announced to reviewers in advance, and I'd like to
Hi,
2013/1/8 Sam Weinig wei...@apple.com:
Hello webkit-dev,
We are making some changes to the development process for WebKit2. These
changes were announced to reviewers in advance, and I'd like to share them
with you now.
WebKit2 has a core set of functionality that is valuable to all
On Qua, 2013-01-09 at 12:04 +0200, Thiago Marcos P. Santos wrote:
I think the fact that the regular WebKit review process stops at the
boundary
of WebKit2 should be documented in the WebKit Committers and Reviewer
Policy.
Agree. And please clarify on the policy if we are talking
I've got a patch in flight that adds a feature flag.
https://bugs.webkit.org/show_bug.cgi?id=106275
According to the instructions liked below I need to edit a WebKit2 file
http://trac.webkit.org/wiki/AddingFeatures#ActivatingafeatureforAutotoolsbasedports
Does that guideline change? Should I
Trivial changes like this do not need to be approved by an owner.
-Sam
On Jan 9, 2013, at 9:38 AM, Gregg Tavares g...@google.com wrote:
I've got a patch in flight that adds a feature flag.
https://bugs.webkit.org/show_bug.cgi?id=106275
According to the instructions liked below I need to
On Jan 9, 2013, at 8:10 AM, Gustavo Noronha Silva g...@gnome.org wrote:
On Qua, 2013-01-09 at 12:04 +0200, Thiago Marcos P. Santos wrote:
I think the fact that the regular WebKit review process stops at the
boundary
of WebKit2 should be documented in the WebKit Committers and Reviewer
Hi Sam. Some comments below.
Cheers,
--Antonio
Curious about this myself, I just reviewed a patch only affecting the
GTK-specific parts of WebKit2, I believe that is OK? Should we ammend
the Owners file to include information about port-specific directories
and reviewers?
Cheers,
At
Also, the word position is used to represent a tree-position in DOM in
WebKit so please don't use that to represent a point in a screen or a layout
coordinate system.
OK, perhaps we should use Vector2d, as is used by the Chromium port
___
webkit-dev
On Jan 9, 2013, at 3:47 PM, Steve Block stevebl...@chromium.org wrote:
Also, the word position is used to represent a tree-position in DOM in
WebKit so please don't use that to represent a point in a screen or a layout
coordinate system.
OK, perhaps we should use Vector2d, as is used by the
Removing the existing subtraction operator (xxxPoint minus
xxxPoint returns xxxSize) might be a good place to start.
I've uploaded a patch to
https://bugs.webkit.org/show_bug.cgi?id=106408 which replaces these
subtraction operators with ones that return xxxPoint, and which adds
On Wed, Jan 9, 2013 at 3:47 PM, Steve Block stevebl...@chromium.org wrote:
Also, the word position is used to represent a tree-position in DOM in
WebKit so please don't use that to represent a point in a screen or a
layout
coordinate system.
OK, perhaps we should use Vector2d, as is used
I'm really not sure that this set of changes is going in the right direction.
What's driving them; some abstract sense of purity, or
reducing the chances of introducing real bugs that we've seen in the past?
Some of both. I was investigating a bug where WebCore is generating
unexpected
On Jan 9, 2013, at 4:52 PM, Steve Block stevebl...@chromium.org wrote:
I'm really not sure that this set of changes is going in the right
direction. What's driving them; some abstract sense of purity, or
reducing the chances of introducing real bugs that we've seen in the past?
Some of both.
We're planning to move parts of the HTML Parser off of the main thread:
https://bugs.webkit.org/show_bug.cgi?id=106127
This is driven by our testing showing that HTML parsing on mobile is
be slow, and long (causing user-visible delays averaging 10 frames /
150ms).
It seems like a lot of churn for relatively little gain. I'd rather our time
be focused
on areas that actually benefit users of WebKit.
OK. I don't feel strongly enough about this to push the issue.
___
webkit-dev mailing list
On Wed, Jan 9, 2013 at 6:00 PM, Eric Seidel e...@webkit.org wrote:
We're planning to move parts of the HTML Parser off of the main thread:
https://bugs.webkit.org/show_bug.cgi?id=106127
This is driven by our testing showing that HTML parsing on mobile is
be slow, and long (causing
How will we ensure thread safety? Even at just the tokenizing level don't we
use AtomicString? AtromicString isn't threadsafe wrt StringImpl IIRC so this
seems like it sould add a world of hurt.
I realise it's been a long time since I've worked on this so it's completely
possible that I'm
On Jan 9, 2013, at 5:40 PM, Simon Fraser simon.fra...@apple.com wrote:
On Jan 9, 2013, at 4:52 PM, Steve Block stevebl...@chromium.org wrote:
I'm really not sure that this set of changes is going in the right
direction. What's driving them; some abstract sense of purity, or
reducing the
On Wed, Jan 9, 2013 at 6:38 PM, Oliver Hunt oli...@apple.com wrote:
How will we ensure thread safety? Even at just the tokenizing level don't we
use AtomicString? AtromicString isn't threadsafe wrt StringImpl IIRC so this
seems like it sould add a world of hurt.
AtomicString is already
On Wed, Jan 9, 2013 at 7:07 PM, Eric Seidel e...@webkit.org wrote:
On Wed, Jan 9, 2013 at 6:38 PM, Oliver Hunt oli...@apple.com wrote:
How will we ensure thread safety? Even at just the tokenizing level
don't we use AtomicString? AtromicString isn't threadsafe wrt StringImpl
IIRC so this
On Wed, Jan 9, 2013 at 7:35 PM, Benjamin Poulain benja...@webkit.org wrote:
On Wed, Jan 9, 2013 at 7:07 PM, Eric Seidel e...@webkit.org wrote:
On Wed, Jan 9, 2013 at 6:38 PM, Oliver Hunt oli...@apple.com wrote:
How will we ensure thread safety? Even at just the tokenizing level
don't we use
I think your biggest challenge will be ensuring that the latency of shoving
things to another core and then shoving them back will be smaller than the
latency of processing those same things on the main thread.
For small documents, I expect concurrent tokenization to be a pure regression
On Wed, 9 Jan 2013, Eric Seidel wrote:
The core goal is to reduce latency -- to free up the main thread for
JavaScript and UI interaction -- which as you correctly note, cannot be
moved off of the main thread due to the single thread of execution
model of the web.
Parsing and (maybe to a
On Jan 9, 2013, at 10:04 PM, Ian Hickson i...@hixie.ch wrote:
On Wed, 9 Jan 2013, Eric Seidel wrote:
The core goal is to reduce latency -- to free up the main thread for
JavaScript and UI interaction -- which as you correctly note, cannot be
moved off of the main thread due to the single
25 matches
Mail list logo
