Extreme Flicker of All Apps under Windows

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?

Yup

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

  1. It’s an easy way to allow multiple changes to an object to be set before a change notification is sent out.

  2. 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.

  1. don’t notify on single property changes - only on the group of changes
    That requires notifications have a means to carry more than one atom of data

  2. is the concern that a thread sends out notifications and those are executed on a secondary thread and not the main thread ?
    Changing the model object should be possible from any thread and the view (UI object) then updates.
    However IF your model and view are intermixed then you have this issue.

  1. Yes. I send out the entire changed object as a notification. However often several properties in a row will be updated, each triggering a notification. The timer ensures only a single notification is sent at the end of the modifications. If you can suggest a better way to do this, I’d like to hear. :slight_smile:

  2. Well, UI elements subscribe to be notified when the data changes. The UI and data are separate. This changed data may have been triggered by an external sync on a separate thread. This ensures the notifications are received on the main thread.

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).