Flickering QuickWin drawings

[onkelhotte]

Hi there,

in my application I draw a few diagrams. Because I actualize them after every calculation, they flicker. I searched the forum for suggestions, but only found a hint to do it with getimage/putimage. But that slows my app down for 271% :-)

I know that QuickWin does not support any buffering.

The help topic of putimage says that the $GXOR command can be used for animations ($GXOR - Causes points in the existing screen image to be inverted wherever a point exists in the stored image. This behavior is like that of a cursor. If you perform an exclusive OR of an image with the background twice, the background is restored unchanged. This allows you to move an object around without erasing the background. The $GXOR constant is a special mode often used for animation).

Does anybody have experience with that? I only get a flickering negative image of the original.

Thanks in advance,

Markus

[Jugoslav_Dujic]

QuickWin flickers by design :-). You probably want $GPSET instead, but you have to prepare the drawing in another child window one way or another.

You can explore QWIN_XFT or XDblBuffer Xeffort samples instead.

[onkelhotte]

With getimage/putimage I draw the diagram in a seperate window that is positioned outside the screen (so the user does not see it) and copy with $GPSET to the final window, so there is no flickering. Butthis methodis very very slow... Rewriting the application to use GDI instead of QuickWin will be too time (and money) expensive. So my boss has to live with flickering, but he is used to it, so it is okay :-)

But this will be the last app that uses CVF and QuickWin, we will migrate to VS2005 and IVF9 soon. My next project will use C# for GUI and graphical output (GDI, DirectX, OpenGL, I dont know yet) and the calculation will be realised in Fortran.

Markus

[Jugoslav_Dujic]

Actually, QuickWin does the double-buffering (SetWindowConfig does a CreateCompatibleBitmap in the background), but the catch is that it doesn't have means to know when to BitBlt from the buffer to the window; so it does this after *every* RECTANGLE, OUTGTEXT etc...

I suggested once to add routine like BEGINDRAWQQ which would suppress BitBlt-ing until the ENDDRAWQQ is called. In this way, if you uses this pair around the drawing block, you'll get much faster operation, and if not, everything would work like before. However, to me, it seems like Intel people look at the QuickWin library as a dusty deck -- they still distribute it but I'm not sure if anybody knows what's in there anymore :-). (Not that I don't sympathize with that attitude -- heck, it dates from 1985 or so).

[anthonyrichards]

In my opinion, time spent mastering the use of the FORTRAN version of the Windows API for drawing to a window is time very well spent. It is surprisingly straightforward, using the GENERIC example as a template. You just have to get used to using a window procedure and learn how to 'handle' windows messages such as WM_SIZE, WM_MOVE, WM_PAINT. Of course, one advantage of QuickWIn is it is multithreaded, so your added number crunching code does not (I think) interfere with the GUI. It is true that in a windows programs, number-crunching can cause the GUI to freeze up or become sluggish for a period. Dis-satisfaction with this aspect normally leads one eventually to exploring how to start new threads and how to manage them.