This is to help anyone else who runs into this problem.
I noticed that my app, when presented with a large amount of data, will cause Windows to flicker so badly that Windows itself becomes unusable. When my app is running, every windows app running including my own will refresh itself rapidly. Hundreds of paint events a second. This leads to so little control over the OS that the user can only restart Windows as nothing else will respond.
I’ll add my solution below.
The cause is apparently instantiating timers. If I instantiate say 5,000 timers while loading data from disk, the flicker happens and keeps on happening. The timers aren’t set to run. Just created in memory. If I delay the instantiation of the timers until after I’ve finished loading other data, the app works fine. I’m sure it must be conflicting with something happening during my loading process but I don’t know exactly what. This isn’t affected by the loading happening during the open event or minutes later.
Now you might be wondering why I’d use thousands of timers. Each of my objects implements an observer pattern so that anything that is interested in it can be notified of changes easily.
Of course, now I wonder if it’s wise to create so many timers in memory. Few of them will ever be set to time at any one time. However, is it wise to have 5,000? 10,000? 100,000?
How about one timer that handles changed data and sends messages every (n) millisenconds to the relevant target?
[quote=185136:@Stephen Dodd]Now you might be wondering why I’d use thousands of timers. Each of my objects implements an observer pattern so that anything that is interested in it can be notified of changes easily.
Of course, now I wonder if it’s wise to create so many timers in memory. Few of them will ever be set to time at any one time. However, is it wise to have 5,000? 10,000? 100,000?[/quote]
Why would you use timers to implement observer ?
Yeah, that’s a good question…
I think you’re holding it backwards.
Sorry. May have been describing it wrong.
In any case, changed it so that any object that wants to fire off notifications simply grabs a new disposable timer from a factory. That should keep the timer count down quite low.
Again why are you using timers for this pattern ?
I’ve used this pattern and timers are definitely not required
It’s an easy way to allow multiple changes to an object to be set before a change notification is sent out.
It guarantees data changes that are sent out to UI elements come in on the main thread.
Is there a better way to do this?
delaying notifications is a good thing to remove duplicates and make sure you redraw only after last change.
Stephen, I do the same in my code a lot. It’s important to make sure that you identify recurring requests so that you only use one Timer object and not lots of them. Do you do that? I can send you some code that manages that, allowing you to prevent duplication of timers for the same callback with or without additional parameters. (It’s straight-forward and rather simple, though - I just wonder why you’d end up with 100s of active Timers, so maybe you do make some wrong assumptions that can be avoided).