2012-03-20 33 views
23

Tôi không thể tìm thấy bất kỳ tài liệu chính thức nào nói rằng an toàn khi gọi số Component.repaint từ một chủ đề khác ngoài Chủ đề công văn sự kiện, EDT.An toàn để sử dụng Component.repaint() bên ngoài EDT?

Đây có phải là như vậy không? Và tôi có thể tìm thấy một số tài liệu/mã ở đâu?

+0

tốt câu hỏi 1, quan điểm máy bay trực thăng của tôi :-) -> 'một)' mọi thứ hoạt động cho đến khi repaint () không bị khóa bởi Thread.sleep (int), 'b)' có một vài chủ đề về isEventDispatchThread(), nhưng những lins đó bị mất trên Java.Net 'c)' đã đồng ý với API cho các thành phần AWT và cho chúng các lớp lồng nhau trong Swing – mKorbel

Trả lời

25

Đây là một quote from an official page nói rằng:

Các phương pháp JComponent Sau đây là an toàn để gọi từ bất kỳ chủ đề:repaint(), revalidate(), và invalidate(). Các yêu cầu xếp hàng theo phương thức repaint()revalidate() hàng đợi cho chuỗi sắp xếp sự kiện để gọi số paint()validate() tương ứng.

EDIT 1:


Kể từ khi liên kết trước đó đề cập đã được thay đổi. Tôi đang đăng một new link, mặc dù có thể mất nhiều thời gian hơn để thực sự biết tính xác thực của trang này, vì nó có vẻ là từ Java mặc dù nó có nguồn gốc từ một số máy chủ của University, như có thể thấy từ thanh địa chỉ.

7

Đó là chủ đề an toàn. RepaintManager đảm bảo rằng các cuộc gọi như vậy được đặt trong Chủ đề công văn sự kiện.

Painting in AWT and Swing ("official" documentation)

Mục đích của lớp RepaintManager Swing là để tối đa hóa hiệu quả xử lý repaint trên một hệ thống phân cấp Swing ngăn chặn, và cũng để thực hiện cơ chế 'kiểm tra hợp lệ' Swing (sau này sẽ một chủ đề cho một bài viết riêng biệt). Nó thực hiện cơ chế repaint bằng cách chặn tất cả các yêu cầu repaint trên các thành phần Swing (vì vậy chúng là không còn được xử lý bởi AWT) và duy trì trạng thái riêng của nó về những gì cần phải được cập nhật (được gọi là "vùng bẩn"). Cuối cùng, nó sử dụng invokeLater() để xử lý các yêu cầu đang chờ xử lý về sự kiện luồng gửi, như được mô tả trong phần "Gửi lại Đang xử lý" (tùy chọn B).

Đối với hầu hết các chương trình, Trình quản lý lại có thể được xem như một phần của hệ thống nội bộ của Swing và hầu như có thể bỏ qua. Tuy nhiên, API của chúng tôi cung cấp các chương trình tùy chọn giành quyền kiểm soát tốt hơn đối với một số khía cạnh nhất định của bức tranh .

+1

Thankx cho Bức tranh tuyệt vời này Doc, tôi cần những thứ này quá lâu :-), không thể tìm thấy nó. Có vẻ như tôi đang chờ bạn tham khảo :-) –

+2

@GagandeepBali: Tôi cũng dựa vào nó. Một cách tiện lợi để tìm thấy nó là thông qua API ['Component'] (http://docs.oracle.com/javase/7/docs/api/java/awt/Component.html). – trashgod

3

về những kinh nghiệm trên diễn đàn này

(+1 cho cả người trả lời) nhưng, tôi nghĩ rằng không thể trả lời câu hỏi của bạn một cách chính xác, một phần của phương pháp Graphics(2D) cần gọi cho repaint() programatically, phần còn lại của họ thực hiện phương pháp này (trong API) trực tiếp (chắc chắn một số trong số họ thiếu phương pháp này trong API)

cho một phần của Swing JComponents là có thể tốt hơn để dis-đồng ý, diễn đàn này là đầy đủ các câu hỏi về Concurency in Swing, bắt đầu với Graphics(2D) nghĩ JTextComponents, JTree, và kết thúc (Giống cách được khai báo là chủ đề an toàn) với setText(),

về Concurency in Swing đang có số đáng chú ý của câu hỏi

+1

ehhh ........? Câu trả lời cho câu hỏi rõ ràng là CÓ - không cần phải lầy lội trong nước bằng cách có thể làm sai mã _unrelated_ – kleopatra

+0

Tôi sẽ xác nhận sự hoài nghi lành mạnh của mKorbel: 1) Các API có thể [thay đổi] (http://stackoverflow.com/a/3245805/230513)), mặc dù có lẽ không phải 'repaint()'. 2) Trong khi 'repaint()' chính nó là thread-safe, một thường gọi nó sau khi cập nhật một thành phần, mà _isn't_ thread-safe. – trashgod

+0

@trahgod cảm ơn vì đã dịch :-) Mặc dù tôi có xu hướng không đồng ý một chút: a) không có thay đổi, nhưng sửa lỗi của một lỗi tài liệu (được cho là cùng một điều, đó là một câu chuyện dài) b) nếu có, mã _before_ gọi repaint là sai, không phải là repaint chính nó – kleopatra

Các vấn đề liên quan