Các chương trình quản lý phòng máy hiện nay ở Việt Nam - 7
lượt xem 5
download
Dòng cuối là gọi phương thức SetWindowPos như cách 1. Có một lưu ý nhỏ ở đây là ta vẫn có thể sử dụng thay thế hàm SetWindowPos bằng một hàm API khác là MoveWindow. Số byte 4 Type trị] U32 dạng mã hóa 0 mã hóa thô (raw) 1 mã hóa CopyRect 2 mã hóa RRE 4 mã hóa CoRRE 5 mã hóa Hextile 16 mã hóa ZRLE 0xffffff11 mã hóa giả Cursor 0xffffff21 mã hóa giả DesktopSize Những mã hóa được đăng kí 6,7,8 khác 0xffffff00 tới 0xffffff10 zlib, tight, zlibhex 0xffffff12 tới 0xffffff20 0xffffff22 tới 0xffffffff các...
Bình luận(0) Đăng nhập để gửi bình luận!
Nội dung Text: Các chương trình quản lý phòng máy hiện nay ở Việt Nam - 7
- Số byte Type [Giá Mô tả trị] 1 U8 2 dạng thông điệp 1 độn 2 U16 số lượng các mã hóa theo sau là các số lượng các mã hóa gởi lặp đi lặp lại : Số byte Type [Giá Mô tả trị] 4 U32 dạng mã hóa 0 mã hóa thô (raw) 1 mã hóa CopyRect 2 mã hóa RRE 4 mã hóa CoRRE 5 mã hóa Hextile 16 mã hóa ZRLE 0xffffff11 mã hóa giả Cursor 0xffffff21 mã hóa giả DesktopSize Những mã hóa được đăng kí 6,7,8 khác 0xffffff00 tới 0xffffff10 zlib, tight, zlibhex 0xffffff12 tới 0xffffff20 0xffffff22 tới 0xffffffff các tùy chọn của tight 4.1.6.3.4 FrameBufferUpdateRequest Báo cho server biết client quan tâm đến một khu vực trong vùng đệm khung xác định bằng x-position, y-position, width và height. Server thường hồi đáp FrameBufferUpdateRequest bằng cách gởi một FramebufferUpdate. Chú ý rằng tuy 151
- là như thế một FramebufferUpdate có thể gởi để hồi đáp nhiều FramebuferUpdateRequest. Server ngầm định rằng client giữ một bản sao của mọt phần trong vùng đệm khung mà nó quan tâm. Điều này có nghĩa là server thông thường chỉ cần gởi các cập nhật tăng dần cho client. Tuy thế, nếu vì vài nguyên nhân nào đó client đã mất nội dung khu vực nó cần, thì client có thể gởi một FramebufferUpdateRequest với incremental đặt bằng 0 (sai). Việc này yêu cầu server gởi cả nội dung của cả khu vực càng sớm càng tốt. Khu vực sẽ không cập nhật khi dùng mã hóa CopyRect. Nếu client đã không mất nội dung khu vực nó quan tâm, thì nó sẽ gởi một FramebufferRequest với incremental đặt khác 0 (đúng). Nếu và khi có bất kì sự thay đổi tới khu vực xác định của vùng đệm khung, server sẽ gởi một FramebufferUpdate. Chú ý rằng có một chu kỳ bất giữa việc gởi và nhận các FramebufferUpdateRequest và FramebufferUpdate. Trong trường hợp là một client nhanh (cấu hình mạnh), client có thể muốn điều chỉnh tần suất gởi các FramebufferUpdateRequest tăng dần để tránh lấn chiếm đường mạng. Số byte Type [Giá Mô tả trị] 1 U8 dạng thông điệp 1 U8 incremental 2 U16 x-position 2 U16 y-position 2 U16 width 2 U16 height 4.1.6.3.5 Sự kiện phím 152
- là khi một phím nhấn hoặc thả. Cờ down là khác 0 (đúng) nếu phím đang được nhấn, 0 (sai) nếu phím đang thả. Phím tự nó cũng được dùng để xác định giá trị “keysym” định nghĩa bởi Hệ thống X Windows. Số byte Type [Giá Mô tả trị] 1 U8 4 dạng thông điệp 1 U8 cờ down 2 độn 4 U32 phím Dành cho hầu hết các phím, “keysym” giống với giá trị ASCII tương ứng. Để biết chi tiết, xem The Xlib Reference Manual, phát hành bởi O’Reilly & Associates, hay xem file tiêu đề từ bất kỳ một cài đặt của hệ hống X Windows. Một số phím thông dụng khác: 153
- Tên phím Giá trị keysym BackSpace 0xff08 Tab 0xff09 Return hay Enter 0xff0d Escape 0xff1b Insert 0xff63 Delete 0xffff Home 0xff50 End 0xff57 Page Up 0xff55 Page Down 0xff56 Left 0xff51 Up 0xff52 Right 0xff53 Down 0xff54 Tên phím Giá trị keysym F1 0xffbe F2 0xffbf F3 0xffc0 F4 0xffc1 … … F12 0xffc9 Shift (trái) 0xffe1 Shift (phải) 0xffe2 Control (trái) 0xffe3 Control (phải) 0xffe4 Meta (trái) 0xffe7 Meta (phải) 0xffe8 Alt (trái) 0xffe9 Alt (phải) 0xffea 154
- Việc thông dịch keysym khá phức tạp. Nhằm để hoạt độn phối hợp rộng rãi càng nhiều càng tốt, cần tuân theo các chỉ dẫn sau: • “Shift state” (i.e. khi các phím shift được nhấn) chỉ nên dùng như một hướng dẫn khi biên dịch một keysym. Chẳng hạn, trên một bàng phím US ký tự ‘#’ được nhấn kèm theo shift mới được, còn bàn phím UK thì không. Một server với một bàn phím US nhận một ký tự ‘#’ từ một client với một bàn phím UK sẽ không được gởi với bất kỳ phím shift nhấn nào cả. Trong trường hợp đó, server có thể cần “giả” nhấn shift trên hệ thống cục bộ của nó, nhằm để lấy ký tự có hay không shift, ví dụ, một ký tự ‘3’. • Việc phân biệt ký tự chữ hoa chữ thường là rất quan trọng. Điều này không đúng với một số bàn phím trong các Hệ thống X Windows xử lý giống nhau với cả chữ hoa chữ thường. Chẳng hạn, server nhận được một keysym ‘A’ hoa mà không kèm theo nhấn shift thì nên thông dịch là một ký tự ‘A’ hoa. Một lần nữa, điều này cũng có thể cần làm “giả” cục bộ nhấn shift. • Server nên bỏ qua việc “khóa” các keysym chẳng hạn CapsLock và NumLock khi có thể. Thay vào đó chúng nên được thông dịch mỗi keysym dựa vào ký tự tùy theo trường hợp của nó. • Không giống Shift, trạng thái của các phím tinh chỉnh như Control và Alt cần phải lấy để chỉnh sửa việc thông dịch các keysym khác. Chú ý rằng sẽ không có những keysym cho ký tự điều khiển ASCII ví dụ như ctrl-a – các tổ hợp phím này được phát sinh qua khung nhìn bằng cách gởi một nhấn Control và một nhấn ‘a’. • Trên khung nhìn khi các phím tinh chỉnh như Control và Alt có thể cũng được dùng để phát sinh các keysym dựa trên ký tự, các khung nhìn có thể cần gởi thêm các sự kiện “thả” nhằm để keysym được thông dịch chính xác. Chẳng hạn, trên một bàn phím PC Đức, ctrl-alt-q sẽ tạo ra ký tự ‘@’. Trong trường hợp này, khung nhìn cần gởi các sự kiện thả “giả” cho Control và Alt 155
- nhằm để ký tự ‘@’ thông dịch đúng (ctrl-alt-q có thể có nghĩa gì đó hoàn toàn khác đối với server). • Không có chuẩn chung cho “tab lùi” trong Hệ thống X Windows. Trên một số hệ thống shift-tab cho keysym “ISO_Left_Tab”, trên số khác nó cho ra keysym “BackTab” dùng riêng và trên số còn lại nó cho “Tab” và các ứng dụng lấy từ tình trạng phím shift để biết nó là tab lùi hay tab tiến. Trong nghi thức RFB cách tiếp cận sau được ưa chuộng hơn. Khung có thể phát sinh một Tab kèm shift nhấn hơn là một ISO_Left_Tab. Tuy thế, để tương thích với một số khung nhìn có sẵn, server cần nhận ra ISO_Left_Tab như là một Tab kèm shift nhấn. 4.1.6.3.6 Sự kiện trỏ cho biết con trỏ có di chuyển hoặc nút trỏ được nhấn hoặc thả. Con trỏ đang ở vị trí (x-position, y-position), và trạng thái của các nút 1 đến 8 tính theo thứ tự từ bit 0 đến 7 của button-mask, giá trị bit 0 là thả, giá trị bit 1 là nhấn Trên một mouse chuẩn, các nút 1, 2 và 3 tương ứng cho các nút trái, giữa và phải trên mouse. Trên mouse có wheel (bộ phận scroll), mỗi bước quay wheel lên tương ứng với việc nhấn và thả nút 4, và mỗi bước quay wheel xuống tương úng với việc nhấn và thả nút 5. Số byte Type [Giá trị] Mô tả 1 U8 5 dạng thông điệp 1 U8 button-mask 2 U16 x-position 2 U16 y-position 4.1.6.3.7 ClientCutText 156
- Client có dạng văn bản mới ISO 8859-1 (Latin-1) trong vùng cắt văn bản của nó. Hết mỗi dòng biểu thị bởi ký tự đơn linefeed / newline (sang dòng mới, giá trị 10), không cần giá trị carriage-return (trở về đầu dòng, giá trị 13). Hiện tại chưa có cách chuyển đổi văn bản ngoài bộ ký tự Latin-1. Số byte Type [Giá trị] Mô tả 1 U8 6 dạng thông điệp 3 độn 4 U32 độ dài chuỗi Độ dài chuỗi mảng U8 văn bản 4.1.6.4 Các thông điệp từ server đến client 4.1.6.4.1 FramebufferUpdate Một cập nhật vùng đệm khung gồm một tuần tự các chữ nhật dữ liệu điểm ảnh client phải vẽ lên vùng đệm khung của nó. Thông điệp được gởi hồi đáp cho một FramebufferUpdateRequest từ client. Chú ý rằng có một quá trình bất tận việc gởi và nhận các FramebufferUpdateRequest và FramebufferUpdate. Số byte Type [Giá trị] Mô tả 1 U8 0 dạng thông điệp 1 độn 2 U16 số các chữ nhật 157
- đi kèm theo là số các chữ nhật dữ liệu điểm ảnh. Mỗi hình chữ nhật bao gồm: Số byte Type [Giá trị] Mô tả 2 U16 x-position 2 U16 y-position 2 U16 width 2 U16 height 4 U32 dạng mã hóa 0 mã hóa thô (raw) 1 mã hóa CopyRect 2 mã hóa RRE 4 mã hóa CoRRE 5 mã hóa Hexile 16 mã hóa ZRLE 0xffffff11 mã hóa giả Cursor 0xffffff21 mã hóa giả DesktopSize Các mã hóa khác 6, 7, 8 zlib, tight, zlibhex 0xffffff00 đến 0xffffff10 0xffffff12 đến các tùy chọn của tight 0xffffff20 0xffffff22 đến 0xffffffff 158
- tiếp theo là các dữ liệu điểm ảnh trong dạng mã hóa đã xác định. Xem phần 4.3.6.5 cho định dạng dữ liệu cho mỗi mã hóa và xem phần 4.3.6.6 cho định nghĩa của mã hóa giả. 4.1.6.4.2 SetColourMapEntries Khi định dạng điểm ảnh dùng “bản đồ ảnh”, thông điệp này báo cho client biết những giá trị điểm ảnh xác định trước cần ánh xạ vào các cường độ RGB. Số byte Type [Giá trị] Mô tả 1 U8 1 dạng thông điệp 1 độn 2 U16 màu đầu tiên 2 U16 số lượng màu tiếp theo là lặp đi lặp lại số lượng màu các dữ liệu như sau Số byte Type [Giá trị] Mô tả 2 U16 đỏ 2 U16 xanh lá 2 U16 xanh dương 4.1.6.4.3 Bell Bật loa chuông nếu client có. Số byte Type [Giá trị] Mô tả 1 U8 2 dạng thông điệp 4.1.6.4.4 ServerCutText Client có dạng văn bản mới ISO 8859-1 (Latin-1) trong vùng cắt văn bản của nó. Hết mỗi dòng biểu thị bởi ký tự đơn linefeed / newline (sang dòng mới, giá trị 10), 159
- không cần giá trị carriage-return (trở về đầu dòng, giá trị 13). Hiện tại chưa có cách chuyển đổi văn bản ngoài bộ ký tự Latin-1. Số byte Type [Giá trị] Mô tả 1 U8 6 dạng thông điệp 3 độn 4 U32 độ dài chuỗi Độ dài chuỗi mảng U8 văn bản 4.1.6.5 Các mã hóa 4.1.6.5.1 Mã hóa thô Mã hóa đơn giản nhất là dữ liệu điểm ảnh thô. Trong trường hợp này, dữ liệu chứa width x height các giá trị điểm ảnh (với width và height là chiều dài và chiều rộng của hình chữ nhật). Các giá trị chỉ đơn giản biểu thị các điểm ảnh theo thứ tự đường quét từ trái sang phải. Mọi client RFB đều phải bắt buộc hiểu dữ liệu điểm ảnh dưới dạng mã hóa thô, và các server chỉ gởi dạng mã hóa thô nếu client không chỉ rõ dạng mã hóa. Số byte Type [Giá Mô tả trị] width x height x bytesPerPixel mảng PIXEL các điểm ảnh 4.1.6.5.2 Mã hóa CopyRect Mã hóa CopyRect (sao chép hình chữ nhật) là dạng mã hóa rất đơn giản và hiệu quả được dùng khi client đã có sẵn dữ liệu điểm ảnh như thế trong vùng đệm khung của nó. Mã hóa trên đường truyền chỉ đơn giản gồm 2 tọa độ X, Y. Hai tọa độ này cho biết vị trí trong vùng đệm khung mà client sẽ sao chép hình chữ nhật dữ liệu điểm ảnh vào. Điều này được ứng dụng trong nhiều tình huống, hiển nhiên nhất là việc người 160
- dùng dời một cửa sổ trên màn hình, và khi nội dung của cửa sổ bị cuộn. Một ứng dụng ít thấy hơn là tích gợp việc việc vẽ văn bản hay lặp lại các mẫu. Một server thông minh sẽ có thể gởi tường minh một mẫu chỉ một lần, và biết vị trí trước đó của mẫu trong vùng đệm khung, gởi từ từ các xuất hiện của mẫu sử dụng mã hóa CopyRect. Số byte Type [Giá Mô tả trị] 2 U16 src-x-position 2 U16 src-y-position 4.1.6.5.3 Mã hóa RRE RRE viết tắt của rise- and-run-length encoding (mã hóa chiều dài tăng trưởng và chạy) và như tên ngầm định của nó, mã hóa cần một mã hóa chiều dài chạy (thay đổi) tương tự hai chiều. Các hình chữ nhật mã hóa RRE đến client trong dạng mà có thể dựng hình ngay lập tức và hiệu quả bởi các engine đồ họa đơn giản nhất. RRE không thích hợp với các máy desktop phức tạp, nhưng có thể hữu dụng trong một số trường hợp. Ý tưởng căn bản đằng sau RRE là phân vùng một hình chữ nhật dữ liệu điểm ảnh thành các vùng hình chữ nhật con (các hình chữ nhật phụ), mỗi cái trong chúng chứa các điểm ảnh của một giá trị đơn và hợp của những cái tạo thành vùng hình chữ nhật ban đầu. Việc phân vùng gần như tối ưu của một hình chữ nhật cho trước thành các hình chữ nhật con thì khá dễ tính. Mã hóa bao gồm một giá trị điểm ảnh nền, Vb (đặc trưng cho hầu hết giá trị điểm ảnh trong hình chữ nhật) và một biến đếm N, kèm theo một danh sách N các hình chữ nhật, mỗi cái chứa một tuple với v ( Vb ) là giá trị điểm ảnh, (x, y) là vị trí tọa độ của hình chữ nhật con tương ứng với góc trên trái của hình chữ nhật, và (w, h) là chiều rộng và dai của hình chữ nhật con. Client có thể dựng hình chữ nhật ban 161
- đầu bằng cách vẽ một hình chữ nhật tô bằng gía trị điểm ảnh nền và sau đó vẽ hình chữ nhật tô dựa theo các hình chữ nhật con. Trên đường truyền, dữ liệu được bắt đầu với tiêu đề: Số byte Type [Giá Mô tả trị] 4 U16 số lượng hình chữ nhật con PIXEL số byte mỗi điểm ảnh giá trị điểm ảnh nền Đi kèm là số lượng hình chữ nhật con các instance (hiển thị) của cấu trúc: Số byte Type [Giá trị] Mô tả PIXEL số byte mỗi điểm ảnh giá trị điểm ảnh hình chữ nhật 2 U16 con 2 U16 x-position 2 U16 y-position 2 U16 width height 4.1.6.5.4 Mã hóa CoRRE Chú thích: mã hóa CoRRE đã bị bỏ - Hextile là mã hóa tốt hơn dùng cùng ý tưởng. CoRRE (Compact RRE) là một biến thể của RRE, với việc chúng ta sẽ bảo đảm hình chữ nhật lớn nhất được gởi không quá 255x255 điểm ảnh. Một server muốn gởi một điểm ảnh lớn hơn thế chỉ đơn giản là cắt nhỏ ra và gởi các hình chữ nhật RFB nhỏ hơn. Trong mỗi hình chữ nhật nhỏ hơn đó, một byte đơn sẽ biểu thị các chiều của hình chữ nhật con. Với một desktop đặc trưng, điều này cho nén tốt hơn cho RRE. Thực tế, việc nén tốt nhất đạt được khi chúng ta giới hạn hơn nữa kích 162
- thước hình chữ nhật – cài đặt hiện tại đang dùng tối đa 48x48. Điều này có được là bởi vì các hình chữ nhật không được mã hóa tốt (tiêu biểu là những cái chứa dữ liệu hình ảnh) được gởi dạng thô, trong khi những cái khác mã hóa tốt gởi theo CoRRE. Kícht thước tối đa hình chữ nhật càng nhỏ, việc mã hóa càng tốt (ít hình chữ nhật thô hơn). Với RRE, cả hình chữ nhật gốc một là gởi theo RRE, hai là gởi theo thô. Tuy nhiên, vì có một số lượng nhất định hao phí gánh chịu từ mỗi hình chữ nhật RFB, làm cho kích thước tối đa hình chữ nhật quá nhỏ (và từ đó làm tăng số lượng hình chữ nhật RFB), dẫn đến việc nén kém hiệu quả hơn. Dữ liệu bắt đầu bằng tiêu đề: Số byte Type [Giá Mô tả trị] 4 U16 số lượng hình chữ nhật con PIXEL số byte mỗi điểm ảnh giá trị điểm ảnh nền Đi kèm là số lượng hình chữ nhật con các instance (hiển thị) của cấu trúc: Số byte Type [Giá trị] Mô tả PIXEL số byte mỗi điểm ảnh giá trị điểm ảnh hình chữ nhật 2 U16 con 2 U16 x-position 2 U16 y-position 2 U16 width height 4.1.6.5.5 Mã hóa Hextile Hextile là một biến đổi của ý tưởng CoRRE. Các hình chữ nhật được cắt ra các tile (lát) 16x16, cho phép các chiều hình chữ nhật xác định bằng mỗi 4 bit, tổng cộng 16 bit. Không giống CoRRE, các lát không phải là các hình chữ nhật RFB cơ bản nhất. 163
- Khi cắt một hình chữ nhật gốc thành các lát, điều này thực hiện theo tính tóan trước. Điều này có nghĩa là vị trí và kích thước của mỗi lát không cần phải xác định tường minh – nội dung mã hóa của các lát chỉ đơn giản theo một lát khác trong thứ tự tính toán trước. Sắp xếp thứ tự các lát chúng ta dùng thì phải bắt đầu từ góc trái trên đi theo từ trái qua phải, từ trên xuống dưới. Nếu độ rộng của hình chữ nhật không chính xác là bội số của 16 thì độ rộng của lát cuối trên mỗi dòng sẽ nhỏ lại tương ứng.Tương tự nếu độ dài của hình chữ nhật không chính xác là bội số của 16 thì độ dài của mỗi lát trên dòng cuối sẽ nhỏ lại tương ứng. Mỗi lát mã hóa hoặc thô hoặc là biến thể RRE. Mỗi lát có một giá trị điểm ảnh nền, như đề cập ở trên. Tuy nhiên, giá trị nền không cần xác định tường minh cho một lát cho trước nếu nó giống với nền của lát trước đó. Nếu mọi hình chữ nhật con của một lát có cùng giá trị điểm ảnh, giá trị này có thể xác định đúng một lần thành giá trị điểm ảnh mặt tiền cho cả lát. Cũng như nền, giá trị điểm ảnh mặt tiền có thể để trống, ngụ ý nó đã có trong lát trước rồi. Do vậy, dữ liệu mỗi lát mã hóa theo thứ tự. Mỗi lát bắt đầu bằng byte dạng subencoding (mã hóa phụ), mang ý nghĩa mặt nạ áp cho số bit: Số byte Type [Giá trị] Mô tả 1 U8 subencoding-mask 1 Thô (raw) 2 BackgroundSpecified 4 ForegroundSpecified 6 AnySubrects 16 SubrectsColoured Nếu bit Raw được đặt lên thì các bit còn lại không liên quan; width x height giá trị điểm ảnh tiếp theo (với widht và height là độ rộng và dai của lát). Nếu không các bit còn lại trong mặt nạ phải như sau: 164
- BackgroundSpecified – nếu đặt, một giá trị điểm ảnh theo sau sẽ xác định màu nền cho lát này: Số byte Type [Giá trị] Mô tả PIXEL số byte mỗi điểm ảnh giá trị điểm ảnh nền Lát đầu tiên trong một hình chữ nhật phải có bt đặt lên. Nếu bit này không đặt thì nền sẽ giống với lát cuối. ForegroundSpecified – nếu đặt, giá trị điểm ảnh theo sau sẽ xác định giá trị màu mặt tiền được dùng cho mọi hình chữ nhật con của lát này: Số byte Type [Giá trị] Mô tả PIXEL số byte mỗi điểm ảnh giá trị điểm ảnh mặt tiền Nếu bit này được thì bit SubrectsColoured phải là 0. AnySubrects – nếu đặt, một byte đơn theo sau cho biết số lượng các hình chữ nhật con: Số byte Type [Giá trị] Mô tả 1 U8 số lượng hình chữ nhật Nếu không đặt, không có hình chữ nhật con (i.e. cả lát chỉ là một màu nền trơ). SubrectsColoured – nếu đặt thì mỗi hình chữ nhật con sẽ đi kèm giá trị điểm ảnh cho biết màu của hình chữ nhật con, vậy một hình chữ nhật con gồm: Số byte Type [Giá trị] Mô tả PIXEL số byte mỗi điểm ảnh giá trị điểm ảnh hình chữ nhật 1 U8 con 1 U8 x-and-y-position 165
- width-and-height Nếu không đặt, mọi hình chữ nhật con có cùng màu, màu mặt tiền; nếu bit ForegroundSpecified không được đặt thì mặt tiền sẽ giống với lát cuối. Một hình chữ nhật con là: Số byte Type [Giá trị] Mô tả 1 U8 x-and-y-position 1 U8 width-and-height Vị trí và kích thước của mỗi hình chữ nhật con xác định trong hai byte, x-and-y-position và width-and-height. Bốn bit quan trọng nhất của x-and-y-position xác định vị trí X, bốn bít còn lại xác định vị trí Y. Bốn bit quan trọng nhất của width- and-height xác định độ rộng trừ đi một, bốn bít còn lại xác định độ dài trừ đi một. 4.1.6.5.6 Mã hóa ZRLE ZRLE viết tắt cho Zlib Run-Length Enconding, là kết hợp của khả năng nén theo zlib, cắt lát, phân bảng màu và mã hóa chiều dài chạy. Trên đường truyền, hình chữ nhật bắt đầu với một trường rộng 4 byte, và theo sau là những byte dữ liệu nén theo zlib. Một đối tượng “theo dòng” zlib đơn được dùng cho một kết nối RFB cho trước, để các hình chữ nhật ZRLE phải được mã hóa và giải mã nghiêm ngặc theo thứ tự. Số byte Type [Giá trị] Mô tả 4 U32 chiều dài mảng U8 chiều dài zlibData (dữ liệu zlib) 166
- zlibData khi được bung nén hiển thị bằng các lát 64x64 điểm ảnh theo thứ tự trái qua phải, trên xuống dưới, tương tự như hextile. Nếu độ rộng của hình chữ nhật không chính xác là bội số của 64 thì độ rộng của lát cuối trên mỗi dòng sẽ nhỏ lại tương ứng.Tương tự nếu độ dài của hình chữ nhật không chính xác là bội số của 64 thì độ dài của mỗi lát trên dòng cuối sẽ nhỏ lại tương ứng. ZRLE sử dụng kiểu dữ liệu mới CPIXEL (compressed pixel – điểm ảnh nén). Kiểu này cũng giống như PIXEL cho định dạng điểm ảnh đã xác định trước, ngoại trừ cờ true-colour là khác 0, số bit mỗi điểm ảnh là 32, độ sâu là 24 hay thấp hơn và mọi bit tạo cường độ đỏ, xanh lá, xanh dương gắn vừa vào 3 byte thứ yếu nhất hoặc 3 byte quan trọng nhất Trong trường hợp này, một CPIXEL chỉ dài độ 3 byte, và chứa 3 byte thứ yếu nhất hay 3 byte quan trọng nhất, tùy bên nào phù hợp hơn. bytePerCPixel là số byte trong CPIXEL. Mỗi lát bắt đầu bằng một byte dạng subendcoding. Bit cao nhất của byte này đặt lên nếu lát được mã hóa chiều dài chạy, nếu không sẽ xóa. Bảy bit dưới cho biết kích thước của bảng màu dùng – 0 có nghĩa là không có bảng màu, một có nghĩa là lát có một màu đơn, 2 đến 127 cho biết bảng màu có kích thước như thế. Các giá trị có thể có của subencoding là: 0 – dữ liệu điểm ảnh thô. width x height giá trị điểm ảnh tiếp theo (với width và height là độ rộng và độ dài của lát): Số byte Type [Giá Mô tả trị] width x height x mảng CPIXEL các điểm ảnh bytesPerCPixel 167
- 1 – một lát cứng là một lát chỉ có một màu đơn: Số byte Type [Giá Mô tả trị] CPIXEL bytesPerCPixel pixelValue – giá trị điểm ảnh 2 to 16 – các dạng bảng màu đóng gói. Theo sau bảng màu, bao gồm các paletteSize (= subencoding) giá trị điểm ảnh. Sau các điểm ảnh đóng gói, mỗi điểm ảnh được biểu diễn bằng một trường bit cho biết chỉ mục cho bảng màu (0 có nghĩa là mục đầu tiên bảng màu ). Cho paletteSize bằng 2, trường 1 bit được dùng, cho paletteSize bằng 3 hay 4, trường 2 bit được dùng, và cho paletteSize từ 5 đến 16, trường 4 bit được dùng. Các trường bit đóng gói trong các byte, các bit quan trọng nhất biểu diễn các điểm ảnh cực trái (i.e. big endian). Cho các lát không rộng bằng bội số 8, 4 hay 2 điểm ảnh, các bit độn sẽ dùng để canh lề mỗi dòng cho chính xác số lượng byte. Số byte Type [Giá Mô tả trị] paletteSize x bytesPerCPixel mảng CPIXEL bảng màu mảng U8 m các điểm ảnh đóng gói 17 đến 127 – không dùng (không có tiến triển trên bảng màu RLE). 128 – RLE trơ, bao gồm số lượng các đường chạy, lặp lại cho đến khi lát gởi hết. Đường chạy có thể bắt đầu từ cuối một dòng sang bắt đầu dòng kế tiếp. Mỗi đường chạy được biểu diễn bởi một giá trị điểm ảnh đơn theo sau là chiều dài của đường chạy. Chiều dài biểu diễn một hoặc nhiều byte. Chiều dài được tính nhiều hơn một so với tổng các byte cho biết độ dài. Bất kỳ giá trị byte khác 255 đều được xem là byte cuối. 168
- Ví dụ, chiều dài 1 biểu diễn [0], 255 là [254], 256 là [255, 0], 257 là [255, 1], 510 là [255, 254] , 511 là [255, 255, 0] ... Số byte Type [Giá Mô tả trị] U8 1 paletteIndex + 128 mảng U8 255 floor((runLength – 1)/255) U8 1 (runLength – 1)%255 4.1.6.6 Mã hóa giả 4.1.6.6.1 Mã hóa giả Cursor Một client yêu cầu mã hóa giả Cursor phải khai báo nó có thể vẽ con trỏ mouse cục bộ được. Điều này có thể làm tăng một cách đáng kể việc trình diễn trên các đường truyền tốc độ thấp. Server thiết lập hình dạng con trỏ bằng cách gởi một hình chữ nhật giả với mã hóa giả Cursor là một phần của việc cập nhật. Các tọa độ x-position và y- position của hình chữ nhật giả cho biết hotspot (đầu trỏ) của con trỏ, và width và height cho biết độ rộng và dài của con trỏ tính bằng điểm ảnh. Dữ liệu gồm width x height giá trị điểm ảnh đi kèm là một mặt nạ bit. Mặt nạ bit gồm các dòng quét từ trái sang phải, từ đỉnh xuống dưới, mỗi dòng quét được độn thêm vào một số các byte tính bằng floor((width+ 7)/8). Trong mỗi byte, bit quan trọng nhất biểu diễn điểm ảnh cực trái, với một bit đó mang ý nghĩa điểm ảnh tương ứng trong con trỏ có hiệu lực. Số byte Type [Giá Mô tả trị] width x height x bytesPerPixel mảng PIXEL các điểm ảnh của con trỏ 169
- mảng U8 floor((width + 7)/8) * height mặt nạ bit 4.1.6.6.2 Mã hóa giả DesktopSize Một client yêu cầu mã hóa giả Cursor phải khai báo nó có thể sao chép với sự thay đổi trong độ rộng và/ hay độ dài vùng đệm khung. Server thay đổi kích thước desktop bằng cách gởi một hình chữ nhật giả với mã hóa giả DesktopSize như là hình chữ nhật cuối cùng của quá trình cập nhật. Các tọa độ x-position và y-position bỏ qua, và width và height cho biết độ rộng và độ dài của vùng đệm khung mới. Không có dữ liệu kèm theo với hình chữ nhật giả. 4.2 H323 4.2.1 Chuẩn H323 là gì ? H.323 là chuẩn của International Telecommunications Union(ITU), cung cấp những đặc điểm kỹ thuật cho máy tính, thiết bị, và dịch vụ cho việc giao tiếp đa truyền thông qua mạng mà không cần phải quan tâm đến chất lượng dịch vụ. Các máy tính và thiết bị có sử dụng H.323 có thể đem đến âm thanh, hình ảnh hay dữ liệu theo thời gian thực. Chuẩn này dựa trên Internet Engineering Task Force (IETF), Real Time Protocol (RTP) và Real Time Control Protocol (RTCP), cộng với một số protocol được thêm vào cho việc thực hiện cuộc gọi, trao đổi dữ liệu và giao tiếp âm thanh, hình ảnh theo thời gian thực. Người dùng có thể kết nối với người khác thông qua internet và sử dụng những loại sản phẩm khác nhau có hỗ trợ H.323. H.323 định nghĩa cách mà thông tin được định dạng và đóng gói trước khi truyền qua mạng. Mã hóa âm thanh và hình ảnh, và giải mã đầu vào/ đầu ra từ nguồn âm thanh, hình ảnh cho việc giao tiếp giữa các điểm. Một codec( bao gồm mã hóa và giải mã) sẽ chuyển đổi tín hiệu âm thanh và hình ảnh giữa hình thức tương tự và số. 170
CÓ THỂ BẠN MUỐN DOWNLOAD
-
Bài giảng Quản trị văn phòng - ThS. Phạm Thị Ngân
81 p | 2741 | 941
-
Bài giảng môn Quản trị văn phòng - GV.Phạm Thị Minh Lan
141 p | 847 | 219
-
GIÁO TRÌNH QUẢN LÝ CHẤT LƯỢNG TRANG PHỤC - CHƯƠNG V QUẢN LÝ CHẤT LƯỢNG QUA CÁC CÔNG ĐOẠN CỦA QUÁ TRÌNH SẢN XUẤT MAY CÔNG NGHIỆP
46 p | 707 | 162
-
HƯỚNG DẪN KỸ THUẬT LẬP BẢN CAM KẾT BẢO VỆ MÔI TRƯỜNG DỰ ÁN XÂY DỰNG KHO XĂNG DẦU QUY MÔ NHỎ (Dung tích dưới 1.000m3)
35 p | 224 | 54
-
Luận văn thạc sỹ - Mô phỏng liên tục tring quản lý dự án - Chương 6
21 p | 182 | 33
-
Bài giảng Quản trị hành chính văn phòng: Chương 3 - ThS. Nguyễn Văn Báu
29 p | 125 | 33
-
Bài giảng Kỹ thuật xây dựng và ban hành văn bản quản lý hành chính Nhà nước: Chương 4, 5 - ThS. Tạ Thị Thanh Tâm
76 p | 161 | 26
-
Bài giảng Quản lý dự án: Chương 2 - GS.TS. Bùi Xuân Phong
9 p | 131 | 17
-
Tài liệu bồi dưỡng Lãnh đạo, quản lý cấp huyện - Chuyên đề 5
25 p | 232 | 15
-
Quản lý đất đai ở Việt Nam (1945-2010) - TS. Nguyễn Đình Bồng
148 p | 59 | 13
-
Chương trình đào tạo, bồi dưỡng lãnh đạo cấp phòng
33 p | 148 | 11
-
Chương trình đào tạo liên tục an toàn người bệnh
24 p | 144 | 8
-
Bài giảng Luật Xây dựng: Chương 5 - Nguyễn Quốc Lâm
30 p | 33 | 8
-
Các chương trình quản lý phòng máy hiện nay ở Việt Nam - 2
25 p | 61 | 7
-
Các chương trình quản lý phòng máy hiện nay ở Việt Nam - 5
25 p | 81 | 7
-
Bài giảng Quản lý học: Chương 6 - TS. Nguyễn Hữu Xuyên
9 p | 22 | 6
-
Bài giảng Quản lý dự án cho kỹ sư: Chương 5 - Lê Phước Luông
8 p | 9 | 2
Chịu trách nhiệm nội dung:
Nguyễn Công Hà - Giám đốc Công ty TNHH TÀI LIỆU TRỰC TUYẾN VI NA
LIÊN HỆ
Địa chỉ: P402, 54A Nơ Trang Long, Phường 14, Q.Bình Thạnh, TP.HCM
Hotline: 093 303 0098
Email: support@tailieu.vn