- #MAC KEYBOARD SHORTCUT FOR CYCLING THROUGH CHROME TABS FULL#
- #MAC KEYBOARD SHORTCUT FOR CYCLING THROUGH CHROME TABS CODE#
But with newer releases, and the increasing use of Flash (I think) on the Net, it started getting slower and slower. So I switched to Opera (and shortly thereafter went from Windows to OS X). It bogged down the CPU, especially after running for awhile. I used Firefox for awhile, a couple of years back. Here's why I'm excited about/anxious for Chrome on OS/X: If you don't want to put your whole profile in RAM (there is the risk of losing important bookmarks and cookies and such if the machine unexpectidly loses all power including battery or if normal shutdown scripts otherwise fail to be callde) you could probably just copy this file in and replace it with a symlink. and even with all the relevant features turned off it seems to keep updating the file. The urlclassifier db appears to be the main culprit for the "unexpected" IO in firefox.
#MAC KEYBOARD SHORTCUT FOR CYCLING THROUGH CHROME TABS FULL#
OK so it lengthens boot time a little, but it isn't often the machine is properly shutdown anyway (it tends to be suspended when not in used instead) so doesn't do a full boot often. On bok the profile is copied in to the ram drive and on shutdown it is rsynced back to the SSD (using -inplace to reduce copy+write operations on the urlclassifier db). If you have >512Mb in your netbook you could do what I've done: I keep the entire profile in RAM (on a tmpfs filesystem). Firefox became a lot snappier once I moved my profile directory to the fast SSD. Most Eee PCs have two SSDs: a large, slow one and a small fast one.
#MAC KEYBOARD SHORTCUT FOR CYCLING THROUGH CHROME TABS CODE#
Rip out the Cocoa code from the additional processes which will make OS-X not expect the process to respond to UI events. have dummy code which responds to UI events to keep OS-X happyĢ. What is happening here is that OS-X expects the additional processes to respond to UI events and since they don't mark them as "Not Responding". In Mac, the one process per site works but if you open up Activity Monitor you will see that the additional processes are shown as "Not responding" though in reality they are. The chrome architecture is that there is a main process which handles the UI and there is one process per site which is launched but do not handle the UI. I'm not a mac dev and what i'm posting here is gleaned from several svn log entries. I'm not current on development for the Mac, but I've heard that multiple processes can't share a single window in OS/X.ĭo you happen to know how Chrome works around this, or is this not an actual limitation?
0 kommentar(er)
