On 06/05/2012 04:35 PM, Keith Kyzivat wrote:
On 06/05/2012 09:22 AM, ext Balazs Kelemen wrote:
On 06/05/2012 03:12 PM, Coda Highland wrote:
I don't understand why the push for V8 in the first place. JSC and V8
are in an arms race for performance, so you can't categorically say V8
is faster because that's not always true.
I did not say it's faster or superior but using two js engines in a
stack is insane.
JSC also has broader support
(see Konstantin's post). Furthermore, my understanding is that V8
doesn't expose the necessary APIs to be able to provide the full scope
of the QtScript API. (Has this changed since the original plans to
move to V8 were announced?)
I don't think v8 lack's any API that JSC has. If we only consider
public API, I think v8 is much more rich - maybe I'm wrong. Anyway,
declarative - which is really a fundamental of Qt5 - is using v8 and
I guess there is a reason for that and it's not desirable to move it
to JSC.
I have been hearing speak of Qt trying something new/moving away from
using v8 (I think because v8 is not optimized for the quick entry/exit
that QML does), though I imagine that Qt5 will stil provide
opportunity to use v8...
Isn't there a way we can have v8 and JSC be separate options, with one
or the other compiled in at compile-time?
How about separating out the JS engine entirely into a separate shared
library?
Granted, there's a maintenance cost for maintaining both engines...
Maybe you're considering that in addition to the memory savings you
mentioned?
JSC is a hard dependency of WebKit. Organizing jsc into a shared library
- which is possible - doesn't solve this. If you think about abstracting
the js engine with some Qt api, that neither does work because we
obviously cannot force everybody in webkit to use our js api.
_______________________________________________
webkit-qt mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-qt
