KHTML, KJS Unfrozen -- details
Koos Vriezen
koos.vriezen at xs4all.nl
Wed Jan 11 19:28:17 GMT 2006
On Wed, Jan 11, 2006 at 11:57:41AM -0500, George Staikos wrote:
> On Wednesday 11 January 2006 10:55, Koos Vriezen wrote:
> > On Tue, Jan 10, 2006 at 11:50:29PM +0000, Charles Samuels wrote:
> > > Koos Vriezen wrote, on Tuesday 2006 January 10 10:27 pm:
> > > > > > Seriously, since I've added KJS CPU guard, what will be the
> > > > > > replacement?
> > > > >
> > > > > I don't know yet.
> > > >
> > > > Any idea how Safari solves this? (I hope we all agree that a script
> > > > never may hang konqueror)
> > >
> > > I think it'd be nice if Javascripts executed incrementally (like on a
> > > QTimer(0) ).
> >
> > This idea is proposed many times. And it would also help when js has to
> > waits for modal dialogs (eg. window.alert()) or async dcop/liveconnect
> > calls.
>
> Rich is right, that would be horribly slow.
Benchmarks :)? Seriously how can you be so sure? Most noticable js speed
ups imho is maksim's work on caching, which is outside of the kjs
engine.
> > But whatever cool things we imagine, we're at the mercy of WebCore now
> > ..
>
> That's not true. We're free to do whatever we want. We're just
> synchronized with them at this time, and only in KJS.
No I didn't get the impression you were working at Steve J. gun point,
but keeping sync with webcore. So rewriting it as above is not an option
(a challange though). Note I wasn't criticising this, but stating that
webcore & kjs walk along now.
Koos
>
> --
> George Staikos
> KDE Developer http://www.kde.org/
> Staikos Computing Services Inc. http://www.staikos.net/
More information about the kfm-devel
mailing list