X11 - Chuyển tiếp và hiệu quả


12

Tôi có một ứng dụng đồ họa chuyên sâu cần được chuyển tiếp qua X11. Tôi đã dành thời gian nghiên cứu X11 và hiệu quả (trong) của nó, bao gồm bài đăng tuyệt vời này: Tại sao X11 chuyển tiếp không hiệu quả? .

Một điều vẫn chưa rõ ràng đối với tôi là liệu hiệu suất của chuyển tiếp X11 có phụ thuộc vào ứng dụng hay không. Tôi có ấn tượng rằng toàn bộ màn hình được chuyển tiếp, bất kể chuyện gì đang xảy ra. Sau đó, chuyển tiếp X11 phải là bất khả tri ứng dụng.

Vì vậy, có bất kỳ thông tin cụ thể về những gì thực sự được chuyển tiếp và liệu hiệu suất của ssh -X phụ thuộc vào ứng dụng?


2
"Vì vậy, có bất kỳ thông tin cụ thể nào về những gì thực sự được chuyển tiếp và liệu hiệu suất của ssh -X có phụ thuộc vào ứng dụng không?" Đúng. Để bắt đầu, hãy xem bài nói chuyện của Daniel Stone Câu chuyện có thật đằng sau Wayland và X từ LinuxConf.au 2013.
sampablokuper

1
"Tôi có ấn tượng rằng toàn bộ màn hình được chuyển tiếp" Thật khó hiểu điều gì sẽ mang lại cho bạn ấn tượng đó, bởi vì những gì mọi người thường làm với chuyển tiếp SSH X là chạy các ứng dụng riêng lẻ trên vỏ từ xa; bạn có thể giải thích về cách bạn khởi chạy các ứng dụng không?
rakslice

1
Một yếu tố cần lưu ý nếu bạn đang vận chuyển phiên X qua đường hầm SSH: ssh có thể thực hiện nén. Đó là -Ctùy chọn trên dòng lệnh hoặc Compression: yestùy chọn trong tệp .ssh / config. Nếu bạn đang thực hiện chuyển tiếp X truyền thống từ Dallas đến Úc qua liên kết T1 bị tắc nghẽn, đây có thể là sự khác biệt giữa nhiệm vụ của bạn là đưa hộp thoại vào năm cấp độ sâu trong giao diện và chọn hộp kiểm từ một nhiệm vụ không thực tế đến chỉ đơn thuần là quá mức bực bội hai tiếng. May mắn thay tôi đã không cần phải thử điều này với Wayland, nhưng tôi cho rằng nó đã được cải thiện rất nhiều.
Ed Grimm

Tôi không muốn bắt đầu một cuộc thảo luận rộng rãi trong các bình luận, đặc biệt vì câu hỏi của tôi đã được @grawity trả lời rất tốt. Bởi "toàn bộ màn hình" Tôi có nghĩa là dữ liệu được chuyển tiếp qua đường hầm ssh sẽ luôn là một mô tả đơn giản về các pixel trên màn hình. @ EdGrimm: Cảm ơn bạn đã nhận xét về việc nén. Tôi biết điều đó. Trong kịch bản cụ thể của chúng tôi, X11 được chuyển tiếp qua Liên kết LAN 10Gbit và nén / không nén dường như hoàn toàn không có sự khác biệt.
Fang

Câu trả lời:


29

Tôi có ấn tượng rằng toàn bộ màn hình được chuyển tiếp, bất kể chuyện gì đang xảy ra. Sau đó, chuyển tiếp X11 phải là bất khả tri ứng dụng.

Không, nó thực sự ngược lại. Lý do chuyển tiếp X11 được gọi là "chuyển tiếp X11" là vì nó vận chuyển các thông điệp giao thức X thực tế được sử dụng bởi các ứng dụng để hiển thị các cửa sổ của chúng trên "máy chủ X" (thường là Xorg). Những thông điệp này là các lệnh để tạo / di chuyển các cửa sổ, vẽ văn bản và nguyên thủy đồ họa (đường / hình chữ nhật), vẽ bitmap, v.v.

Bạn có thể nói về mặt khái niệm nó trái ngược với các giao thức "hình ảnh toàn màn hình" như VNC / RFB. Tôi nghĩ rằng nó có thể so sánh với RDP của Windows, cũng được tạo ra để vận chuyển các lệnh vẽ GDI.

