Adam,
Thanks for your detailed reply. Seems like you guys have a pretty good plan in
place.
I hope this works and produces a performance improvement. That being said this
does look like a sufficiently complex work item that success is far from
guaranteed. So to play devil's advocate, what is
The solution I'd recommend is to make the JavaScriptCore and/or
WebKit2 bots faster. If those bots are able to complete their
processing before the commit-queue, then they'll stop the patch from
being committed by marking the patch commit-queue-.
Adam
On Thu, Jan 10, 2013 at 9:22 PM, Ryosuke Ni
Hi all,
As you might all know, the commit-queue uses chromium linux port.
Consequently, any JavaScriptCore and WebKit2 specific changes (and any
non-Chromium port specific changes) are never tested. Commit-queue doesn't
even detect whether it builds or not.
This is a source of confusion because m
On Jan 10, 2013, at 12:07 PM, Adam Barth wrote:
>
> On Thu, Jan 10, 2013 at 12:37 AM, Maciej Stachowiak wrote:
>> I presume from your other comments that the goal of this work is
>> responsiveness, rather than page load speed as such. I'm excited about the
>> potential to improve responsiven
+1 on the feature addition.
Please use a feature define so vendors can decide to ship the new functionality
at a time of their choosing.
Cheers,
Maciej
On Jan 10, 2013, at 6:36 AM, Kentaro Hara wrote:
> At TPAC there was no objection for DOM4 Event constructors (e.g. new
> MouseEvent()).
>
Thanks everyone for your feedback. Detailed responses inline.
On Wed, Jan 9, 2013 at 9:41 PM, Filip Pizlo wrote:
> 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 th
At TPAC there was no objection for DOM4 Event constructors (e.g. new
MouseEvent()).
Now DOM4 Event constructors are on editor's draft:
http://html5labs.interoperabilitybridges.com/dom4events/
https://dvcs.w3.org/hg/d4e/raw-file/tip/source_respec.htm
Given the above, I am planning to implement the
Hi,
FYI, WebKit-EFL is now building with gstreamer 1.0 by default [1].
[1] https://bugs.webkit.org/show_bug.cgi?id=106178
On Tue, Jan 8, 2013 at 10:09 PM, Ryan Ware wrote:
>
>
> > -Original Message-
> > From: webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev-
> > boun...@lists.web
On Thu, Jan 10, 2013 at 8:37 AM, Maciej Stachowiak wrote:
>
> The reason I ask is that this sounds like a significant increase in
> complexity, so we should be very confident that there is a real and major
> benefit. One thing I wonder about is how common it is to have enough of the
> page process
The data Eric and Adam were using comes from a python library a few of us
have been developing called "telemetry." Its basically a bunch of python
that lets us write performance tests against any browser that speaks the
inspector websocket protocol. We're using it a lot of "should we
parallelize X"
When loading web pages we are very frequently in a situation where we
already have the source data (HTML text here but the same applies to
preloaded Javascript, CSS, images, ...) and know we are likely to need it
in soon, but can't actually utilize it for indeterminate time. This happens
because pe
I presume from your other comments that the goal of this work is
responsiveness, rather than page load speed as such. I'm excited about the
potential to improve responsiveness during page loading.
One question: what tests are you planning to use to validate whether this
approach achieves its g
https://bugs.webkit.org/show_bug.cgi?id=63531
The work was done by Zoltan Horvath and Balazs Kelemen.
Regards,
Zoltan
> Hi Zoltan,
>
> I would be curious how you did the synchronization. I've had some luck
> reducing synchronization costs before.
>
> Was the patch ever uploaded anywhere?
>
> -F
Hi Zoltan,
I would be curious how you did the synchronization. I've had some luck
reducing synchronization costs before.
Was the patch ever uploaded anywhere?
-F
On Jan 10, 2013, at 12:11 AM, Zoltan Herczeg wrote:
> Parsing, especially JS parsing still takes a large amount of time on page
Parsing, especially JS parsing still takes a large amount of time on page
loading. We tried to improve the preload scanner by moving it into
anouther thread, but there was no gain (except some special cases).
Synchronization between threads is surprisingly (ridiculously) costly,
usually worth for t
15 matches
Mail list logo
