Hi Jens,
Thank you for your comments. The behavior you're describing results from PCM's desire to scale across a wide range of customer sizes. In the case of Events the same PCM server module is actually feeding data to both the Network Management Home view and the Events view. This PCM server module can be receiving hundreds of events per second from your PCM agent(s) and assembling them in real time into a cohesive data set.
In the case of the Home view only counts are needed by the screen, so the data to be transferred from server to GUI is very small and easy to compute quickly. But the Events view shows very extensive data about each event displayed; only enough data to satisfy the screen is transferred (so if you have 100k events only enough for the page shown, maybe 50 events, will be sent) but the computation of exactly what data to transfer from server to client can be very intensive depending on things like how many events have arrived since the last update, what filters are being applied to the data shown, how the data is sorted, etc. If updates to the Events view weren't "batched" and updated periodically rather than on a per-event basis the resources (primarily CPU and memory) of the system(s) running the PCM client and server would be noticeably affected and performance of the entire PCM application, and perhaps other applications running on the same systems, could be significantly degraded.
It was also felt that, from a usability perspective, the data set could update so rapidly - there could be hundreds of events received per second - that updating the client display in real-time would be undesirable. Even tens, or even five, new events per second scrolling through your a displayed page of the most recent 50 events received would be hard for most humans to make sense of.
Regards,
SVB