Fine grained events: for performanceOne critical difference between Glazed Lists' EventList and Swing's ListModel is that Glazed Lists uses fine-grained events and ListModel doesn't. What's the difference? First, lets compare the APIs:
|Granularity||1 range||Unlimited ranges|
|Sample Event||5-13 updated||5-7 updated, 10-12 deleted, 13 inserted|
So fine-grained events are more detailed, but more complex as a consequence. What's the benefit?
Suppose you're writing a World Cup app and have a List
Fine-grained events describe only what actually changed.
JTablereceives the "5-22 updated" event, it must repaint the two changed rows plus the 16 rows in between, which are falsely reported as "updated". With the other event, it only needs to repaint two rows.
Fine-grained events save repaints.
Add sorting to the mix. So we'll need to re-sort the 18 'updated' elements. And although 5-22 was the minimum range before sorting, the sorter must fire a single event with that may span even more indices, perhaps '3-30 updated'. With fine-grained events, only the two impacted indices need to be re-sorted, so the sorter fires a concise event.
Fine-grained events save sorts. Fine-grained events don't expand when indices are reordered..
Now on to filtering. It's not hard to imagine that the change to the 'USA' element caused it to be filtered out of the user's view. To users of the filtered view, the change will look like Czech element was updated and the USA element was deleted. Unfortunately, loosely grained events cannot have a change containing both an update and a delete. What happens? Badness! TableModelEvent has a special state to cover these 'drastic' cases: "All rows changed". Among other things, this causes the entire table to be repainted.
Fine-grained events can handle mixed-type events which occur naturally wherever filtering is used.
So fine-grained events offer big performance benefits. This is particularly important with large datasets (think thousands) because the performance is perceptible to the user.