Trình giả lập thiết bị đầu cuối có thể nhanh như TTY 1-6 không?


59

Gần đây tôi đã thử nhiều trình giả lập thiết bị đầu cuối khác nhau, từ gnome-terminal tích hợp, aterm, xterm, wterm, đến rxvt. Bài kiểm tra tôi đã làm theo thứ tự này:

  1. Mở một cửa sổ tmux với 2 tấm
  2. Khung bên trái sẽ là một nhiệm vụ chuyên sâu, chẳng hạn như grep a /et/c -rhoặc đơn giảntime seq -f 'blah blah %g' 100000
  3. Khung bên phải sẽ là một cửa sổ vim với cú pháp bật, mở bất kỳ tệp nào có hơn> 100 dòng mã.

Khi khung bên trái đang in rất nhiều đầu ra, khung bên phải dường như rất chậm và không phản hồi, tôi đã cố cuộn trong vim nhưng phải mất 1-2 giây để nó thay đổi. Khi tôi cố nhấn CtrlCvào khung bên trái, nó sẽ đợi hơn 10 giây trước khi dừng

Khi tôi làm điều tương tự trong TTY (nhấn CTRL+ ALT+ ( F[1-6])), điều đó không xảy ra và cả hai pan đều rất nhạy.

Tôi đã bật một số cấu hình như phông chữ antialias, chuyển màu, sử dụng cài đặt mặc định và thay đổi thành xmonad và openbox, nhưng nó không thay đổi gì cả.

Kết quả time seq -f 'blah blah %g' 100000là không thực sự khác biệt giữa các thiết bị đầu cuối này, nhưng khả năng đáp ứng thực sự khác biệt, đặc biệt là khi tôi đang chạy tmux pane spited (hoặc các bộ ghép kênh khác). FYI, tôi đang chạy tất cả chúng trong một chế độ tối đa.

Tôi đã đọc về các thiết bị đầu cuối được đệm khung nhưng không chắc nó hoạt động như thế nào và làm thế nào để sử dụng nó để tăng tốc trình giả lập thiết bị đầu cuối của tôi.

Vì vậy, câu hỏi của tôi là, điều gì làm cho trình giả lập thiết bị đầu cuối chậm hơn TTY? Có khả năng nào để làm cho nó nhanh như TTY không? Có lẽ tăng tốc phần cứng hoặc một cái gì đó?. Một điều tôi biết, độ phân giải của tôi trong máy chủ X khi chạy trình giả lập thiết bị đầu cuối tối đa là 1920x1080 và khi tôi chạy TTY thì nó ít hơn thế, nhưng tôi không chắc điều này sẽ ảnh hưởng đến hiệu suất như thế nào.


Nghe có vẻ như có một vùng đệm lớn ở đâu đó
Thorbjørn Ravn Andersen

2
Lưu ý tty [1-6] không phải lúc nào cũng nhanh chóng. Trên một trong những máy tôi đang sử dụng, bảng điều khiển văn bản rất chậm trong khi một xterm hoạt động tốt.
把 友情 留

Câu trả lời:


75

Khi một giao diện mô phỏng thiết bị in ra một chuỗi, nó có để chuyển đổi chuỗi để phông chữ codepoints, gửi codepoints đến một renderer font chữ, lấy lại một bitmap và blit rằng bitmap để hiển thị thông qua các máy chủ X.

Trình kết xuất phông chữ phải truy xuất glyphs và chạy chúng (bạn có biết rằng phông chữ Truetype / Opentype là các chương trình chạy bên trong một máy ảo trong trình kết xuất phông chữ không?). Trong quá trình chạy từng glyph, một số quyết định điên rồ được đưa ra liên quan đến các số liệu phông chữ, k sâu (mặc dù phông chữ đơn cách và k sâu không kết hợp tốt), tuân thủ Unicode và trước khi chúng ta thậm chí tiếp cận trình rasteriser có thể sử dụng phụ địa chỉ -pixel. Sau đó, thiết bị đầu cuối phải lấy bộ đệm do trình tạo phông chữ tạo ra và đưa nó đến đúng vị trí, chăm sóc chuyển đổi định dạng pixel, kênh alpha (để đánh địa chỉ pixel phụ), cuộn (bao gồm nhiều lỗi hơn ), et cetera.

