CDC::BitBlt(...) - strange speed variations
-
Hi all, I'm trying to fix some efficiency issues with some graph-drawing code in my application. This is an MFC application, so I'm using CDCs. Different parts of the graph display are rendered to seperate in-memory CDCs, and then they are combined into a final in-memory CDC via BitBlt() calls. This final CDC is then BitBlt()ed to the window's CClientDC during OnPaint(). I've added some QueryPerformanceCounter() calls into my rendering code to try and figure out what calls are eating up the most cycles, and I'm seeing some wierd behaviour. Here's an example: <------------SNIP------------------> C2DTrajWindow::UpdateVirt(): m_memDC.BitBlt( 0, 0, 1280, 827, &m_decorationsMemDC, 0, 0, SRCAND ) ] took 0.017600 milliseconds C2DTrajWindow::UpdateVirt(): m_memDC.BitBlt( 0, 0, 1280, 839, &m_decorationsMemDC, 0, 0, SRCAND ) ] took 0.017600 milliseconds C2DTrajWindow::UpdateVirt(): m_memDC.BitBlt( 0, 0, 1280, 837, &m_decorationsMemDC, 0, 0, SRCAND ) ] took 876.786575 milliseconds C2DTrajWindow::UpdateVirt(): m_memDC.BitBlt( 0, 0, 1280, 814, &m_decorationsMemDC, 0, 0, SRCAND ) ] took 0.017879 milliseconds <------------SNIP------------------> As you can see, normally this BitBlt() operation takes very little time, but every now and then it jumps up to around 800ms. I can't figure out why! Any one have any suggestions? TIA, Pete
-
Hi all, I'm trying to fix some efficiency issues with some graph-drawing code in my application. This is an MFC application, so I'm using CDCs. Different parts of the graph display are rendered to seperate in-memory CDCs, and then they are combined into a final in-memory CDC via BitBlt() calls. This final CDC is then BitBlt()ed to the window's CClientDC during OnPaint(). I've added some QueryPerformanceCounter() calls into my rendering code to try and figure out what calls are eating up the most cycles, and I'm seeing some wierd behaviour. Here's an example: <------------SNIP------------------> C2DTrajWindow::UpdateVirt(): m_memDC.BitBlt( 0, 0, 1280, 827, &m_decorationsMemDC, 0, 0, SRCAND ) ] took 0.017600 milliseconds C2DTrajWindow::UpdateVirt(): m_memDC.BitBlt( 0, 0, 1280, 839, &m_decorationsMemDC, 0, 0, SRCAND ) ] took 0.017600 milliseconds C2DTrajWindow::UpdateVirt(): m_memDC.BitBlt( 0, 0, 1280, 837, &m_decorationsMemDC, 0, 0, SRCAND ) ] took 876.786575 milliseconds C2DTrajWindow::UpdateVirt(): m_memDC.BitBlt( 0, 0, 1280, 814, &m_decorationsMemDC, 0, 0, SRCAND ) ] took 0.017879 milliseconds <------------SNIP------------------> As you can see, normally this BitBlt() operation takes very little time, but every now and then it jumps up to around 800ms. I can't figure out why! Any one have any suggestions? TIA, Pete
Hi, OS? probably not really multitasking and hanging in another process. Sytem clean up? Kind of magic numbers? Swapfile operations? GSte
-
Hi, OS? probably not really multitasking and hanging in another process. Sytem clean up? Kind of magic numbers? Swapfile operations? GSte
Thanks for the reply. Sorry, you're right, I should have included more information. :-O I'm running on Windows 2000, and probably working this machine a little too hard with quite a few processes. As to the rest of you reply, I'm not really sure what information you're asking for? If you could, it'd be great if you could go into a little more detail as to exactly what information is relevent. It would be even GREATER if you could give me a little advice on how to collect it. Jeez, I don't ask for much, do I?! ;) Thanks again, Pete
-
Thanks for the reply. Sorry, you're right, I should have included more information. :-O I'm running on Windows 2000, and probably working this machine a little too hard with quite a few processes. As to the rest of you reply, I'm not really sure what information you're asking for? If you could, it'd be great if you could go into a little more detail as to exactly what information is relevent. It would be even GREATER if you could give me a little advice on how to collect it. Jeez, I don't ask for much, do I?! ;) Thanks again, Pete
Hi, Sorry that I didn't make it clear. Those were not questions but hints, what you should ask. Like, are there page misses, so the system as to relad memory from the swapfile. Is any process eating up CPU-time by atomic instructions (anti virus software/ multimedia player). If your using W2000 try to shut down most processes you can, to get the time measurement more reliable. See if there is a pattern in the time frame, like every third or fourth call is aout of order. I can't give you a solution, but just a few hints how to track the problem. And if anything fails, use your imagination. I once had a similiar problem and a wrongly installed outlook proofed to be the trouble maker. Regards GSte -- Even dwarves were born small --
-
Hi, Sorry that I didn't make it clear. Those were not questions but hints, what you should ask. Like, are there page misses, so the system as to relad memory from the swapfile. Is any process eating up CPU-time by atomic instructions (anti virus software/ multimedia player). If your using W2000 try to shut down most processes you can, to get the time measurement more reliable. See if there is a pattern in the time frame, like every third or fourth call is aout of order. I can't give you a solution, but just a few hints how to track the problem. And if anything fails, use your imagination. I once had a similiar problem and a wrongly installed outlook proofed to be the trouble maker. Regards GSte -- Even dwarves were born small --
Hi GSte, Thanks again for your input on this, I really appreciate it! Would you be able to point me in the right direction on how I can look into the page-misses stuff? Is this something I can investigate with in-code profiling, or with the Task Manager, or do I need some more specialized profiling tools? Also, after some more experimentation (including turning off my internet radio - doh!), I've found the following: - Minimizing the number of other processes seems to have negligable effect. - The slow calls only happen when the window size is being /increased/, never when it is being /decreased/. - If I resize the window slowly, then every other BitBlt() call is slow, e.g.: <-----------------SNIP--------------------> ... ... C2DTrajWindow::UpdateVirt(): m_memDC.BitBlt( 0, 0, 1280, 752, &m_decorationsMemDC, 0, 0, SRCAND ) ] took 0.011454 milliseconds C2DTrajWindow::UpdateVirt(): m_memDC.BitBlt( 0, 0, 1280, 755, &m_decorationsMemDC, 0, 0, SRCAND ) ] took 630.962036 milliseconds C2DTrajWindow::UpdateVirt(): m_memDC.BitBlt( 0, 0, 1280, 758, &m_decorationsMemDC, 0, 0, SRCAND ) ] took 0.015086 milliseconds C2DTrajWindow::UpdateVirt(): m_memDC.BitBlt( 0, 0, 1280, 762, &m_decorationsMemDC, 0, 0, SRCAND ) ] took 636.752995 milliseconds ... ... etc. <-----------------SNIP--------------------> I don't suppose you have any insights after seeing this information? Thanks again, Pete
-
Hi GSte, Thanks again for your input on this, I really appreciate it! Would you be able to point me in the right direction on how I can look into the page-misses stuff? Is this something I can investigate with in-code profiling, or with the Task Manager, or do I need some more specialized profiling tools? Also, after some more experimentation (including turning off my internet radio - doh!), I've found the following: - Minimizing the number of other processes seems to have negligable effect. - The slow calls only happen when the window size is being /increased/, never when it is being /decreased/. - If I resize the window slowly, then every other BitBlt() call is slow, e.g.: <-----------------SNIP--------------------> ... ... C2DTrajWindow::UpdateVirt(): m_memDC.BitBlt( 0, 0, 1280, 752, &m_decorationsMemDC, 0, 0, SRCAND ) ] took 0.011454 milliseconds C2DTrajWindow::UpdateVirt(): m_memDC.BitBlt( 0, 0, 1280, 755, &m_decorationsMemDC, 0, 0, SRCAND ) ] took 630.962036 milliseconds C2DTrajWindow::UpdateVirt(): m_memDC.BitBlt( 0, 0, 1280, 758, &m_decorationsMemDC, 0, 0, SRCAND ) ] took 0.015086 milliseconds C2DTrajWindow::UpdateVirt(): m_memDC.BitBlt( 0, 0, 1280, 762, &m_decorationsMemDC, 0, 0, SRCAND ) ] took 636.752995 milliseconds ... ... etc. <-----------------SNIP--------------------> I don't suppose you have any insights after seeing this information? Thanks again, Pete
hi again, Looks like we found the nasty guy. Page misses. Everytime you make the picture larger a new block of memory must be allocated. If the RAM is low, than a part of the memory must be swapped to the memory file on disk (aka swap file). And that's what takes so long. Only solution so far ( And I mean this serene) lots of RAM, RAM, RAM. How can I tell? You see, the first allocation gets swift. When you increase the picture size, the system will allocate a block of memory a liitle bit larger than needed. That makes the second enlargement pretty fast. The third enlargement must be reallocated again (slow). And so forth. Probably (I don't know for sure) you can preallocate a reasonable (lets say 1600*1200) amount of memory prior BitBlitting the immage the first time. That way by enlargening a smaller picture needn't to be reallocated until it exceeds the size of 1600*1200. But I don't know how this could be done. Maybe a code like this will work. Avoid flickering -- Disable Output BitBlitt(1600*1200) Enable Output BitBlitt(1280*600) BitBlitt(1280*610) and so on. How to en/disable painting the image depends. There are several functions for this purpose. Regards. Please referr to you most likely base class reference. Regards GSte GSte
-
hi again, Looks like we found the nasty guy. Page misses. Everytime you make the picture larger a new block of memory must be allocated. If the RAM is low, than a part of the memory must be swapped to the memory file on disk (aka swap file). And that's what takes so long. Only solution so far ( And I mean this serene) lots of RAM, RAM, RAM. How can I tell? You see, the first allocation gets swift. When you increase the picture size, the system will allocate a block of memory a liitle bit larger than needed. That makes the second enlargement pretty fast. The third enlargement must be reallocated again (slow). And so forth. Probably (I don't know for sure) you can preallocate a reasonable (lets say 1600*1200) amount of memory prior BitBlitting the immage the first time. That way by enlargening a smaller picture needn't to be reallocated until it exceeds the size of 1600*1200. But I don't know how this could be done. Maybe a code like this will work. Avoid flickering -- Disable Output BitBlitt(1600*1200) Enable Output BitBlitt(1280*600) BitBlitt(1280*610) and so on. How to en/disable painting the image depends. There are several functions for this purpose. Regards. Please referr to you most likely base class reference. Regards GSte GSte
I follow your reasoning, and it does seem completely reasonable. The only thing is, I don't see why BitBlt() is /allocating/ memory. As far as I was aware, BitBlt only copies blocks of memory. I /am/ allocating larger bitmaps as the window size increases, but that's done outside of the code I'm profiling. Here's how I'm profiling the code: <------------------SNIP----------------------> #ifdef _DEBUG LARGE_INTEGER time4; VERIFY( ::QueryPerformanceCounter( &time4 ) ); #endif m_memDC.BitBlt( 0, 0, m_iScreenWidth, clientRect.Height(), &m_decorationsMemDC, 0, 0, SRCAND ); #ifdef _DEBUG LARGE_INTEGER time5; VERIFY( ::QueryPerformanceCounter( &time5 ) ); #endif ... ... ... TRACE( " m_memDC.BitBlt( 0, 0, %i, %i, &m_decorationsMemDC, 0, 0, SRCAND ) ] took %f\tmilliseconds\n" , m_iScreenWidth, clientRect.Height(), ((time5.QuadPart - time4.QuadPart)/(double)freq.QuadPart)*1000 ); <------------------SNIP----------------------> As you can see, the only thing I'm timing is that one call to BitBlt(...), so it's definitely something within that method that's slowing down. One thought I had was that maybe BitBlt() is doing some behind-the-scenes allocation for some reason? Or perhaps there's some lazy-initialization going on where the CBitmaps attached to my CDCs only allocate memory when needed, in this case somewhere within BitBlt(). That doesn't really make sense though - I'm drawing into the source CDC before the guilty BitBlt() call (and presumably the memory would have to be allocated then), and I call m_memDC.BitBlt( 0, 0, m_iScreenWidth, clientRect.Height(), NULL, 0, 0, WHITENESS ); earlier as well, so as far as I can tell both the source and destination DCs' CBitmaps should already be allocated when that slow call BitBlt() happens. Strange, no? Anyways, thanks once again for your help. If you have any further thoughts, obviously I'd love to hear them! Cheers, Pete
-
Hi all, I'm trying to fix some efficiency issues with some graph-drawing code in my application. This is an MFC application, so I'm using CDCs. Different parts of the graph display are rendered to seperate in-memory CDCs, and then they are combined into a final in-memory CDC via BitBlt() calls. This final CDC is then BitBlt()ed to the window's CClientDC during OnPaint(). I've added some QueryPerformanceCounter() calls into my rendering code to try and figure out what calls are eating up the most cycles, and I'm seeing some wierd behaviour. Here's an example: <------------SNIP------------------> C2DTrajWindow::UpdateVirt(): m_memDC.BitBlt( 0, 0, 1280, 827, &m_decorationsMemDC, 0, 0, SRCAND ) ] took 0.017600 milliseconds C2DTrajWindow::UpdateVirt(): m_memDC.BitBlt( 0, 0, 1280, 839, &m_decorationsMemDC, 0, 0, SRCAND ) ] took 0.017600 milliseconds C2DTrajWindow::UpdateVirt(): m_memDC.BitBlt( 0, 0, 1280, 837, &m_decorationsMemDC, 0, 0, SRCAND ) ] took 876.786575 milliseconds C2DTrajWindow::UpdateVirt(): m_memDC.BitBlt( 0, 0, 1280, 814, &m_decorationsMemDC, 0, 0, SRCAND ) ] took 0.017879 milliseconds <------------SNIP------------------> As you can see, normally this BitBlt() operation takes very little time, but every now and then it jumps up to around 800ms. I can't figure out why! Any one have any suggestions? TIA, Pete
What is the value for rcClipBox if you call CRect rcClipBox; m_memDC.GetClipBox(rcClipBox); TRACE("l: %d, t: %d, r: %d, b: %d", rcClipBox.left, rcClipBox.top, rcClipBox.right, rcClipBox.bottom); just prior to each BitBlt call?
:suss: Pssst. You see that little light on your monitor? That's actually a government installed spy camera. Smile and wave to big brother!
-
What is the value for rcClipBox if you call CRect rcClipBox; m_memDC.GetClipBox(rcClipBox); TRACE("l: %d, t: %d, r: %d, b: %d", rcClipBox.left, rcClipBox.top, rcClipBox.right, rcClipBox.bottom); just prior to each BitBlt call?
:suss: Pssst. You see that little light on your monitor? That's actually a government installed spy camera. Smile and wave to big brother!
C2DTrajWindow::UpdateVirt: ClipBox - l: 0, t: 0, r: 1280, b: 740 m_memDC.BitBlt( 0, 0, 1280, 740, &m_decorationsMemDC, 0, 0, SRCAND ) ] took 617.089323 milliseconds C2DTrajWindow::UpdateVirt: ClipBox - l: 0, t: 0, r: 1280, b: 748 m_memDC.BitBlt( 0, 0, 1280, 748, &m_decorationsMemDC, 0, 0, SRCAND ) ] took 1.938794 milliseconds C2DTrajWindow::UpdateVirt: ClipBox - l: 0, t: 0, r: 1280, b: 750 m_memDC.BitBlt( 0, 0, 1280, 750, &m_decorationsMemDC, 0, 0, SRCAND ) ] took 628.530162 milliseconds C2DTrajWindow::UpdateVirt: ClipBox - l: 0, t: 0, r: 1280, b: 760 m_memDC.BitBlt( 0, 0, 1280, 760, &m_decorationsMemDC, 0, 0, SRCAND ) ] took 1.418616 milliseconds
-
Hi all, I'm trying to fix some efficiency issues with some graph-drawing code in my application. This is an MFC application, so I'm using CDCs. Different parts of the graph display are rendered to seperate in-memory CDCs, and then they are combined into a final in-memory CDC via BitBlt() calls. This final CDC is then BitBlt()ed to the window's CClientDC during OnPaint(). I've added some QueryPerformanceCounter() calls into my rendering code to try and figure out what calls are eating up the most cycles, and I'm seeing some wierd behaviour. Here's an example: <------------SNIP------------------> C2DTrajWindow::UpdateVirt(): m_memDC.BitBlt( 0, 0, 1280, 827, &m_decorationsMemDC, 0, 0, SRCAND ) ] took 0.017600 milliseconds C2DTrajWindow::UpdateVirt(): m_memDC.BitBlt( 0, 0, 1280, 839, &m_decorationsMemDC, 0, 0, SRCAND ) ] took 0.017600 milliseconds C2DTrajWindow::UpdateVirt(): m_memDC.BitBlt( 0, 0, 1280, 837, &m_decorationsMemDC, 0, 0, SRCAND ) ] took 876.786575 milliseconds C2DTrajWindow::UpdateVirt(): m_memDC.BitBlt( 0, 0, 1280, 814, &m_decorationsMemDC, 0, 0, SRCAND ) ] took 0.017879 milliseconds <------------SNIP------------------> As you can see, normally this BitBlt() operation takes very little time, but every now and then it jumps up to around 800ms. I can't figure out why! Any one have any suggestions? TIA, Pete
Have you ever look at how many processes might be running on you machine at one time. BitBlt() is like every other piece of code running on youre machine, it is a matter of priority (every body gets a slice of the processors time [at least they are supposed to]). I discover a virus once, becuase I notice that processor time was being eatin (slow down in resonse time). May be someone can give you an idea for improving the speed if you explained why the graph is rendered in pieces, instead of as a whole. INTP "The more help VB provides VB programmers, the more miserable your life as a C++ programmer becomes." Andrew W. Troelsen
-
C2DTrajWindow::UpdateVirt: ClipBox - l: 0, t: 0, r: 1280, b: 740 m_memDC.BitBlt( 0, 0, 1280, 740, &m_decorationsMemDC, 0, 0, SRCAND ) ] took 617.089323 milliseconds C2DTrajWindow::UpdateVirt: ClipBox - l: 0, t: 0, r: 1280, b: 748 m_memDC.BitBlt( 0, 0, 1280, 748, &m_decorationsMemDC, 0, 0, SRCAND ) ] took 1.938794 milliseconds C2DTrajWindow::UpdateVirt: ClipBox - l: 0, t: 0, r: 1280, b: 750 m_memDC.BitBlt( 0, 0, 1280, 750, &m_decorationsMemDC, 0, 0, SRCAND ) ] took 628.530162 milliseconds C2DTrajWindow::UpdateVirt: ClipBox - l: 0, t: 0, r: 1280, b: 760 m_memDC.BitBlt( 0, 0, 1280, 760, &m_decorationsMemDC, 0, 0, SRCAND ) ] took 1.418616 milliseconds
OK, how about the clipbox values for m_decorationsMemDC?
:suss: Pssst. You see that little light on your monitor? That's actually a government installed spy camera. Smile and wave to big brother!
-
OK, how about the clipbox values for m_decorationsMemDC?
:suss: Pssst. You see that little light on your monitor? That's actually a government installed spy camera. Smile and wave to big brother!
Hi Jack, Pretty much the same story: <---------------------SNIP-----------------------> C2DTrajWindow::UpdateVirt: m_memDC's ClipBox - l: 0, t: 0, r: 1280, b: 807 m_decorationsMemDC's ClipBox - l: 0, t: 0, r: 1280, b: 807 m_memDC.BitBlt( 0, 0, 1280, 807, &m_decorationsMemDC, 0, 0, SRCAND ) ] took 684.505154 milliseconds C2DTrajWindow::UpdateVirt: m_memDC's ClipBox - l: 0, t: 0, r: 1280, b: 809 m_decorationsMemDC's ClipBox - l: 0, t: 0, r: 1280, b: 809 m_memDC.BitBlt( 0, 0, 1280, 809, &m_decorationsMemDC, 0, 0, SRCAND ) ] took 2.769346 milliseconds C2DTrajWindow::UpdateVirt: m_memDC's ClipBox - l: 0, t: 0, r: 1280, b: 812 m_decorationsMemDC's ClipBox - l: 0, t: 0, r: 1280, b: 812 m_memDC.BitBlt( 0, 0, 1280, 812, &m_decorationsMemDC, 0, 0, SRCAND ) ] took 683.831325 milliseconds C2DTrajWindow::UpdateVirt: m_memDC's ClipBox - l: 0, t: 0, r: 1280, b: 815 m_decorationsMemDC's ClipBox - l: 0, t: 0, r: 1280, b: 815 m_memDC.BitBlt( 0, 0, 1280, 815, &m_decorationsMemDC, 0, 0, SRCAND ) ] took 2.098870 milliseconds <---------------------SNIP-----------------------> Cheers, Pete