2009-09-19 12 views
11

Ho un lavoro intensivo di CPU da fare e non voglio degradare l'esperienza dell'utente. poiché i web worker (http://ejohn.org/blog/web-workers/) sono una nuova funzionalità e non sono supportati da tutti i browser, ho pensato di aprire un iframe con un HTML + JS che farà tutto il lavoro sporco e utilizzando alcune comunicazioni tra domini per trasmettere i risultati. Purtroppo ho notato che il proprietario dell'iframe soffre del lavoro della CPU della finestra dell'iframe.Iframe viene eseguito sullo stesso thread del proprietario?

Questo comportamento è come progettato? c'è un modo per risolvere questo?

risposta

8

Un modo per simulare il multithreading è avere una funzione JavaScript che fa un po 'di lavoro, quindi chiamare lo setTimeout con la stessa funzione; allora la funzione farà un po 'di lavoro e chiamerà di nuovo setTimeout, e questo ciclo continuerà per sempre o finché non chiuderanno il fotogramma o segnalerai di smettere di funzionare. MDN has a good example of how to set this up.

Tra i timeout, Javascript non deve consumare tempo processore. Potresti dover giocare un po 'per vedere quanto dovrebbero durare i tuoi timeout - 1 ms è probabilmente troppo breve, ma 1s è decisamente troppo lungo. Un altro fattore sarà la velocità del processore del computer che esegue il lavoro, quindi potrebbe essere necessario eseguire alcuni pseudo benchmark sul lato client tramite Javascript prima di poter determinare il tempo di ritardo ogni volta.

+6

w3schools! = W3C –

+0

16ms è di aggiornamento dello schermo, vi consiglio. – Fresheyeball

4

JavaScript è a passo singolo. Le schede o le finestre separate possono essere eseguite in thread o processi separati a seconda del browser, tuttavia non è possibile comunicare tra queste finestre, quindi non è possibile utilizzare in modo esplicito più thread o processi in JavaScript.

Se è una questione di reattività dell'interfaccia utente, Rushakoff ha una buona risposta. Mentre JavaScript è in esecuzione, non avviene alcun rendering HTML e l'interfaccia utente non risponde. Usando i timeout, il controllo può essere rilasciato di nuovo sul thread di rendering/dell'interfaccia utente periodicamente, dando una sensazione più reattiva, anche se viene eseguito solo a thread singolo.

+5

>, tuttavia, non è possibile comunicare tra queste finestre 'postMessage' –

Problemi correlati