Để so sánh, việc viết một chuỗi vào Virtual Terminal chạy ở chế độ văn bản (lưu ý: không phải là bảng điều khiển đồ họa) liên quan đến việc ghi chuỗi đó vào bộ nhớ video. 'Chào thế giới!' liên quan đến việc viết 13 byte (13 từ 16 bit nếu bạn cũng muốn màu sắc). Trình tạo phông chữ X thậm chí chưa bắt đầu các bài tập kéo dài và bẻ khóa ngón tay, và chúng ta đã hoàn thành. Đây là lý do tại sao chế độ văn bản rất quan trọng trong nhiều thập kỷ qua. Nó rất nhanh để thực hiện. Ngay cả việc cuộn cũng dễ dàng hơn bạn nghĩ: ngay cả trên MDA và CGA dựa trên Motorola 6845 đáng kính, bạn có thể cuộn màn hình theo chiều dọc bằng cách viết một giá trị 8 bit vào một thanh ghi (có thể là 16 ... quá dài). Mạch làm mới màn hìnhđã làm phần còn lại. Về cơ bản, bạn đã thay đổi địa chỉ bắt đầu của bộ đệm khung.

Bạn không thể làm gì để tạo một thiết bị đầu cuối đồ họa nhanh như thiết bị đầu cuối chế độ văn bản trên cùng một máy tính. Nhưng hãy lưu ý: đã có những máy tính có chế độ văn bản chậm hơn thiết bị đầu cuối đồ họa chậm nhất bạn từng thấy trên một máy tính hiện đại. Máy tính IBM ban đầu khá tệ (DOS đã cuộn phần mềm, thở dài). Khi tôi nhìn thấy bảng điều khiển Minix đầu tiên của mình trên một chiếc 80286, tôi đã rất ngạc nhiên về tốc độ di chuyển (nhảy). Tiến bộ là tốt.

Cập nhật: cách tăng tốc thiết bị đầu cuối

