> I am also trying to do human behavioral studies using LabView on a
> small budget. I share your pain. Unfortunately I invested a lot of
> time and effort in my labview6 program only to come up against the
> same obstacles you have. Part of my study involves subjects moving a
> cursor connected to a pot to track a moving target on the screen. I
> have tried all of the suggestions the gurus gave you, all to no avail.
> (I refresh the screen at 60Hz, but things still look bad if the cursor
> moves fast enough.) I was wondering if any of the gurus know how we
> could easily employ ActiveX for our displays. It seems that the
> cursor in Windows2000 always looks good, no matter how fast it moves.
I'm sorry to hear that we have failed you, but if you are willing to
write the SW the right way, you can make it work. Active X will
probably not help that much. I'm not familiar with every control out
there, but what you really need to do is use lower level HW access, like
the cursor is doing. The LV graphics are done on top of Windows using
what is know as the GDI or graphics device interface. It helps to make
lots of video and printers work roughly the same, but it is sort of
primitive and sort of old. It doesn't expose enough control to be able
to reduce the flicker that you are talking about, because what you
really have to do is to synchronize the drawing with the monitor's
refresh. If they aren't in synch, then you get a jumpy update or you
get jagged graphics edges. It is much like setting up a strobe light.
You need to synchronize the other things in your experiment to the
strobe or everything gets out of whack.
As I said in my earlier post, I think the best way to accomplish this
flicker-free graphics is to use DirectDraw. It is part of DirectX and
is how many of the PC games are written. You may be able to do the
synchronization through OpenGL, but when we last checked, it was not in
the implementation that we wanted to use. Specifically what you want to
use is what is called double-buffering or back-buffering. It is where
two screens or windows worth of memory are set aside, and when a frame
of your drawing is complete, you schedule to have the buffers flipped.
This flipping will not occur while the CRT is tracing the screen, but
will wait until the next ~60HZ tick when it can swap pointers so that
the next trace will come from the complete buffer. This is really the
only way to guarantee that no flicker takes place because the image the
user sees is always complete, no partial images with old and new or
erased but still drawing.
I know that this sounds like something that should be more simple, but
it is one of those things that game SW deals with all the time and other
SW really doesn't need, therefore normal graphics APIs don't support it.
FYI, the poor man's method of doing this is to use a bitmap to draw the
graphics and copy the bitmap to the screen when everything is ready.
This is what LV does to provide smooth updates or offscreen drawing. It
gets rid of most flicker, but not all.
Sorry that there isn't a simpler solution.
Greg McKaskle
