Re: How to minimize jitter in BitBlit to screen ?

It sounds like you've done your homework, so here's a few suggestions
that may or may not help.

Since you're performing sub-millisecond operations, you could glean a
lot of info from the kernel profiler. You can use it to find out
what's happening with your thread--is it being blocked? Is it running
at the priority/quantum you think it is? Are you waiting on some
semaphore? Is MFC "helping you" by adding critical sections that are
slowing you down? There's some good info about getting started on Sue
Loh's weblog, as well as the online docs.

Is OnPaint() being called IN ADDITION to OnMyScroll()? You should use
one or the other.

Also, since you're using MFC, you might try a more direct way of
forcing the draw than the Windows asynchronous message. You could try
SendMessage() instead, or invalidate and redraw directly.

BTW, what happens to the jitter when you draw without the memory DC?
Is it still as "jittery" or is it hard to tell because of the flicker?
(I'm assuming by jitter that you mean scrolling that isn't smooth, not
screen filcker, right?)

Hope any of that helps,
Dan.

kuykens@xxxxxx wrote:
Hi All,

I am writing a program that in real time draws signals to the screen. I
have been struggling to get a smooth scroll of such signals. Maybe
someone has found a solution...

I am using MFC with the view being responsible to do the scroll and
redraw
I am using double buffering to paint to screen...
I am using a multimedia timer to get accurately timed drawing events...
I am using (another) multimedia timer to measure the delays in the code
Draw Interval is 50ms or less.

The delay times that I measure after the bitblt vary from 1500us to
6000us.
Th interval time is really steady with a jitter of 1ms max.

In fact I don't care about the length of the delay. What really bothers
me is the jitter in delay.
That results in jerky behaviour of the scrolling process. That may seem
awkward as it is only max 10% of the interval time. However, the
variation in delay is not completely random. Sequences of longer delay
appear which make the effect more visible, Also, this was a test
application. The real application uses a a few of these scrolling
panels which may emphasize the effect.

I tried the following techniques to solve the issue:

Set thread priority temporarily 0 and thread quantum 0 just prior to
the bitblt and restoring them immediately after the BitBlt. No effects
seen.

I deliberately put the actual scroll and redrawing of teh memory DC
after flippig the (previous) image to screen to minimize additional
(jitter) delay from the drawing process.

I did a short experiment on a normal PC running XP and using
directdraw's blt function to flip an image on screen (in this case
without using memoryDC double buffering). Also here teh same jitter was
observable.

Does anybody know how to minimize this jitter and really get smooth
scroll?

Thanks: Hans

The pseudo code looks like this:

// this is called through a callback on a multimedia timer
::OnMMTimer
{
StopTimer
Measure intrerval time
PostMessage( WM_MY_SCROLL , ....)
Restart timer
}


OnMyScroll()
{
CDC * pDC = GetDC();
pDC->BitBlt( 0 , 0 , rRect.Width() , rRect.Height() , &m_MemoryDC
, 0,0 , SRCCOPY);
ReleaseDC( pDC );

Measure delay

MyScrollDC( m_MemoryDC )
MyPaintDC( m_MemoryDC )
}

.

Relevant Pages

  • How to minimize jitter in BitBlit to screen ?
    ... have been struggling to get a smooth scroll of such signals. ... I am using a multimedia timer to get accurately timed drawing events... ... Th interval time is really steady with a jitter of 1ms max. ... In fact I don't care about the length of the delay. ...
    (microsoft.public.windowsce.embedded.vc)
  • Re: FPGA delay generator
    ... have jitter of some 10s of picoseconds. ... Even with a zero jitter 1GHz clock the generated delay will jitter 1ns. ... SRS generates delay using counters clocked by a crystal oscillator at ...
    (comp.arch.fpga)
  • Re: Equipting a test bench
    ... We get down around 5 ps RMS jitter for short delays. ... both jitter and insertion delay. ... perfectly linear and perfectly matched, ... But seriously, everybody should have a pulse generator of some sort, ...
    (sci.electronics.design)
  • Re: Write Signal on Disk II Question
    ... checked for sampling jitter using an oscilloscope? ... But I noticed another shocking thing: The timing loop I used to find ... the timing resolution is quite high, since the delay loop on the main ...
    (comp.sys.apple2)
  • Re: Write Signal on Disk II Question
    ... checked for sampling jitter using an oscilloscope? ... But I noticed another shocking thing: The timing loop I used to find ... the timing resolution is quite high, since the delay loop on the main ...
    (comp.sys.apple2)
Loading