I write a program to display some f(x) graph data. To make it flicker free I draw everything to some memory bitmap and bitblit it when necessary. When I draw with a solid 1-pixel wide pen, everything is fine, but when i set thicker width, the program starts consuming 100% cpu time and slows terribly, Why? What's the problem with thick pens?
Good question. Can you post a smallish buildable asm file that demonstrates this?
It has to do with not releasing and/or deleting the pen HDC appropriately - you have a memory leak. You can use a program called 'memproof' to track it down. For every pen you create, you must also destroy, in my layman terms.. maybe someone else can elaborate.
Hi,
In toolbar paint the brush width is selectable and there is no noticable difference between a thick and thin brush. The problem is somewhere else. The destruction of brushes is necessary but should not affect your performance, brushes are not kept in the 64K common GDI memory in 9x so logical brushes are essentially unlimited across all platforms, read that somewhere, don't know if it's absolutely true though. You should always destroy them though as they consume memory. You need to post a bit of code before anyone can help.
In toolbar paint the brush width is selectable and there is no noticable difference between a thick and thin brush. The problem is somewhere else. The destruction of brushes is necessary but should not affect your performance, brushes are not kept in the 64K common GDI memory in 9x so logical brushes are essentially unlimited across all platforms, read that somewhere, don't know if it's absolutely true though. You should always destroy them though as they consume memory. You need to post a bit of code before anyone can help.
I destroy everything properly.
All I do is change the lopnWidth member in the LOGPEN structure from 1 to 2 and rebuild my program. With width set to 1 everything works fine. If I set 2-pixel width everything slows significantly. The thiker width the more it slows. I think it's my win98 system, because i tested it on another pc with win2k and it worked fine.
All I do is change the lopnWidth member in the LOGPEN structure from 1 to 2 and rebuild my program. With width set to 1 everything works fine. If I set 2-pixel width everything slows significantly. The thiker width the more it slows. I think it's my win98 system, because i tested it on another pc with win2k and it worked fine.
Cold you attach a small sample program showing this problem?
Might also be relevant to know which video card you have, and the drivers - I'm not sure which GDI operations are usually accelerated and which aren't, but perhaps the slowness could be because the operations aren't accelerated on your system?
It's rather a shame that so many GDI operations are painfully slow :/
Might also be relevant to know which video card you have, and the drivers - I'm not sure which GDI operations are usually accelerated and which aren't, but perhaps the slowness could be because the operations aren't accelerated on your system?
It's rather a shame that so many GDI operations are painfully slow :/
I write it in C, and it's quite a big library by now. I draw graph on device dependent bitmaps and bitblit it when nessecary. I think that drawing on offscreen bitmaps doesn't get any videodrivers involved. I might be wrong though. Looks like it was a bad idea to use gdi for that stuff. I should have used direct draw or openGL instead. Just wanted to make neat and simple and it proved to be slower than i expected.
Yes, unfortunately some GDI stuff is pretty slow - it sounds weird it's so slow for you, though. The best option is normally to draw stuff manually (using DIB's), the BitBlt itself should be fast enough.
Draw manually?
Does it mean I have to write my own functions to manage pens and draw lines instead of using windows GDI interface, or is DIB faster than DDB?
Does it mean I have to write my own functions to manage pens and draw lines instead of using windows GDI interface, or is DIB faster than DDB?