What I really wanted in vc.net
-
"Use private DCs. They're not a resource bottleneck anymore, and you don't have to bother with all the saving and restoring." What do you mean when you say "private DCs"? Declared in the class as private or something WAY different? Mark Lenz
Windows allocates a private DC for a window if the window class (not the C++ class, mind you, but the class of the window as defined using RegisterClass() in Win32 or AfxRegisterClass() or AfxRegisterWndClass() in MFC) specifies CS_OWNDC as one of the class styles. This means that you never have to call GetDC() and ReleaseDC() more than once--call it once in your WM_CREATE handler or OnCreate() function, store it, and don't release it until you're ready to destroy the window. It also means none of this hOldPen = SelectObject(); SelectObject(oldPen) restoration garbage. GetDC()/ReleaseDC() are expensive calls, so you can not only simplify your code, you can also speed it up if your code is graphics-intensive.
The drawbacks? On NT/2000/XP, there are none. DCs are allocated from the system heap. On Win95/98/ME, they're allocated from the 64k GDI heap, which means they're somewhat limited (but nowhere near as badly as on Win3.1, since a lot of other structures were moved out of the GDI heap).
So, if you're running on NT/2000/XP, use them as much as possible. If you're running on 95/98/ME, use them when your GetDC()/ReleaseDC() usage is getting to be a pain to manage or a performance bottleneck. Tim Lesher http://www.lesher.ws
-
"Use private DCs. They're not a resource bottleneck anymore, and you don't have to bother with all the saving and restoring." What do you mean when you say "private DCs"? Declared in the class as private or something WAY different? Mark Lenz
Or use GDI+ which is an object oriented toolkit for GDI by MS.
Todd Smith
-
Windows allocates a private DC for a window if the window class (not the C++ class, mind you, but the class of the window as defined using RegisterClass() in Win32 or AfxRegisterClass() or AfxRegisterWndClass() in MFC) specifies CS_OWNDC as one of the class styles. This means that you never have to call GetDC() and ReleaseDC() more than once--call it once in your WM_CREATE handler or OnCreate() function, store it, and don't release it until you're ready to destroy the window. It also means none of this hOldPen = SelectObject(); SelectObject(oldPen) restoration garbage. GetDC()/ReleaseDC() are expensive calls, so you can not only simplify your code, you can also speed it up if your code is graphics-intensive.
The drawbacks? On NT/2000/XP, there are none. DCs are allocated from the system heap. On Win95/98/ME, they're allocated from the 64k GDI heap, which means they're somewhat limited (but nowhere near as badly as on Win3.1, since a lot of other structures were moved out of the GDI heap).
So, if you're running on NT/2000/XP, use them as much as possible. If you're running on 95/98/ME, use them when your GetDC()/ReleaseDC() usage is getting to be a pain to manage or a performance bottleneck. Tim Lesher http://www.lesher.ws
Thanks, I had never heard of them before. I'm having a problem where it looks like I'm running out of device contexts. I have a control which looks kinda like a fuel guage. The value that the needle represents is updated about every second, so the needle must be redrawn about every second. I have about 4 or 5 of these controls in my view. When I have been displaying the view for about 3 minutes, things start to get weird. All of my fonts revert to a standard font and it starts to draw white where there was supposed to another color. This starts to affect the title bar, making it white. Sometimes it even starts to affect other applications. Would using a private DC solve this, even running on Windows 98? Or is there something else I'm missing? Thanks. Mark Lenz
-
Thanks, I had never heard of them before. I'm having a problem where it looks like I'm running out of device contexts. I have a control which looks kinda like a fuel guage. The value that the needle represents is updated about every second, so the needle must be redrawn about every second. I have about 4 or 5 of these controls in my view. When I have been displaying the view for about 3 minutes, things start to get weird. All of my fonts revert to a standard font and it starts to draw white where there was supposed to another color. This starts to affect the title bar, making it white. Sometimes it even starts to affect other applications. Would using a private DC solve this, even running on Windows 98? Or is there something else I'm missing? Thanks. Mark Lenz
That definitely sounds like a resource leak. A private DC might appear to solve the problem, but it might just mask it. Look for calls to GetDC() that aren't balanced by calls to DeleteDC(). Also look for GDI objects that are created, selected into the DC, and then deleted before being selected back out--they won't actually be deleted, because they're still in use. Tim Lesher http://www.lesher.ws
-
That definitely sounds like a resource leak. A private DC might appear to solve the problem, but it might just mask it. Look for calls to GetDC() that aren't balanced by calls to DeleteDC(). Also look for GDI objects that are created, selected into the DC, and then deleted before being selected back out--they won't actually be deleted, because they're still in use. Tim Lesher http://www.lesher.ws
I have been using SaveDC() before I create any new GDI objects and then RestoreDC() when I'm done with them. Example: void DumbControl::OnPaint() { CPaintDC dc(this); int saveDC = dc.SaveDC(); CBrush brush; /*....using GDI object....*/ dc.RestoreDC(saveDC); } I make function calls within the OnPaint() method who take a pointer to the DC and then use GDI objects created within their scope, but those functions don't make a call to SaveDC(). Do I need to call SaveDC() in those functions as well, or am I missing something else? Thanks. Mark Lenz
-
That definitely sounds like a resource leak. A private DC might appear to solve the problem, but it might just mask it. Look for calls to GetDC() that aren't balanced by calls to DeleteDC(). Also look for GDI objects that are created, selected into the DC, and then deleted before being selected back out--they won't actually be deleted, because they're still in use. Tim Lesher http://www.lesher.ws
-
I had the same problem with a program I wrote. It's because Win2K manages it's GDI resources better. "The world has achieved brilliance without wisdom, power without conscience. Ours is a world of nuclear giants and ethical infants." - Omar Bradley
-
I have been using SaveDC() before I create any new GDI objects and then RestoreDC() when I'm done with them. Example: void DumbControl::OnPaint() { CPaintDC dc(this); int saveDC = dc.SaveDC(); CBrush brush; /*....using GDI object....*/ dc.RestoreDC(saveDC); } I make function calls within the OnPaint() method who take a pointer to the DC and then use GDI objects created within their scope, but those functions don't make a call to SaveDC(). Do I need to call SaveDC() in those functions as well, or am I missing something else? Thanks. Mark Lenz
I make function calls within the OnPaint() method who take a pointer to the DC and then use GDI objects created within their scope, but those functions don't make a call to SaveDC(). That's probably your problem. The path of execution looks like this: 1. Acquire DC 2. Save DC context 3. Call function 4. (in function) create resource 5. (in function) select resource into DC 6. (function returning) delete resource 7. Restore DC context Notice that you're still destroying the objects while they're still selected into the DC. The objects are probably what are leaking. Tim Lesher http://www.lesher.ws
-
Makes sense--under NT, device contexts aren't allocated in a small heap, as they are under Win 9x. Tim Lesher http://www.lesher.ws
-
I make function calls within the OnPaint() method who take a pointer to the DC and then use GDI objects created within their scope, but those functions don't make a call to SaveDC(). That's probably your problem. The path of execution looks like this: 1. Acquire DC 2. Save DC context 3. Call function 4. (in function) create resource 5. (in function) select resource into DC 6. (function returning) delete resource 7. Restore DC context Notice that you're still destroying the objects while they're still selected into the DC. The objects are probably what are leaking. Tim Lesher http://www.lesher.ws
hi... i've read your explanations, but there are still some things i don't get.. my normal drawing routine looks something like:
void CView::OnDraw(CDC *pDC)
{
CObjectList::iterator i;for (i = m\_ObjList.begin(); i != m\_ObjList.end(); i++) (\*i)->Draw(pDC);
}
//this is one of the objects i am drawing
void CDrawObject::Draw(CDC *pDC)
{
int i_save = pDC->SaveDC()pDC->SelectObject (&cp\_dashdot); pDC->SelectObject (&cf\_arial20); pDC->Rectangle (0, 0, 100, 100); //Aufräumen pDC->RestoreDC (i\_save);
}
i really like to make the pens and fonts member of the base class of all draw objects.. cause they all use the same font - and pen - settings and then select em into the device contexts.. my problem now is WHEN should i do the things you've told me to. (cause i found out that i am leaking resources.. when drawing more than 1000 objects or so (when printing out.. more than 6 pages,i got the standard font on WIN NT) and if this is a good idea to make this in a base class.. and what would be other ways to share the same font / pen - settings for all objects.. thanks in advance bernhard
Sometimes I think the surest sign for intelligent life elsewhere in the universe is that none of them ever tried to contact us.
-
hi... i've read your explanations, but there are still some things i don't get.. my normal drawing routine looks something like:
void CView::OnDraw(CDC *pDC)
{
CObjectList::iterator i;for (i = m\_ObjList.begin(); i != m\_ObjList.end(); i++) (\*i)->Draw(pDC);
}
//this is one of the objects i am drawing
void CDrawObject::Draw(CDC *pDC)
{
int i_save = pDC->SaveDC()pDC->SelectObject (&cp\_dashdot); pDC->SelectObject (&cf\_arial20); pDC->Rectangle (0, 0, 100, 100); //Aufräumen pDC->RestoreDC (i\_save);
}
i really like to make the pens and fonts member of the base class of all draw objects.. cause they all use the same font - and pen - settings and then select em into the device contexts.. my problem now is WHEN should i do the things you've told me to. (cause i found out that i am leaking resources.. when drawing more than 1000 objects or so (when printing out.. more than 6 pages,i got the standard font on WIN NT) and if this is a good idea to make this in a base class.. and what would be other ways to share the same font / pen - settings for all objects.. thanks in advance bernhard
Sometimes I think the surest sign for intelligent life elsewhere in the universe is that none of them ever tried to contact us.
Hmm... if this is all you're doing, I don't see the leak. As long as your objects get selected back out of the DC (which RestoreDC() should be doing), you should be in good shape. Are you sure there aren't any other places where you're leaking? Is it possible that you're destroying CDrawObjects, but not destroying some CGI objects they contain? Tim Lesher http://www.lesher.ws
-
Hmm... if this is all you're doing, I don't see the leak. As long as your objects get selected back out of the DC (which RestoreDC() should be doing), you should be in good shape. Are you sure there aren't any other places where you're leaking? Is it possible that you're destroying CDrawObjects, but not destroying some CGI objects they contain? Tim Lesher http://www.lesher.ws
well.. i was inspecting my code once again.. and there i saw the problem (at least i guess it was the problem):
CRepDrawFont::CRepDrawFont()
{
try
{
cf_std[0].CreateFont (...);
cf_std[1].CreateFont (...);
cf_std[2].CreateFont (...);
cf_std[3].CreateFont (...);
cp_solid.CreatePen (...);
}
catch (CResourceException e)
{
TCHAR sz_message [256];
e.GetErrorMessage (sz_message, 256);
TRACE (sz_message);
}
}CRepDrawFont::~CRepDrawFont()
{
//Added later and now the problem is gone
cf_std[0].DeleteObject();
cf_std[1].DeleteObject();
cf_std[2].DeleteObject();
cf_std[3].DeleteObject();
}maybe the problem was the array of cfonts.. which cause that the destructor of cfont was never beeing called (?) and so it leaked resources as hell.. and because i made CRepDrawFont a base class of every draw object the whole shista leaked as hell.. well.. thank you for your kind answers.. (i just wanted to know for sure, that my way of painting is not bad in general, cause 50% of my work are grounded on this) bernhard
Sometimes I think the surest sign for intelligent life elsewhere in the universe is that none of them ever tried to contact us.
-
Or use GDI+ which is an object oriented toolkit for GDI by MS.
Todd Smith
Todd Smith wrote: Or use GDI+ which is an object oriented toolkit for GDI by MS question: if i use mfc i get dc's to paint all over.. can i paint on a dc with gdi+ ? (if that would work it would really be a possibility cause i've read some docs and it sounds great) thanks in advance bernhard
Sometimes I think the surest sign for intelligent life elsewhere in the universe is that none of them ever tried to contact us.
-
I make function calls within the OnPaint() method who take a pointer to the DC and then use GDI objects created within their scope, but those functions don't make a call to SaveDC(). That's probably your problem. The path of execution looks like this: 1. Acquire DC 2. Save DC context 3. Call function 4. (in function) create resource 5. (in function) select resource into DC 6. (function returning) delete resource 7. Restore DC context Notice that you're still destroying the objects while they're still selected into the DC. The objects are probably what are leaking. Tim Lesher http://www.lesher.ws
I changed my code so that it saves the DC at the beginning and end of the OnPaint() method and the beginning and end of every function called inside OnPaint() that takes a pointer to the DC. I'm still seeing the same thing. Is there another kind of resource leak that could cause this, or does saving and restoring the DC not work quite right? Thanks for all of your help. This problem has become quite frustrating. Mark Lenz
-
I make function calls within the OnPaint() method who take a pointer to the DC and then use GDI objects created within their scope, but those functions don't make a call to SaveDC(). That's probably your problem. The path of execution looks like this: 1. Acquire DC 2. Save DC context 3. Call function 4. (in function) create resource 5. (in function) select resource into DC 6. (function returning) delete resource 7. Restore DC context Notice that you're still destroying the objects while they're still selected into the DC. The objects are probably what are leaking. Tim Lesher http://www.lesher.ws
Could it be that I do something like this: void ControlClass::OnPaint() { CPaintDC dc(this); int saveDC = dc.SaveDC(); Brush brushFill; brushFill.CreateSolidBrush(...); dc.SelectObject(brushFill); /*...Use brushFill...*/ brushFill.DeleteObject(); brushFill.CreateSolidBrush(...); dc.SelectObject(brushFill); /*...Use brushFill again...*/ dc.RestoreDC(saveDC); } -Mark Lenz
-
Could it be that I do something like this: void ControlClass::OnPaint() { CPaintDC dc(this); int saveDC = dc.SaveDC(); Brush brushFill; brushFill.CreateSolidBrush(...); dc.SelectObject(brushFill); /*...Use brushFill...*/ brushFill.DeleteObject(); brushFill.CreateSolidBrush(...); dc.SelectObject(brushFill); /*...Use brushFill again...*/ dc.RestoreDC(saveDC); } -Mark Lenz
Certainly! When you think you're deleting brushFill the first time, your're really not--it's still selected into the DC, so the delete will fail. Whenever you delete a GDI object, it MUST NOT be selected into a DC at the time. You're getting around the problem by doing a RestoreDC before the objects go out of scope, but the manual attempt at deletion is breaking the model. You need to select another brush into the DC before deleting the brush--either save the old brush when selecting the new one in, or select in GetStockObject(NULL_BRUSH) before deleting. You and Bernhard are actually seeing almost the same problem. It's leading me to the belief "RestoreDC Considered Harmful", because it's easy to assume that because you're saving and restoring the DC, that you don't have to think about what's selected into the DC at any given time. Hmm... maybe there's an article in that... That's a dangerous assumption, as you can see. Tim Lesher http://www.lesher.ws
-
Certainly! When you think you're deleting brushFill the first time, your're really not--it's still selected into the DC, so the delete will fail. Whenever you delete a GDI object, it MUST NOT be selected into a DC at the time. You're getting around the problem by doing a RestoreDC before the objects go out of scope, but the manual attempt at deletion is breaking the model. You need to select another brush into the DC before deleting the brush--either save the old brush when selecting the new one in, or select in GetStockObject(NULL_BRUSH) before deleting. You and Bernhard are actually seeing almost the same problem. It's leading me to the belief "RestoreDC Considered Harmful", because it's easy to assume that because you're saving and restoring the DC, that you don't have to think about what's selected into the DC at any given time. Hmm... maybe there's an article in that... That's a dangerous assumption, as you can see. Tim Lesher http://www.lesher.ws