2

in the java swing tablemodel, we are able to fire table changed, added, deleted etc. I am wondering if these method calls are expensive if the component is NOT in visibility?

For instance, another window is covering it. Or its in an non-active tab.

mKorbel
  • 109,525
  • 20
  • 134
  • 319
delita
  • 1,571
  • 1
  • 19
  • 25
  • Can you define what you mean by 'expensive'? Have you noticed these calls being 'expensive' when the component is visible? – copeg Aug 26 '16 at 14:56
  • I noticed lag in the swing application often on a view with static text, whilst there are heavy table updates in a hidden tab component. – delita Aug 26 '16 at 15:02
  • Can you post an [mcve] that demonstrates this lag? Lags are not a typical complaint of a `JTable`, and often are due to threading issues (see @trashgod answer) – copeg Aug 26 '16 at 16:01

2 Answers2

5

To minimize the impact of firing a large number of update events, JTable renderering uses the flyweight pattern to render only visible cells. The approach is outlined here. This related example scales well into the thousands of rows, but you should profile to verify the desired performance.

I noticed lag in the swing application often on a view with static text, whilst there are heavy table updates in a hidden tab component.

As shown here, use SwingWorker to manage indeterminate latency.

Community
  • 1
  • 1
trashgod
  • 203,806
  • 29
  • 246
  • 1,045
0

I think is depends on the application itself on how to respond to these events.

Suppose you need to perform some kind of background tasks based on these event it would still be useful.

Beniton Fernando
  • 1,533
  • 1
  • 14
  • 21
  • Assume that i do need the background task for record keeping purposes. But i am more concern about the load on the EDT thread, where there is any "dirty" region to repaint even if its partially/completely invisible. – delita Aug 26 '16 at 14:47