| |||||||||||||
In defense of FirefoxIn defense of FirefoxPosted May 29, 2008 15:55 UTC (Thu) by BenHutchings (subscriber, #37955)In reply to: In defense of Firefox by ekj Parent article: In defense of Firefox
In my experience, UIs are always required to be single-threaded. The locking needed to make multi-threaded UIs work will tend to kill any speed advantage. Now some time-consuming operations maybe ought to be done asynchronously so the UI thread doesn't have to wait for them. But that's easier said than done. I suspect that the problem you're seeing (and which I recognise) is due to running Javascript in the UI thread. I don't know whether it's possible to avoid that, without introducing potential for deadlocks.
(Log in to post comments)
In defense of Firefox Posted May 29, 2008 16:46 UTC (Thu) by nix (subscriber, #2304) [Link] Well, yes, but if instead of single-threading you desynchronize the (event-driven) UI from the backend processing *and rendering* work, it can get fast again. (After all, what else is an X server?)
In defense of Firefox Posted May 29, 2008 16:47 UTC (Thu) by nix (subscriber, #2304) [Link] That is, of course, instead of *multi*-threading. :)
In defense of Firefox Posted May 30, 2008 7:19 UTC (Fri) by ekj (guest, #1524) [Link] The UI may need to be single-threaded. But handling the events need not be. Control could, and should, return to the UI-thread without waiting for the event to be finished handling. Just because tab a is currently in the process of repainting, there's no reason to -not- process new events coming in. Yeah, yeah, I know -why- FF is like this. But that doesn't change the fact that this particular aspect truly sucks.
|
|||||||||||||