Vì vậy, lý do bạn thấy sự khác biệt giữa các chương trình là:

  1. Để trích dẫn bài đăng mà bạn đã tham chiếu, ban đầu hầu hết các chương trình dựa trên X đều hoạt động như thế này:

    Về cơ bản X11 không gửi màn hình tới máy tính của bạn, nhưng nó sẽ gửi hướng dẫn hiển thị để máy chủ X trên máy tính cục bộ của bạn có thể tạo lại màn hình trên hệ thống cục bộ của bạn.

    Vì vậy, khi một chương trình muốn hiển thị một nút, nó chỉ gửi một vài lệnh ngắn - "vẽ hình chữ nhật", "vẽ văn bản" và có lẽ một số dòng để làm cho nó trông giống 3D.

  2. Theo thời gian, điều này đã thay đổi, các chương trình bắt đầu tự thực hiện kết xuất và nhiều hướng dẫn đó đã trở thành "đây là một bitmap mà tôi đã kết xuất, đưa nó lên màn hình" - rất nhanh cục bộ, nhưng rất chậm qua mạng do X11 không có Nén hình ảnh.

    Điều này có nghĩa là các chương trình được xây dựng bằng bộ công cụ hiện đại chậm hơn nhiều so với X11 được nối mạng, ngay cả khi đó là thứ gì đó cơ bản như phông chữ được khử răng cưa.

    (Ngược lại, RDP đã điều chỉnh theo thời gian và bao gồm nhiều hình thức nén hình ảnh khác nhau như JPEG và thậm chí H.264; bạn thường có thể nhận thấy các tạo tác nén trong khi tải hình ảnh đầy đủ.)

  3. May mắn thay, hầu hết các bộ công cụ UI như GTK đều thực hiện theo dõi thiệt hại để chỉ các khu vực được cập nhật mới được gửi lại. Tuy nhiên, một số chương trình (như một số phiên bản Firefox / Thunderbird), không hỗ trợ điều này và yêu cầu kết xuất lại toàn bộ cửa sổ, ngay cả khi nó chưa thực sự được cập nhật.

    Đó là một sự khác biệt khác giữa các chương trình - những chương trình hoạt động tốt vẫn có thể sử dụng được qua mạng, nhưng những chương trình lỗi có thể bão hòa một liên kết 100 Mbps hoàn toàn không có ích gì.


1
Tôi nhớ một lần cố gắng thiết lập một máy chủ MythTV. Tiện ích "thiết lập" là một ứng dụng Qt và mất vài phút để hiển thị từng trang cấu hình, mặc dù liên kết ADSL hợp lý là nút cổ chai (gần 8 Mb / giây). Một vài phút làm việc mất vài giờ vì điều này - nó sẽ dễ dàng hơn nhiều với Giao diện người dùng Curses hoặc thậm chí là một ứng dụng X11 hoạt động tốt. Nếu tôi biết sẽ có bao nhiêu rắc rối xảy ra, tôi đã đợi một hoặc hai tuần cho đến khi tôi có mặt tại chỗ và sử dụng một trong những hộp mặt trước không đĩa để hiển thị. Tôi muốn máy chủ lên và làm việc sớm hơn thế.
Toby Speight

1
Để bảo vệ những "chương trình lỗi" đó, người ta phải chỉ ra rằng đây là lỗi của hệ tư tưởng bộ công cụ X +, về cơ bản khiến cho các chương trình lỗi đó phải bị lỗi ngay từ đầu. Bạn sẽ nghĩ rằng một chương trình chỉ có thể gọi một API (gửi lệnh) để có "cửa sổ nhìn bình thường", một menu và một nút ở đây và một thanh cuộn ở đó, nhưng không. Bạn, hoặc bộ công cụ, phải làm mọi thứ bằng tay. Tôi thực sự không phải là fan hâm mộ lớn của MS và thậm chí còn ít hơn Apple, nhưng họ đã có những điều đó đúng trong khi hệ sinh thái X đã bị hút trong nhiều thập kỷ, và vẫn còn tệ.
Damon

Tôi không chắc chắn nếu có bất kỳ sự khác biệt mặc dù. Điều gì làm cho UWP hoặc WinForms của Windows hoặc comctl32 trở thành một "bộ công cụ" ít hơn GTK và QT? Họ cũng không làm mọi thứ "bằng tay" à?
dùng1686
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.