From: Lyle Johnson <lyle@...>
Date: 2003-01-15T05:15:39+09:00
Subject: Re: FXRuby problem on Windows

Daniel P. Zepeda wrote:

>> Device contexts (i.e. FXDCWindow instances) are just supposed to be 
>> temporary objects, not things that you hang on to for the life of a 
>> program. They are most often constructed and torn down within a 
>> SEL_PAINT handler, although there are some other times you might need to
>> use them (for some examples, see the scribble.rb example program).
> 
> The documentation shows this as well. The reason I created the Device
> Contexts and kept them around for the life of the application is that I
> was using them to do crude animations.

Ah.

> I figured (with no real basis) that
> setting up/tearing down Device Contexts every 10 milliseconds or so was
> wasteful and that just setting them up once and using them throughout the
> application would make the program run better. Am I wrong? Given that I
> want to use the Device Context every 10 milliseconds, doing crude
> animation, do you still recommend that I set up/tear down the Device
> Contexts each time, that is, for the example below, run the onPaint
> example below every 10 ms with a slightly different @image each time?

OK. In that case, you're right that the cost of instantiating a new 
FXDCWindow object every 10 milliseconds could start to bog things down. 
So another approach that I think will work is to hang on to the device 
contexts (as you did before) and then use FXDCWindow#begin to lock the 
device context before drawing into it.

So I guess during initialization you'd want to construct the device 
contexts (for the canvas and the image) and then immediately unlock them:

     @sdc = FXDCWindow( @canvas )
     @sdc.end
     @idc = FXDCWindow( @image )
     @idc.end

and then when you "really" need to use them, call begin and pass in the 
associated drawable object:

     def onPaint( sender, sel, event )
       @sdc.begin( @canvas )
       @sdc.drawImage( @image, 0, 0 )
       @sdc.end
     end

Be sure to make a similar change in the image drawing routine(s).

Give this a shot, and if the performance still seems unacceptable, maybe 
we can investigate some other optimizations (e.g. double-buffered 
drawing of the image).

Hope this helps,

Lyle