linux/unix系統下的顯示模式都是採用x的架構，這裡說明一下，其實我們常說的x其實不是現實裝置，而是現實協議，xserver和xclient通過x協議進行互動，由xserver對目標裝置進行顯示，然後xserver把中間的資訊和使用者反饋的資訊傳送給xclient。可以這樣形容：
xserver：負責終端裝置的顯示。並告知client發生了什麼
xclient：負責告訴xserver顯示什麼，通過server告訴的「發生了什麼」，做相應的處理。
display :
若干個螢幕(screen)以及一套輸入裝置（鍵盤和滑鼠）構成乙個display，display概念的關鍵就是有一套完整的輸入輸出。螢幕不一定必須是乙個，可以有多個，各個螢幕可以用來顯示相同的內容，也可以用來構成矩陣顯示乙個大螢幕的內容。
乙個x server可以支援多個display。
screen :
screen的層次在display之下，是x server顯示管理的次級單位。乙個screen對應乙個根視窗（root window），根視窗的大小與screen相同。如果在命令列執行"x"的話，啟動了x server，這時在螢幕上看到乙個單調的桌面，以及乙個"x"形的滑鼠，不過因為沒有啟動window manager，所以什麼都不能做，只能動動滑鼠。這時你看到的這個單調的「桌面」正是根視窗。
window :
window是比screen還要小一級的概念了。window是有樹形繼承關係的，每乙個螢幕上都對應有乙個「視窗樹」，樹的根就是root window，即根視窗，它沒有父視窗；除此之外，所有window都有父視窗。乙個視窗還可能有子視窗，但並不是必須的。
xlib把應用程式的圖形操作轉換為傳送給x server的請求，xlib與xserver之間的通訊是非同步的。當應用程式呼叫xlib與xserver通訊時，xlib不會每次都立刻把請求傳送出去，而是把請求進行排隊，放在乙個緩衝區裡，當某種條件被滿足時，再一次性地把多個請求一起發出。
如果應用程式需要馬上得到響應的話，可以呼叫類似於sync之類的xlib介面來強制清空緩衝。
因為與server之間是通過網路來通訊的，所以xlib並不能保證請求立刻就能到達server，因為可能有網路的延時；即使到達了，也不能保證server立刻就處理請求。
從server到xlib的訊息一般是event，應用需要處理這些event。同樣，event的傳遞也是非同步的，會有排隊也會有網路延時。
關於資源，當應用呼叫xlib建立某種資源時，比如window, font, pixmap, colormap, cursor或gcontext時，會返回給應用乙個id，而資源本身是在server上的。這些資源是有可能在應用之間共享的，其中是font和 cursor是自動被同一display上所有screen的所有window共享的。
關於error。有兩種，一種是呼叫xlib時的返回值錯誤，如果函式呼叫失敗的話，一般的xlib函式會返回0；另一種是error是由server發出的，在與xlib通訊中，如果發現了錯誤，按照x protocol的規範，server會發error到xlib，進而到達應用程式，應用程式需要處理這樣的錯誤。
Denoise auto encoder的乙個理解
這幾天反覆的看denoise auto encoder的解釋，尤其是geometric interpretation。作者寫道，本來的資料假定是在乙個低緯度的流行結構上，加了噪音之後，這些噪音點就距離這個流行結構要有點遠，或者不在這個流行結構上了，那麼學習的過程就會去學習在這個本來的流行結構。個人認...
erlang lists keyfind的乙個小坑
key 2 2，findreuslt lists keyfind key,1,case findreuslt of find false not find end.這段 會報沒有匹配的錯誤 原因是 key 2 2 其實 key被賦值為1.0 摔，這個基礎概念都能忘記 lists keyfind 文件...
WM DRAWITEM，DrawItem的一些總結
1 當在mfc中要對某個控制項自繪時，就需要重寫drawitem或者ondrawitem函式，要實現重繪 首先要允許重繪 1 可以在控制項屬性中設定 網上很多，自己搜吧 2 在控制項類中實現，比如我實現了class cmybutton public cbutton自己的按鈕類，然後在cmybutto...