Control event firing frequency though attaching/detaching to the event. Bad practice?

Yesterday I provided an answer to the question How do you control event firing in C#? which, in short, asks the following:

"There is an event that fires whenever a new frame is received from the camera. However, this happens more frequently than I'd like ... How can I control when the event fires?"

In my answer I provided the code below, and this morning I found that I had 2 downvotes without any comments. My concern is not mainly the loss of rep, but rather that this is logic that I am using myself in various applications, and that the downvo开发者_JAVA技巧tes could indicate that my implementations are bad practice or bad for performance. Thus, I am asking this question to clarify if there is anything wrong with attaching/detaching event controllers in this manner?

public MyObject()
{    
   MyTimer = new System.Timers.Timer(100); // 10 Hz
   MyTimer.Elapsed += new ElapsedEventHandler(OnTimedEvent);
   MyTimer.Enabled = true;
}

private void ImageDataUpdated(object sender, EventArgs e) 
{
   // detach from the event to keep it from firing until the timer event has fired.
   MyImageObject.Update -= new UpdateEventHandler(ImageDataUpdated);

    // do stuff
}

private static void OnTimedEvent(object source, ElapsedEventArgs e)
{
    // (re-)attach to the event handler.
   MyImageObject.Update += new UpdateEventHandler(ImageDataUpdated); 
}

In addition I wrote the following, referring to that it is possible to check if you have any subscribers before actually preparing the data to send to the subscriber. And in some cases this can lead to reduced CPU usage. To me it seems right (again I do this myself), but is there anything wrong with this statement?

Using this strategy there is a good chance that you are preventing the underlying image object from doing additional work while the event handler is detached (of course this depends on the implementation of the image object). Chances are that you are saving CPU-cycles for your own image processing.

I imagine they felt that dynamically adding and removing events, based on an unrelated timer, was a bad thing. While that is a neat trick that might be useful somewhere, someday, I tend to agree with them. External control over other object's event handlers does not indicate good encapsulation.

The alternative is to simply check that sufficient time has elapsed in the receiving event handler between calls and decide whether to process or not. This is more consistent with how logic works in real-time games or similar apps and means you are not constantly connecting and disconnecting event handlers from the outside.

The overhead of an actual event call itself is quite small, so do not worry about a few calls per frame, so long as the "slow part" (i.e. the bit doing the actual work) is not executing every time.