@ poige đã đề cập đến ba trong câu trả lời của anh ấy , nhưng đây là của riêng tôi về chúng:

  • Giảm kích thước của thiết bị đầu cuối. Thiết bị đầu cuối của riêng tôi có xu hướng phát triển cho đến khi chúng lấp đầy màn hình, và chúng bị chậm khi chúng làm điều đó. Tôi bực tức, khó chịu ở các thiết bị đầu cuối đồ họa, sau đó tôi thay đổi kích thước chúng và mọi thứ đều tốt hơn. :)
  • (@poige) Sử dụng trình giả lập thiết bị đầu cuối khác. Bạn có thể nhận được một sự gia tăng tốc độ lớn với chi phí của một số tính năng hiện đại. xtermrxvthoạt động thực sự tốt, nó có một trình giả lập thiết bị đầu cuối tuyệt vời. Tôi nghi ngờ các bài kiểm tra của bạn có thể cho thấy chúng hoạt động tốt hơn so với các bài kiểm tra 'hiện đại'.
  • (@poige) Không sử dụng phông chữ có thể mở rộng. 1986 có thể gọi và yêu cầu thiết bị đầu cuối của nó trở lại, nhưng bạn không thể từ chối chúng nhanh hơn. ;)
  • (@poige) Giảm âm thanh rasteriser bằng cách tắt địa chỉ khử răng cưa / pixel phụ và gợi ý. Hầu hết trong số chúng cho phép ghi đè lên các biến môi trường, vì vậy bạn không phải thực hiện việc này trên toàn cầu. Lưu ý: vô nghĩa nếu bạn chọn phông chữ bitmap.
  • Điều này sẽ làm tổn thương nhiều nhất: không sử dụng (nhiều bảng trong)tmux - chạy hai thiết bị đầu cuối riêng biệt cạnh nhau. Khi tmuxhiển thị hai bảng, nó phải sử dụng các chỉ thị đầu cuối để di chuyển con trỏ xung quanh rất nhiều. Mặc dù các thư viện thiết bị đầu cuối hiện đại rất nhanh và tối ưu hóa tốt, chúng vẫn ăn cắp byte từ băng thông đầu cuối thô của bạn. Để di chuyển con trỏ đến một hàng tùy ý trên thiết bị đầu cuối tương thích DEC VT, bạn gửi ESC [ row ; col H. Đó là 6 byte10 byte. Với nhiều thiết bị đầu cuối, bạn đang tách biệt công việc, giải quyết nhu cầu định vị, tối ưu hóa, đệm và tất cả các công cụ khác curses, và sử dụng tốt hơn nhiều lõi CPU.

5
+1, nhưng điều tmux thậm chí còn phức tạp hơn so với chỉ một số mã thoát bổ sung được gửi. Thiết bị đầu cuối có nghĩa là cuộn toàn bộ cửa sổ, không phải một nửa của nó. Vì vậy, khi tmux phải di chuyển tất cả văn bản trong khung bên trái lên một dòng, nó không thể tạo một dòng mới và để thiết bị đầu cuối di chuyển nó lên, nó phải vẽ lại toàn bộ khung.
Patrick

1
Khá đúng! Tôi quên mất điều đó. Mặc dù đã có các thiết bị đầu cuối có thể cuộn một phần của màn hình (IIRC, nó được gọi là phần 'bảo vệ' của màn hình - nó được sử dụng cho các hình thức, v.v.), nó không bao giờ đặc biệt linh hoạt và có lẽ không được hỗ trợ bởi các trình giả lập thiết bị đầu cuối hiện đại. Mặc dù bạn tìm thấy một số chỉ thị lỗi thời thực sự kỳ lạ vẫn được thực hiện ngày hôm nay.
Alexios

Trả lời điều này sau 3 năm nhưng hy vọng ai đó thấy điều này hữu ích. Tôi chỉ nhận thấy độ trễ khi tôi thực hiện phân tách dọc trong vim của mình (vâng, thậm chí là NERDTree) nhưng sự phân chia bình thường dường như không phải là vấn đề trong quá trình cuộn.
hét

17

Trong khi đó @Alexios đã mô tả khá rõ tất cả các lý do, tôi có thể đề cập đến một số điều, tương đối làm giảm cơn đau:

  • sử dụng phông chữ bitmap ( Terminal, Terminus- đây thực sự là một phông chữ tuyệt vời),
  • tắt khử răng cưa hoặc xem xét ít nhất là không sử dụng kết xuất pixel phụ ,
  • sử dụng thiết bị đầu cuối của KDE - konsole.

1
Ngoài ra, và đây là một điều đau đớn, làm giảm kích thước của thiết bị đầu cuối (OP đang sử dụng cửa sổ 1920x1200px). Tôi yêu các thiết bị đầu cuối lớn, và của tôi có xu hướng phát triển cho đến khi chúng lớn gần bằng màn hình, nhưng tốc độ thiết bị đầu cuối giảm khi thiết bị đầu cuối phát triển. Ngay cả konsole(mà tôi ủng hộ).
Alexios

3
konsolekhông cập nhật màn hình lười biếng: thay vì hiển thị đầu ra ngay lập tức, nó sẽ đợi một chút thời gian để có thêm đầu ra, để cập nhật "hàng loạt". Đó là lý do tại sao nó hoạt động rất tốt, đến mức hoàn toàn đáp ứng với bài kiểm tra căng thẳng của OP.
ninjalj

2
Khá chắc chắn kết xuất phông chữ được lưu trữ tại một số điểm. Tôi không nghĩ các pixel đại diện cho chữ f được kết xuất lại từ định nghĩa vectơ mỗi khi nó được sao chép sang pixmap. (trừ khi nó phải được hiển thị ở kích thước mới hoặc góc mới). Tôi sẽ không tranh cãi về thực tế rằng có một số phông chữ bitmap thực sự đẹp, đó có thể là lựa chọn tốt nhất chỉ để xuất hiện một mình, nếu chúng tồn tại với kích thước bạn muốn.
Peter Cordes
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.