Forcing windows to update during processing

[John Peat]

I have a node webkit app which opens another window (hidden) - events on the content on the new 'hidden' window then add stuff onto the visible 'app' window (e.g. it's a scraping-style app).

Problem is - this takes a while (10-15 seconds) during which nothing happens from the user's perspective.

If I breakpoint the process with the debug window open, I can update a status value - if the 'hidden' window is visible I can scroll it etc. - but 'normal processing' does not cause any updates/scrolling to happen until it's all completed (I guess because no user interaction has occurred, so webkit doesn't realise anything has changed!?)

Any ideas or tricks that can force webkit to update content as a result of what amounts of background processing - when the user is just sitting idle?

[John Peat]

Just to make this clearer - imagine you ran a long loop updating the value of a SPAN from 1 - a big number, webkit would only show the final 'big number' and not all the values on the way there - is there a way to make it show ALL the values as they update?

[LZAntal]

Hi

I use web workers for this. They are perfect for this kind of apps. Basically add the long running code into an other JS file and make it into a web worker by adding the required "message" handlers. Then call that from your visible window and listen for messages. In your long running web worker, ever time you want to print a message to the user just send a message back before you start an other long running task. Also this does not block your visible window event loop so you can display or do other things as well.

Hope it helps

Laszlo

http://twitter.com/LZAntal

--
You received this message because you are subscribed to the Google Groups "node-webkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to node-webkit...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[John Peat]

I'm already ensuring processing isn't happening 'foreground' as everything is triggered via setTimeout - and everything belongs to the hidden window and not the user's application (foreground window) 

Your comment on webworkers reminded me of something tho

My main processing loop is recursive (as it's DB access is async, it cannot just loop).  Although that process is started with setTimeout, it's recursion means it's a long-running single process and it does seem that processes of that sort simply 'lock out' webkit from updating until they're done.

I changed self-referencing call to use setTimeout rathern than call the function directly - so now, each recursion is a separate thread and the old thread dies - even if the timeout 'delay' is 1ms, it's enough to allow webkit to refresh content, so my status message/progress bar updates as I'd like it to!

Downside is that it's probably slower - with a small delay between each step - but better the user see it working a bit longer than see nothing for 10+ seconds...

Thanks for the idea!