🚀 go-pugleaf

You might try first calling InvalidateRect for the window with the RECT 
element set to NULL and the other argument set to repaint the background and 
after that call Repaint.

.  Ed

> Wookie wrote in message
> news:465B192D.18A0FD94@skynet.be...
>
> I am working inside a thread that drives a LCD screen and a camera. I
> have to synchronize the display on the LCD and the camera acquisition. I
> would like to know if there is any window message that is sent when a
> window has been repainted (a sort of WM_ENDPAINT). I do call the Repaint
> method of TWinControl but most of the time, the camera acquires a mix of
> the previous frame and the new one. How can I be sure the LCD has been
> fully repainted ?

Wookie wrote:

>have to synchronize the display on the LCD and the camera acquisition.

So you are using a camera to capture the LCD display?

> most of the time, the camera acquires a mix of
>the previous frame and the new one.
> How can I be sure the LCD has been fully repainted ?

I think you also need to take into account the LCD latency.

Il Mon, 28 May 2007 20:02:21 +0200, Wookie <fa067235@skynet.be> ha scritto:

>Hi all,
>
>I am working inside a thread that drives a LCD screen and a camera. I
>have to synchronize the display on the LCD and the camera acquisition. I
>would like to know if there is any window message that is sent when a
>window has been repainted (a sort of WM_ENDPAINT). I do call the Repaint
>method of TWinControl but most of the time, the camera acquires a mix of
>the previous frame and the new one. How can I be sure the LCD has been
>fully repainted ?

Hi Christophe,

    I'm not sure if this approach can help you, but you could try to paint
directly from (synchronized with) the thread. Then you can invoke the GDIFlush
API whenever you need to have the screen updated. 

For example:

void __fastcall TYourThread::Execute()
{
    while ( !Terminated ) {
        TCanvas* Canvas = /* acquire here the control's canvas */
        Canvas->Lock();

        // Perform here the painting
 
        Canvas->Unlock();
        GdiFlush();
    }
}

or, for exception safety, something like this:

class TCanvasLockManager : boost::noncopyable {
public:
    TCanvasLockManager( TCanvas& Canvas )
      : canvas_( Canvas ) { canvas_.Lock(); }
    ~TCanvasLockManager() throw() { canvas_.Unlock(); }
    operator bool() const { return true; }
private:
    TCanvas& canvas_;
};

