Hi,
The Qt port of WebKit (based on Qt 5.x) does not use v8.
(Qt 5.x uses v8 in other places, but that is not relevant to the WebKit project
and this discussion)
Simon
Markus kamika...@gmx.de wrote:
For the record though I don't think Qt is using any of that those.
Qt 5.x uses V8.
Hi Geoff,
First of all, let me say upfront that I see all the potential advantages of
sticking to just one JS engine, and also perfectly understand the points
that most of the people here have made on favour of not supporting multiple
engines.
Also, my mail was not really a formal request to
On Qui, 2013-04-04 at 18:46 +0200, Balazs Kelemen wrote:
FWIW, mrobinson has been working on a GYP build for the GTK port, so I
wouldn't delete all of the .gyp files (at least not w/o them weighing
in on it). I thought there was some interest at Apple in also using
GYP, but perhaps things
Also, WebP project is unfinished state right now. This changeset requires
libwebp version 0.3.0:
https://trac.webkit.org/changeset/147048
But version 0.3.0 also supports animated webp, and google doesn't have the
code for animation support in WEBPImageDecoder.cpp yet, not even in
Chromium.
So
Hi Mario.
First of all, let me say upfront that I see all the potential advantages of
sticking to just one JS engine, and also perfectly understand the points
that most of the people here have made on favour of not supporting multiple
engines.
Also, my mail was not really a formal request
On Friday 05 April 2013, Max Stepin wrote:
Also, WebP project is unfinished state right now. This changeset requires
libwebp version 0.3.0:
https://trac.webkit.org/changeset/147048
To me it looks more like it requires 0.3.0 to enable color correction. Older
ABIs are still supported.
`Allan
To me it looks more like it requires 0.3.0 to enable color correction.
Older ABIs are still supported.
Yes, but some WebP images (created with 0.3.0) will not work.
I tried, not even the first frame is displayed.
Would it be OK to just take future WEBPImageDecoder.cpp updates from Chromium?
On Friday 05 April 2013, Max Stepin wrote:
To me it looks more like it requires 0.3.0 to enable color correction.
Older ABIs are still supported.
Yes, but some WebP images (created with 0.3.0) will not work.
I tried, not even the first frame is displayed.
Would it be OK to just take
On Apr 5, 2013, at 5:25 AM, Mario Sanchez Prada mario.pr...@samsung.com wrote:
Also, my mail was not really a formal request to keep the V8 bits around in
the long term, but just a quick reply to the following comment from Maciej:
Geoff posted the list in part because we'd like to
On Friday, April 05, 2013 09:24:59 AM Geoffrey Garen wrote:
Hi Mario.
First of all, let me say upfront that I see all the potential advantages
of
sticking to just one JS engine, and also perfectly understand the points
that most of the people here have made on favour of not supporting
On Thu, Apr 4, 2013 at 12:30 AM, Geoffrey Garen gga...@apple.com wrote:
Hi folks.
Since we no longer need to support the Chromium port, let's take the
opportunity to streamline. Hopefully, this will make development easier and
more coherent for everyone. Adam and Eric offered to do some of
On Thursday 04 April 2013, Geoffrey Garen wrote:
Hi folks.
Since we no longer need to support the Chromium port, let's take the
opportunity to streamline. Hopefully, this will make development easier
and more coherent for everyone. Adam and Eric offered to do some of this
cleanup, but I
@lists.webkit.org
Subject: Re: [webkit-dev] Cleaning House
On Thursday 04 April 2013, Geoffrey Garen wrote:
Hi folks.
Since we no longer need to support the Chromium port, let's take the
opportunity to streamline. Hopefully, this will make development easier
and more coherent for everyone. Adam
BlackBerry is moving away from Skia, a removal wouldn't hurt us at this point. With EFL being on cairo, it seems like that item can stay on the list.- Jakob
On Apr 4, 2013, at 1:39 AM, Allan Sandfeld Jensen k...@carewolf.com wrote:
On Thursday 04 April 2013, Geoffrey Garen wrote:
Hi folks.
Since we no longer need to support the Chromium port, let's take the
opportunity to streamline. Hopefully, this will make development easier
and more
On Thursday 04 April 2013, jpe...@gmx.at wrote:
BlackBerry is moving away from Skia, a removal wouldn't hurt us at this
point. With EFL being on cairo, it seems like that item can stay on the
list.
Ah, right. Sorry for the confusion. I had the impression with all the places
Skia specific
Geoffrey Garen gga...@apple.com writes:
Also:
Adopt libc++
My FreeBSD hat appreciates that, but can you elaborate? Is there
something specific to libc++ not present in, say, libstdc++, that is
going to be used?
--
Intel Finland Oy
Open Source Technology Center
GoogleURL seems Chromium-specific, i.e. WTF_USE_GOOGLEURL is only defined
for Chromium in Source/WebCore/config.h.
Regards,
-Z
On Thu, Apr 4, 2013 at 10:50 AM, Maciej Stachowiak m...@apple.com wrote:
On Apr 4, 2013, at 1:39 AM, Allan Sandfeld Jensen k...@carewolf.com
wrote:
On Thursday 04
Hi,
On Apr 4, 2013, at 1:39 AM, Allan Sandfeld Jensen k...@carewolf.com
wrote:
[...]
#if USE(V8)
#if !USE(JSC)
Here at Samsung we are using WebKitGTK+ and V8, and I bet we are not the
only ones doing it, so it would be great to keep those guards there.
Geoff posted the list in
Hey,
On Qui, 2013-04-04 at 01:22 -0700, Dirk Pranke wrote:
FWIW, mrobinson has been working on a GYP build for the GTK port, so I
wouldn't delete all of the .gyp files (at least not w/o them weighing
in on it). I thought there was some interest at Apple in also using
GYP, but perhaps things
We'll be in #webkit and happy to be helpful in any way we can.
I considered posting patches to remove *Chromium files yesterday
afternoon, but then abarth reminded me that the commit-queue currently
uses chromium-linux. I spoke with rniwa at some length yesterday in
#webkit about transitioning
From: webkit-dev-boun...@lists.webkit.org
[webkit-dev-boun...@lists.webkit.org] on behalf of Eric Seidel
[e...@webkit.org]
Sent: Thursday, April 04, 2013 9:41 AM
To: Geoffrey Garen
Cc: webkit-dev@lists.webkit.org Development
Subject: Re: [webkit-dev] Cleaning House
I considered posting
Geoffrey Garen gga...@apple.com writes:
Concepts we plan to remove:
Features #defines that haven't gained traction
Do you already have anything in mind? Is the process described in the
DeprecatingFeatures article on the wiki still going to be followed?
--
Intel Finland Oy
Open Source
On Thu, Apr 4, 2013 at 3:56 AM, Mario Sanchez Prada mario.pr...@samsung.com
wrote:
On Apr 4, 2013, at 1:39 AM, Allan Sandfeld Jensen k...@carewolf.com
wrote:
[...]
#if USE(V8)
#if !USE(JSC)
Here at Samsung we are using WebKitGTK+ and V8, and I bet we are not the
only ones
On 04/04/2013 03:15 PM, Gustavo Noronha Silva wrote:
Hey,
On Qui, 2013-04-04 at 01:22 -0700, Dirk Pranke wrote:
FWIW, mrobinson has been working on a GYP build for the GTK port, so I
wouldn't delete all of the .gyp files (at least not w/o them weighing
in on it). I thought there was some
On Apr 4, 2013, at 2:01 AM, Raphael Kubo da Costa rak...@webkit.org wrote:
Geoffrey Garen gga...@apple.com writes:
Also:
Adopt libc++
My FreeBSD hat appreciates that, but can you elaborate? Is there
something specific to libc++ not present in, say, libstdc++, that is
going to be
I would strongly suggest purging V8, for the many performance and code
complexity reasons Google is removing JSC from blink. (See
www.chromium.org/blink/developer-faq)
I'd also suggest purging the chromium layout tests ASAP so we can enjoy the
much-reduced archive sync costs.
-Brent
Sent
On Apr 4, 2013, at 10:03 AM, Brent Fulgham bfulg...@gmail.com wrote:
I would strongly suggest purging V8, for the many performance and code
complexity reasons Google is removing JSC from blink. (See
www.chromium.org/blink/developer-faq)
+1
I'd also suggest purging the chromium layout
On Thu, Apr 4, 2013 at 10:34 AM, Geoffrey Garen gga...@apple.com wrote:
What would it take for WebKitGTK+ to adopt the JSC bindings?
Just for clarity's sake. WebKitGTK+ only supports JSC, but it seems
there are some external branches/forks using V8. In the past, we've
rejected proposals to add
Is the process described in the
DeprecatingFeatures article on the wiki still going to be followed?
Yes.
I'm generally talking about features that will fall under the Cold turkey
approach, based on rough consensus that they are either unsupported or unused.
Geoff
Hi Martin.
Just for clarity's sake. WebKitGTK+ only supports JSC, but it seems
there are some external branches/forks using V8. In the past, we've
rejected proposals to add V8 support to WebKitGTK+.
OK, I think that pretty much confirms that no WebKit contributors are
maintaining the v8
On Apr 4, 2013, at 10:37 AM, Martin Robinson mrobin...@webkit.org wrote:
On Thu, Apr 4, 2013 at 10:34 AM, Geoffrey Garen gga...@apple.com wrote:
What would it take for WebKitGTK+ to adopt the JSC bindings?
Just for clarity's sake. WebKitGTK+ only supports JSC, but it seems
there are some
On Thu, Apr 4, 2013 at 11:03 AM, Brent Fulgham bfulg...@gmail.com wrote:
I'd also suggest purging the chromium layout tests ASAP so we can enjoy
the much-reduced archive sync costs.
We really need to get the Mac or Win EWS performing tests by default and
reliably before doing this. At
I'd also suggest purging the chromium layout tests ASAP so we can enjoy the
much-reduced archive sync costs.
We really need to get the Mac or Win EWS performing tests by default and
reliably before doing this. At present, only the chromium-linux EWS bot has
been consistently running
Hi folks,
I definitely do not want to see the EWS system go away. But in the short term ,
I would be in favor of manual commits and manual testing.
We still have the build bots running tests, so it's not like we lose all
coverage.
Thanks,
-Brent
Sent from my iPhone
On Apr 4, 2013, at 11:56
I think everyone is agreeing that we should have a suitable replacement for
EWS.
But I also want to see us move forward with clean ups. I think such clean ups
will bring clarity to what we would want our EWS testing to look like since
we'll have fewer configurations to test.
I like the
On Thu, Apr 4, 2013 at 1:44 PM, Filip Pizlo fpi...@apple.com wrote:
Sent from my PDP-11
11/20? 11/40? RSX-11? RT-11? Love the split I/D memory on 11/70s.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
On Thu, Apr 4, 2013 at 1:50 PM, Geoffrey Garen gga...@apple.com wrote:
To clarify:
(1) The EWS bots are still running.
(2) The mac and mac-wk2 EWS bots are running tests, and passing.
(3) The cr-linux bots are running tests, and failing.
If we're OK with item (3), we can go ahead with
Hi,
On Apr 4, 2013, at 12:50 PM, Geoffrey Garen gga...@apple.com wrote:
(3) The cr-linux bots are running tests, and failing.
If we're OK with item (3), we can go ahead with cleaning house, and break the
cr-* EWS bots entirely, while we work on making the mac and mac-wk2 EWS bots
faster.
We're ready to turn down the cr-linux EWS bots at your command.
Just let us know (via email or #webkit). Thanks!
On Thu, Apr 4, 2013 at 12:50 PM, Geoffrey Garen gga...@apple.com wrote:
To clarify:
(1) The EWS bots are still running.
(2) The mac and mac-wk2 EWS bots are running tests, and
Resent from the right address.
On Thu, Apr 4, 2013 at 1:09 PM, Eric Seidel esei...@google.com wrote:
We're ready to turn down the cr-linux EWS bots at your command.
Just let us know (via email or #webkit). Thanks!
On Thu, Apr 4, 2013 at 12:50 PM, Geoffrey Garen gga...@apple.com wrote:
To
On Thu, Apr 4, 2013 at 12:50 PM, Geoffrey Garen gga...@apple.com wrote:
To clarify:
(1) The EWS bots are still running.
(2) The mac and mac-wk2 EWS bots are running tests, and passing.
(3) The cr-linux bots are running tests, and failing.
If we're OK with item (3), we can go ahead with
On 04/04/2013 10:21 AM, Oliver Hunt wrote:
Supporting V8 places a considerable burden on webkit, there are a number of
large, cumbersome and expensive abstractions required for to support multiple
JS engines (see the original discussions on the topic from many years ago).
We at Oracle are
Supporting multiple JS engines is a major burden, and prevents us from doing
optimizations that more seamlessly bridge the gap between DOM and JSC. I
suspect we won't want to continue supporting multiple JS engines like we did
when the Chrome folks used WebKit with V8.
-Filip
On Apr 4,
For the record though I don't think Qt is using any of that those.
Qt 5.x uses V8.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
On Thu, Apr 4, 2013 at 6:01 PM, Markus kamika...@gmx.de wrote:
For the record though I don't think Qt is using any of that those.
Qt 5.x uses V8.
QML uses V8. That does not matter for WebKit.
QtWebKit uses exclusively JSC.
Benjamin
___
webkit-dev
On Apr 4, 2013, at 4:54 PM, Per Bothner per.both...@oracle.com wrote:
On 04/04/2013 10:21 AM, Oliver Hunt wrote:
Supporting V8 places a considerable burden on webkit, there are a number of
large, cumbersome and expensive abstractions required for to support multiple
JS engines (see the
47 matches
Mail list logo
