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/