java 是否将多个 repaint() 调用整合到一个 repaint() 中？
Does java consolidate multiple repaint() calls into a single repaint()?
我在几秒钟内每秒接收数百个事件，每个事件都会更新我的模型。如果我在每个事件后调用 invokeLater() 内部的 repaint()，repaint 会每秒调用数百次吗？它是否足够聪明，意识到它有 500 个备份 repaint() 而它只需要做 1 个？
我不知道事件何时会暂停，但我只想以合理的速度更新 UI。我可以实现一个不断更新的未来，直到有足够长的暂停时间，比如 500 ms，但是如果 java 已经这样做了，那我为什么要这么做？
文档 是很好的信息来源。
来自 repaint() 的 javadoc:
Note: For more information on the paint mechanisms utilitized by AWT and Swing, including information on how to write the most efficient painting code, see Painting in AWT and Swing.
The program invokes repaint() on the component, which registers an asynchronous request to the AWT that this component needs to be repainted.
The AWT causes the event dispatching thread to invoke update() on the component.
NOTE: If multiple calls to repaint() occur on a component before the initial repaint request is processed, the multiple requests may be collapsed into a single call to update(). The algorithm for determining when multiple requests should be collapsed is implementation-dependent. If multiple requests are collapsed, the resulting update rectangle will be equal to the union of the rectangles contained in the collapsed requests.
我在几秒钟内每秒接收数百个事件，每个事件都会更新我的模型。如果我在每个事件后调用 invokeLater() 内部的 repaint()，repaint 会每秒调用数百次吗？它是否足够聪明，意识到它有 500 个备份 repaint() 而它只需要做 1 个？
我不知道事件何时会暂停，但我只想以合理的速度更新 UI。我可以实现一个不断更新的未来，直到有足够长的暂停时间，比如 500 ms，但是如果 java 已经这样做了，那我为什么要这么做？
文档 是很好的信息来源。
来自 repaint() 的 javadoc:
Note: For more information on the paint mechanisms utilitized by AWT and Swing, including information on how to write the most efficient painting code, see Painting in AWT and Swing.
The program invokes
repaint()on the component, which registers an asynchronous request to the AWT that this component needs to be repainted.The AWT causes the event dispatching thread to invoke
update()on the component.NOTE: If multiple calls to
repaint()occur on a component before the initial repaint request is processed, the multiple requests may be collapsed into a single call toupdate(). The algorithm for determining when multiple requests should be collapsed is implementation-dependent. If multiple requests are collapsed, the resulting update rectangle will be equal to the union of the rectangles contained in the collapsed requests.