用 Safari 4 的使用者要注意囉。Safari 4 有 Webpage Previews 的 Cache 設計，所以你在 Top Sites 看到的畫面基本上都是之前瀏覽過的網頁抓圖。而這個圖檔的快取目錄為以下的位置。請開啟 Terminal 後打
而裡面的檔案就是一堆 jpeg or png。如果你 cd `getconf DARWIN_USER_CACHE_DIR`com.apple.Safari/Webpage\ Previews 後再用 open 加上任一檔案，你可以發現圖檔就是網頁的 screenshot。du -sh `getconf DARWIN_USER_CACHE_DIR`com.apple.Safari/Webpage\ Previews
defaults write com.apple.Safari DebugSnapshotsUpdatePolicy -int 2然後重新啟動 Safari。然後把上面目錄中的 *.jpeg *.png 砍光光。
Opera Turbo 號稱可以加快網路瀏覽速度，當然就是壓縮瀏覽器與 server 之間的資料。原本 HTTP 協定就可以指定用 gzip 來壓縮 text-base 的 HTML/XML/JavaScript/CSS 等等。但是牽涉到 server loading 和 request 量，一般預設應該都是不會開。Firefox 的 about:config 中，network.http.accept-encoding 就是預設 "gzip,deflate"。不過 server 不壓縮，還是沒用。所以 Opera Turbo 就透過中間的 server 把東西都壓縮了再給你。但是如果是走 HTTPS，抱歉，那就沒有效果。
除了這個之外，Opera Turbo 還會壓縮圖片，意思就是用失真演算法，把圖檔的大小壓得更小，所以載入更快，如果在手持裝置上看，反正小尺寸的 LCD 看縮小的圖可能還能接受。desktop PC 的話，用起來發覺失真得還蠻嚴重的。
至於 Turbo server 是在哪？用 UserAgent.org 的 What is my IP address？一看，Your IP Address is: 64.255.180.34。簡單 traceroute 後是 r02-02.opera-mini.net。所以就是透過 Opera 本身自家的 server 幫大家壓縮傳輸量，但是 RTT 好像蠻高的。或許以後各大家 ISP 都部署之後，就不會那麼高。但是如果拿來看 flicr、picasa、wretch、diggirl，應該會蠻吐血的。所以美好的東西是值得等待的 XD。話說 Opera Turbo 網頁載入快雖快，但是一堆標準和 JavaScript 都打不贏 Firefox/Safari，這...
CrossOver 把 Google Chrome 瀏覽器的開發版本 Chromeium，以及 wine 1.1.4 直接包裝成完整的執行檔 CrossOver Chromium。以下是執行畫面，背後的程式是 Firefox 3.1 beta。
下載後，拖拉到桌面或應用程式裡面，就可以馬上執行由 wine 模擬起 windows 環境執行 Chrome 瀏覽器的功能。不過這當然是非常非常嘗鮮的玩法，因為在 wine 裡面執行的 Chrome 會加上參數 --no-sandbox --in-process-plugins，最主要的 multile processes 優點就沒有啦。如此一來，醜醜的 windows 視窗外框，不是很漂亮的 X11 Font Rendering，只能跑 single process 的 multithread，優點大概只剩 V8 Engine 的速度。不過 Firefox 3.1 beta 是 TraceMonkey (記得把 about:config 的 javascript.options.jit.content 和 javascript.options.jit.chrome 打開才有效) 也差不到哪去; Safari 4.0 preview 是 WebKit 搭配 SquirrelFish，既然都是用 WebKit，就直接跑 Safari 就差不多了。
因為 google chrome 的 mac 版本尚未推出, 因此只能在 windows 上一探究竟和體驗. 但是某公司電腦作業系統不在支援範圍 (XP/Vista), 因此只得透過 Virtual Box 的 Windows XP 來體驗. 況且 CPU 不是 Vx 技術, 執行起來速度還可以接受, 但是實際上宣稱的 JavaScript 效率就無從實際體驗, 只能透過別人的benchmark來了解效能.
基本上用起來很不錯, 對於中文輸入支援也很好, 簡潔的畫面和 google 風真的很不錯. 另外在開發者選單裡面有工作管理員, 可以看到每個網頁的 tab 所佔用的資源和CPU loading 真的是很新鮮. 不過還沒遇到過網頁當掉, 然後直接把某個tab給殺掉的用法.
基本上還是看mac版推出後有什麼跟Safari/Firefox上的效能差異,畢竟Firefox雖然也是native程式,但是那堆message pump framework, XPCOM, 搞得Firefox又肥又大,GUI 效能上好像沒有Safari快.
SafariPowerToy 又改版了, 這次主要直接增加詞彙的轉換而不全只是每個中文字的字形的轉換. 因為會變成類似正面表列法, 有支援的詞, 或是可以一對一轉的個別字才會轉換, 所以有可能會有些漏網之魚的簡體字詞彙中有個別的字形沒有轉換, 但是數量應該很少, 至少瀏覽頁面已經大幅的呈現正體/簡體以符合使用者閱讀習慣. 新一版是 0.2.5, 一樣是 intel leopard build.
在 Safari 的設定裡面，只能自訂 Standard Font 和 Fixed-width Font。其他各家的瀏覽器通常可以設定 Serif 和 Sans-serif 的字體。而 Safari 似乎一定都是用 Times 字體當 Serif。如果要自行設定的話，目前 GUI 上找不到任何地方可以改。但是透過修改設定檔的方式，其實是可以自訂這些字體。
首先開啟 ~/Library/Preferences/com.apple.Safari.plist 這個檔案，如果是文字檔格式就可以用任何文字編輯器編輯。或是使用 Property List Editor 編輯。然後新增這些 key value 組合。WebKitSansSerifFont 代表的是 Sans-Serif 字體；WebKitSerifFont 代表的則是 Serif 字體。
然後結束 Safari 之後，重新開啟，就會有自行設定的字體。
根據 Surfin' Safari 最新的文章和測試，新的 JavaScript 引擎，代號為「SquirrelFish」的 interpreter，讓 Safari 的速度加速為 WebKit 3.1 的 1.6 倍（SunSpider benchmark suite）。可望讓 Firefox 3.0 引以為傲的速度不再專美於前。
繼續閱讀
最近消失的十億很熱門，但跟主題無關係，雖然電腦上用掉十億很簡單(1GB=1,073,741,824 bytes）。在 Firefox 的網址列打 about:cache，可以看到 memory 和 disk 的 cache 容量和消耗。
一定會有人好奇，怎麼 memory cache 的 Maximum storage size 是 5000 KiB（這是我設的，因個人設定或電腦記憶體容量而定），結果 Storage in use 反而比 Maximum 還大。如果是 disk 部份就正常，不會超過 Maximum storage size。這個原因是，記憶體的 cache 有部份會存放的是「解壓縮」後的圖片，例如 jpeg、png 這類解開通常容量都不小。所以實際上 memory cache 的檔案可能沒有超過 5000 KiB，但是 cached 未壓縮圖片檔容量卻已經超過這個容量。點選如圖片上面的 List Cache Entries 就會列出每個詳細資料，我的範例如下，
一定會有人好奇例如 http://css.funp.com/base/css/v3/nt.png 這個不是照片的圖檔有 3,840,000 bytes，約 3.66MB。第二個 http://css.funp.com/base/css/_4939/B0.png 也不遑多讓，有近 3MB 的空間。實際上，第一個 nt.png 檔案只有 44.33 KB (45392 bytes) 這麼大，但是解析度是 400px × 2400px，也就是 400×2400×4 (32bits color) = 3,840,000 bytes，沒錯，就是上面的大小。只要有 10 個類似的東西，加上 firefox 本身程式內部用量，消耗的記憶體馬上破百不是問題。
當然這是拜 CSS 之賜，可以用 clip 的方式來選擇顯示範圍的圖片，這樣好處當然是瀏覽器只要 cache 一個小圖檔（壓縮後不大），也減少 http server request 和檢查 expire 次數。所以網頁中看到很多用到小圖的地方，可能是圖檔中不同的部位去選擇要呈現的範圍。但是，事實上，圖片上蠻多空白（不會用到）的地方，當然這些空白的地方，電腦還是要花記憶體的空間去儲存地。
後記：為啥拿 funp.com 上面的 background png 來舉例？因為，剛好大小榮登上面排行榜前幾位，純屬巧合 :P。
利用 WebKit 所提供的 SunSpider benchmark 來測試 Mac OS X 上各家的瀏覽器裡面 JavaScript 的效能。
測試平台是 Mac OS X 10.5.2 Leopard on Apple iBook 1.2Ghz。瀏覽器包含正式版的 Firefox 2.0.11、Safari 3，測試版的 Firefox 3.0b5pre、WebKit Nightly Build、Opera 9.5beta。測試結果看來都是測試版的瀏覽器大獲全勝，其中又以 Firefox 3.0b5pre 最為突出，一改 Firefox 讓人詬病的速度問題。再來是 WebKit，效能上只輸 Firefox 3b5pre 一點，很難想像用他來作為核心的 Safari 竟然會有這麼大的差距。接著是 Opera 9.5beta，雖然他們號稱速度上是第一，可能整體上來說沒錯，但是畢竟在單純 JavaScript 上沒有這麼好的成績。敬陪末座的就是舊版 Gecko 核心的 Camino 1.5 和 Firefox 2.0.11。
在 Firefox 3b5pre 釋出後不到一天，一些 Addons 已經更新支援最新的 Firefox 3 beta nightly build，例如 Adblock Plus。
Firefox 3 的第五個測試版本出來了，舊的測試版用戶可以透過 Update 直接升級。但是升級的缺點就是一些 addons 都不能用，其實應該是相容，但是受限版本檢查限制，全部不能用。尤其我最重要的 adblock plus 一失效的話，yahoo、udn 等等廣告全部跑出來了，花花綠綠的真是不習慣。
順便做了 WebKit 上得 Sunspider 效能測試，來試驗現在各家版本的 JavaScript 效能。
在 WebKit based 的瀏覽器上，瀏覽器顯示的字型是以 International Pane 所選擇的地區順序設定來挑選 fallback 字型。（當該字型沒有該字的 Glyph，則繼續選用候選字型）所以常常可以在某些網頁上看到本來是細明體的字型，穿插著黑體字。或者是在黑體字中間，穿插著粗細或高低不一的字。尤其是在 firefox 瀏覽器上常常看得到。
這個原因是 firefox 本身有 unicode 地區的編碼分類，以及各種語系之間使用不同的字型因素。像是台灣中文是 Apple LiGothic Medium，日文是 Hiragino Kaku Gothic，韓文是 Apple Gothic。而當某些 unicode 網頁中出現某些字型，可能會依照該字碼挑選地區來選擇字型。或者看起來像是繁體的中文字，卻挑選了日文的字型來繪製。而這些字型的挑選，雖然在程式已經提供了讓使用者可以挑選各地區的字型，但是真正繪出文字的字型可能不是使用者希望的。所以最好的方法就是，在這些 CJK 語系地區使用統一的字型，而且該字型又有幾近完整的 unicode glyph 資料，才不會到時候缺字又要使用其他字型補字。
在 Mac OS X 上，有一個字型叫做 Arial Unicode MS。雖然名字有 MS 但不是微軟做的，是一家 Monotype 字型公司。英文字型看起來是 Arial，亞洲字體看起來像是黑體（雖然經過 Apple AntiAlias後看起來沒有黑體那麼黑和清晰）。用起來在 firefox 上效果不錯，對於本身我自己習慣看 Sans-Serif 字體來說，是相當好的選擇，就連 Safari 預設字型都設成這個字型。
MacOSX 上的 Safari 出了 3.0 beta, 更驚人的是出了 windows 版本. 雖然說支援 Windows XP/Vista, 但是 Windows 2000 還是可以安裝, 也跑得很好. 只是說真的是 beta 會經常 crash. 但是看到的使用畫面, 真是驚為天人, 字型跟 Mac 上的細緻和精美程度完全讓 windows 其他字形沒得比, apple 在人機介面與互動方面能力果然厲害,. 而且我也沒有安裝這些什麼黑體字型, 真的是很好玩. 而且在我的 win2k 上也沒有出現別人 screenshot 的黑體夾雜標楷或是細明的畫面; 另外 windows 的 menu bar 在 window 上方, 用起來還真不習慣; preferences 的 Appearance 裡面的 Font smoothing, 也出現在 Safari 裡面的 Appearance, 表示 apple 自己用自家的 font rendering engine, 不用 MS anti alias/clear type.
另外隨著 windows 版的推出, opera watch 也寫出新的文章, 質疑 safari 的速度跟記憶體消耗能力. 長久以來, opera 就致力於這方面的努力, 並以 IE & Firefox 為箭靶. Safari for Windows 的推出, opera 又可以多一項正式的箭靶. 我承認 opera 真的快, 但是記憶體用量的確也比 firefox 省, 但是真的很省我很質疑, 因為就有用到爆出幾百 MB. 只要是軟體就有 bugs, 就可能有 leakages. 唯一辦法就是用久了一段時間重開. 另外 opera 在 mac 上的中文字體因為用不同的字型而產生上下標的中文結果, 還有某些 firefox 可以看的網頁 opera 甚至不能看. 所以能寫的就拼命評比 speed & memory, 稱讚自家 opera 多棒 :P, 不過有比較才有進步.
Update: 常常在 form input 輸入東西時候掛點, 什麼 DummyWindowless 的, 靈機一動把 auto fill 都關掉, 終於比較正常了.
Update 2: 似乎不支援 https =_=
更新了 WebKit nightly build，結果使用出現一些小問題，其實也不是大地雷。第一個是，可以看到網頁內容但是上面的連結或控制項卻無法用滑鼠點選。關掉 tab 或是 reload 都無效，只有重開 Safari。第二個地雷是，本來可以用的 google spreadsheets，現在進去變成整頁的觀看模式，無法編輯。 第一個是不定時炸彈，但是幾乎很少遇到；第二個問題就算用原廠 Safari 的 WebKit 也無法用 google docs。再來翻翻看有沒有以前的 nightly build history 好了，看看之前的 nightly build version 再不再。
WebKit 當然就是 Safari 的 kernel，以前使用 WebKit nightly build 的經驗是，偶而看普通的網頁就會當掉，實在受不了所以只能忍耐用 Apple build 的 WebKit 版本。最近因為在玩 Yahoo! Fantasy baseball，常常會去看一些畫面 layout 比較複雜的頁面和 mlb.com，比較驚訝的是最近開 top 一看發現 Safari 的 RPRVT (Private Memory) 竟然高達 697MB，quit 掉 Safari 後就撿回來不少記憶體空間。第一次遇到這種情況，之前最高也是才 300MB 出頭。所以自己的使用習慣是用一段時間的 Safari 就會 quit 然後重新啟動。不過說也奇怪，把 WebCore cache disable 以及自己寫的 Safari Plugin 來設定 NSURLCache 的 memory/disk size 竟然也限制不了 Safari 一直長大的問題。所以這個問題也就無解，並且不了了之。 最近使用 WebKit 的經驗是感覺蠻穩定了，而且 memory leakage 似乎不會那麼嚴重，至少把頁面該關的都關掉後，就回復到蠻基本的 RPRVT 用量。並且至少新的 WebKit 也可以上 docs.google.com，就不用再開 Camino 來應付。缺點大概就是一些 Safari Plugin 不能用，比如說 SafariBlock，就無法阻擋廣告的出現。
這個 Camino 版本是從每天的 mozilla source code CVS 所更新和編譯出來的 trunk 版本。最主要的地方是修改了 gecko 的 thebes 中的 ATSUI font fallbacks。直接使用 hard code 的「儷黑Pro」、「Apple LiGothic Medium」、和「STHeiti」來當作預設的字形 fallbacks。感覺起來比較好看多了，總比預設不知哪來的 fallback 順序使用的日文字形和產生出來的粗細不一字體好太多了，而且跟 Safari 比起來，也比較類似。
不過 trunk 版本總是有些風險和代價，目前的 gecko 1.9 似乎還有一些 layout 上的問題，cairo 針對 Quartz Surface 和 ATSUI 也還在實驗版本階段。自己使用上起來似乎也沒有 coredump 產生，但是有些排版和 Cocoa widgets 會消失倒是不知道原因。或許就是 trunk 上的問題。有些網頁上的顯示和使用反而更慢，例如使用 google spreadsheet，在上面打字的速度真是慢到暴，但是其他網頁的輸入感覺卻蠻正常的。有興趣的人可以試用看看，不過有些網頁上顯示的問題可能也不是短時間能解的，畢竟我只是小小修改 ATSUI font fallbacks 部份，頂多顯示的字形不太一樣而已，其他的可能也幫不了什麼忙。
Firefox 3.0 的 nightly trunk 使用了 gecko 1.9 新的 layout engine，對於中文方面的 glyphs rendering，還是覺得非常不好看。在 Safari，不論是 zh-TW, UTF-8 裡面的中文似乎都是使用 LiHei Pro 或是 Apple LiGothic Medium。相反的 Firefox 只要是非 zh-TW, Big5 的網頁，似乎都會去用日文字形裡面的中文字，看起來就有很大差異。缺字的話還需要 fallback 找到其他字形去替補，因此各種混雜家錯的字形看起來真是不好看。對於 Firefox 3 的 gecko，給他寫了 default 的 fallback fonts，像是 Apple LiGothic Medium，LiHei Pro，簡體用 STHeiti，看起來畫面像 Safari 產生的文字，感覺好多了。
圖左邊是 Minefield，也就是 Firefox nightly trunk；右邊是 GranParadiso。
Firefox 3.0 的 Gecko 1.9 已經將 text rendering 的工作，統一交由跨平台的 Cairo 處理。另外有一篇 Cairo bets Safari? 的文章，內有 Camino、Safari、以及新的 Camino trunk 的 screenshot，看起來 Cairo 的清晰程度和 Quality 蠻不錯的。另外新的 Camino with Cairo 的 nightly trunk 可以下載來試試看。
google spreadsheets 更新了，變成 1.1.5g，又有些新的 features。不過在 mac os x 上使用的幾個缺點就是只能用 Firefox 或是 Camino 來開啟。Safari 和 Opera 都不支援（雖然gmail、calendar都能用這兩個browsers）。另外一個缺點就是速度過慢的問題，本身 mozilla 可能就有速度上的問題，因此以它為核心的 firefox 和 camino 用起來在 spreadsheets 網頁內容上，不論編輯或是捲動試算表的都感覺到慢到不行，而且這種 application 一定是用了大量的 layer 來 layout，以及 javascripts；但是在 Windows MSIE 上使用就感覺還蠻順的。另外一方面大概就是為了 real time sharing，連一個小 cell 不含公式的輸入都要透過網路。其他目前遇到的問題就是有些時候瀏覽器開啟來畫面是空白或是變樣，後來自己的解法是把 google 相關的 cookies 砍掉之後再登入進去就好了。
雖然在 mac 上缺點好像多了一點，但是把一些資料存在遠端機器上，到哪邊用哪種機器都可以看或修改還是比較方便。
發表文章
所有留言