#define  LOCK_CANVAS( C ) \
    if ( bool const & C_lk ## __LINE__ = TCanvasLockManager( ( C ) ) )

struct TGDIFlusher {
    ~TGDIFlusher() throw() { GdiFlush(); }
};

void __fastcall TYourThread::Execute()
{
    while ( !Terminated ) {
        TCanvas* Canvas = /* acquire here the control's canvas */
        TGDIFlusher const GDIFlusher;
        LOCK_CANVAS( *Canvas ) {
            // Perform here the painting
        }
    }
}

Regards

Giuliano

Yes, but there is an optical system between the LCD and the camera.

> So you are using a camera to capture the LCD display?

Yes, I take it into account but even, it seems that sometimes, the LCD has
not been completely refreshed ...

>
> I think you also need to take into account the LCD latency.

Christophe

Hi Giuliano,

Thanks for the sugestion but unfortunately it does not help. It seems that the
problem comes from the hardware driving the LCD. Altough, they ensure a refresh
rate of 60 Hz, in practice I have to wait a quite long time between the display
function and the actual display on the LCD.

Christophe



> Il Mon, 28 May 2007 20:02:21 +0200, Wookie <fa067235@skynet.be> ha scritto:
>
> >Hi all,
> >
> >I am working inside a thread that drives a LCD screen and a camera. I
> >have to synchronize the display on the LCD and the camera acquisition. I
> >would like to know if there is any window message that is sent when a
> >window has been repainted (a sort of WM_ENDPAINT). I do call the Repaint
> >method of TWinControl but most of the time, the camera acquires a mix of
> >the previous frame and the new one. How can I be sure the LCD has been
> >fully repainted ?
>
> Hi Christophe,
>
>     I'm not sure if this approach can help you, but you could try to paint
> directly from (synchronized with) the thread. Then you can invoke the GDIFlush
> API whenever you need to have the screen updated.
>
> For example:
>
> void __fastcall TYourThread::Execute()
> {
>     while ( !Terminated ) {
>         TCanvas* Canvas = /* acquire here the control's canvas */
>         Canvas->Lock();
>
>         // Perform here the painting
>
>         Canvas->Unlock();
>         GdiFlush();
>     }
> }
>
> or, for exception safety, something like this:
>
> class TCanvasLockManager : boost::noncopyable {
> public:
>     TCanvasLockManager( TCanvas& Canvas )
>       : canvas_( Canvas ) { canvas_.Lock(); }
>     ~TCanvasLockManager() throw() { canvas_.Unlock(); }
>     operator bool() const { return true; }
> private:
>     TCanvas& canvas_;
> };
>
> #define  LOCK_CANVAS( C ) \
>     if ( bool const & C_lk ## __LINE__ = TCanvasLockManager( ( C ) ) )
>
> struct TGDIFlusher {
>     ~TGDIFlusher() throw() { GdiFlush(); }
> };
>
> void __fastcall TYourThread::Execute()
> {
>     while ( !Terminated ) {
>         TCanvas* Canvas = /* acquire here the control's canvas */
>         TGDIFlusher const GDIFlusher;
>         LOCK_CANVAS( *Canvas ) {
>             // Perform here the painting
>         }
>     }
> }
>
> Regards
>
> Giuliano

Wookie wrote:

>Thanks for the sugestion but unfortunately it does not help. It seems that the
>problem comes from the hardware driving the LCD. Altough, they ensure a refresh
>rate of 60 Hz, in practice I have to wait a quite long time between the display
>function and the actual display on the LCD.

Ok, so the hardware is sending the signal to the pixels every 17 ms
Then each pixel takes what, 20 ms to turn on?
And you want a full frame, presumably, so you need to know the start
of the second refresh, (or wait 3 refresh times), plus the LCD
latency. So, somewhere around 70ms. Does that sound about right?
What is your "in practice" figure?

Yes it turns around 70 msec to get a "stable" image. Images are vertical and
horizontal grating and some full white screens. As I have to wait at least 70 msec
and then wait the next synchro top of the camera, I am decreasing the acquisition
frequency. If I decrease those 70 msec, than for sure I will get a mix of two
frames. I was hoping (but I think there is no way to get it) to know by any way when
the LCD has been completely refreshed ...

Christophe

> Ok, so the hardware is sending the signal to the pixels every 17 ms
> Then each pixel takes what, 20 ms to turn on?
> And you want a full frame, presumably, so you need to know the start
> of the second refresh, (or wait 3 refresh times), plus the LCD
> latency. So, somewhere around 70ms. Does that sound about right?
> What is your "in practice" figure?

Christophe MINETTI wrote:
> Yes it turns around 70 msec to get a "stable" image. Images are vertical 
> and
> horizontal grating and some full white screens. As I have to wait at least 
> 70 msec
> and then wait the next synchro top of the camera, I am decreasing the 
> acquisition
> frequency. If I decrease those 70 msec, than for sure I will get a mix of 
> two
> frames. I was hoping (but I think there is no way to get it) to know by 
> any way when
> the LCD has been completely refreshed ...

Maybe I'm way off here, but are you able to do something like this:

1. Send new frame to LCD
2. Pause for about 80ms.
3. Tell camera to grab frame.
4. Wait till camera has frame.
5. Goto 1.

Jon 

Christophe MINETTI wrote:

>Yes it turns around 70 msec to get a "stable" image.
>As I have to wait at least 70 msec
>and then wait the next synchro top of the camera, I am decreasing the acquisition
>frequency. If I decrease those 70 msec, than for sure I will get a mix of two
>frames.

If you go to DirectDraw or DirectX you might be able to pick up a bit
by drawing the next frame on a hidden page while you are waiting for
the LCD pixels to turn on.
http://msdn2.microsoft.com/en-us/library/ms792915.aspx

Pre-Paint to hidden page
Loop:
WaitForBlank	less than 17ms (end of last scanline)
Flip page
Paint to hidden page
WaitForBlank	17ms
Wait for LCD	5 to 20 ms depending on LCD
Click Camera
repeat Loop.

So, if you have a gamer's LCD, and your camera can sync up and capture
within 12 ms, then you could get 30 fps
With a regular LCD, you would be looking at a maximum of 20 fps.
And if the camera is slow, 15 fps.

> I was hoping (but I think there is no way to get it) to know by any way when
>the LCD has been completely refreshed ...

No, there is no way, as that has to do with the speed of the crystals,
and not the electronics.

Jonathan Benedicto wrote:

>Maybe I'm way off here, but are you able to do something like this:

I think that's what he is saying, yes
But he wants a higher frame rate.

Thanks for your help ! It's getting more clear for me.

Christophe

Bob Gonder wrote:

> Christophe MINETTI wrote:
>
> >Yes it turns around 70 msec to get a "stable" image.
> >As I have to wait at least 70 msec
> >and then wait the next synchro top of the camera, I am decreasing the acquisition
> >frequency. If I decrease those 70 msec, than for sure I will get a mix of two
> >frames.
>
> If you go to DirectDraw or DirectX you might be able to pick up a bit
> by drawing the next frame on a hidden page while you are waiting for
> the LCD pixels to turn on.
> http://msdn2.microsoft.com/en-us/library/ms792915.aspx
>
> Pre-Paint to hidden page
> Loop:
> WaitForBlank    less than 17ms (end of last scanline)
> Flip page
> Paint to hidden page
> WaitForBlank    17ms
> Wait for LCD    5 to 20 ms depending on LCD
> Click Camera
> repeat Loop.
>
> So, if you have a gamer's LCD, and your camera can sync up and capture
> within 12 ms, then you could get 30 fps
> With a regular LCD, you would be looking at a maximum of 20 fps.
> And if the camera is slow, 15 fps.
>
> > I was hoping (but I think there is no way to get it) to know by any way when
> >the LCD has been completely refreshed ...
>
> No, there is no way, as that has to do with the speed of the crystals,
> and not the electronics.