|
> I don't want to do "create and delete" system, because it
> would be slow and inefficient.
Before you call something 'slow and inefficient', try to *measure* its performance. On my old 333MHz box it takes less than 120 msec to perform this:
for (int j = 0; j < 10000; j ++)
{
HPEN hp = CreatePen(PS_SOLID, 1, RGB(j % 255, j % 255, j % 255));
SelectObject(hdc, hp);
MoveToEx(hdc, j, 0, NULL);
LineTo(hdc, j, 1);
SelectObject(hdc, GetStockObject(NULL_PEN));
DeleteObject(hp);
}
It's roughly 83300 pens per second. Are you sure that pens are *real* bottleneck in your program?
Tomasz Sowinski -- http://www.shooltz.com.pl
|
|
|
|
|
Doesn't every single CreatePen, DeleteObject pair fragment memory?
I suppose it does.
BTW 120 ms is pretty long time  .
|
|
|
|
|
> Doesn't every single CreatePen, DeleteObject pair fragment
> memory?
I doubt there's any significant performance hit. Many programs create and destroy pens/brushes during each WM_PAINT processing. GDI must deal with this.
> BTW 120 ms is pretty long time
For 10000 cycles? I don't think so. How much time does it take to compute data points you're going to visualize?
Tomasz Sowinski -- http://www.shooltz.com.pl
|
|
|
|
|
I'm not very certain about this, but I believe there's no memory fragmentation,
because Windows allows a fixed number of GDI resources (am I right  ), so there must be an efficient way of handling them. I don't think the system allocates and frees memory every time you create a pen.
Any comments?
|
|
|
|
|
Wow - this is quite a lengthy conversation you two have had. My 2 cents worth, which is just over 1 cent, US.
1/ You *can* use DrawSolidRect and pass in a colour to draw a line without creating a pen, but the API will just create one internally.
2/ There is *no* way that 'thousands' of different line colours will be visible to the naked eye unless they form a gradient and the interaction between them is the point. The only other reason to do this would be colour keying
3/ MFC is a thin wrapper for the API - look at the code and it more often than not calls an API function directly. CPen is just a wrapper that helps prevent memory leaks.
4/ Windows does have finite GDI space, and you will find that unless you are careful handling all these pens and deleting them properly you will find your system will go down. I strongly recommend running the resource meter while you work on this code. This is also why I would not recommend pre-creating your pens in memory.
5/ The other option if you feel so strongly about it is to grab a DIBSection wrapper to help you get access to the bits and set the pixel data yourself. No CPens or HANDLEs needed, just an implimentation of the Bresenham algorithm, which is pretty simple stuff.
Christian
#include "std_disclaimer.h"
People who love sausage and respect the law should never watch either one being made.
The things that come to those who wait are usually the things left by those who got there first.
|
|
|
|
|
You could try using GDI+, its in beta 2 and not too long before is public release.
It requires only 1 DLL to be deployed with your application.
It is supported on all operating systems apart from Win95.
You'll coverage in Februarys 2001 Platform SDK.
I've started implementing GDI+ in my commercial applications which are due out in last quarter 2001, thats how much faith I have in GDI+.
Hope this helps
Norm
|
|
|
|
|
Is it "must pay"?
Where it can be obtained and how it can be used in my application?
Thanks.
-Mato
|
|
|
|
|
Nope, you can redistribute free of charge.
heres a snippet of GDI+
Pen blackPen(Color(255, 0, 0, 0), 5);
graphics.DrawRectangle(&blackPen, 10, 10, 100, 50);
See Christian Graus's article on GDI+, they should tell you everything need to know to get started.
|
|
|
|
|
Why not create all pens you will use in advance and save them in an array ? Then all you have to do is select the one you want to draw with and use it. This will be much faster than continual create/select/draw/deletes.
The absolute fastest way to go is to use PolyLine but that is limited to connected lines of one color. If each function's line was limited to one color this would work very well. I once wrote a spirograph program with hundreds of lines and PolyLine was so fast I could not even see them drawn.
|
|
|
|
|
Thousands of pens would be hard to track individual colors of ( unless you did them in a 3 dimensional array or used the RGB marco to generate indices ), and would also be an unreasonable hit on GDI resources IMHO.
Christian
#include "std_disclaimer.h"
People who love sausage and respect the law should never watch either one being made.
The things that come to those who wait are usually the things left by those who got there first.
|
|
|
|
|
Thousands would be but I seriously doubt he deals with thousands of pens.
|
|
|
|
|
I have to draw number (thousands) of lines and every line must be drawn in different color
I don't get it, but that's what he said.
Christian
#include "std_disclaimer.h"
People who love sausage and respect the law should never watch either one being made.
The things that come to those who wait are usually the things left by those who got there first.
|
|
|
|
|
No doubt!
Color is (or may be) function of x. It is only for effect.
|
|
|
|
|
Mato-
Pls post the code that you think is inefficient..
Some tips'
1. Dont use CPen, use a HPEN directly using CreatePen
2. Cache all the HPENs you need in an internal data structure.
3. If you Must use a CPen object, create it as a member variable and then
Attach and Detach a HPEN from the cache.
4. Dont worry there is very minimum overhead for CreatePen. I have seen folks work with many thousands of pens, brushes, with very little visual performance impact.
Finally as Christian pointed out, use a Bitmap if you want to take matters into your own hands...
Again, lets see some code that you thnk is slow..
vivek
|
|
|
|
|
I think there is no need to post the code. I will use the "create delete" approach with direct API calls. At last you convinced me. Thanks for the ideas and effort.
-Mato
|
|
|
|
|
Hi,
I have a SDI application, and i like to change it to MDI.
1- is it possible?
2- what is the easiest way?
3- will my program work in MDI the same way as it works in SDI?
Thanks
Ehsan 
Ehsan Behboudi
|
|
|
|
|
Does any one know how to program in VC++ " For sending and receiving a Message as Short Message Service(SMS)through local PC connected with Mobile Phone to another remote PC connected with Mobile Phone" using SMS Gateway?
Please refer http://www.winsms.com for SMS Gateway.
a sample code would be great!
Thanks!
Best Regards
Nagajothi
|
|
|
|
|
How do you make to convert html files to rtf format?
Thanks
|
|
|
|
|
When working through the DAOEnroll tutorial I came across something odd: The text says I should add a combo box and add a member variable to it using ClassWizard. I'm supposed to accept the default value (which should be m_pSet->m_CourseID but is only m_) but this is not correct and I'm not allowed to enter the correct value either. After some experimenting i found that everything works fine if I change the type of the combo box from the suggested "drop list" to something else (i.e "Simple" or "Dropdown"). Is there a bug or is it just me?
ps. The default value ClassWizard generates is based on the tab order of the controls, I'm not doing anything wrong there I'm sure.
Is DAO alive and kicking btw.? ADO seems to be the way to go but our app will only need very simple database support so I reckon DAO (with MFC support) will do the job.
/Erik
|
|
|
|
|
Now, I can display different language string using TextOutW() function, such as Portuguese and Traditional Chinese. However, when I print them, such characters there are just blank???
I don't know why? Help me, please!
Thank you for your kindness first.
Any comment is welcome!
|
|
|
|
|
You also need to select a font into the DC that supports the character sets used by the foreign languages.
--Mike--
http://home.inreach.com/mdunn/
#include "buffy_sig"
|
|
|
|
|
I am writing a c++ .exe MFC program, using a library written in C code.
from the C code, I want a message box to pop up when an error has been detected. I tried using MessageBox function but it says too few actual parameters. The function prototype the MessageBox function is:
int MessageBox(
HWND hWnd, // handle to owner window
LPCTSTR lpText, // text in message box
LPCTSTR lpCaption, // message box title
UINT uType // message box style
);
does the problem lies with the hWnd handle? how can i get the handle to the window from the library in C code?
Pls help.
hearties
|
|
|
|
|
You could pass NULL to the hWnd parameter or use ::GetActiveWindow to attach the box to the current active window
Michael 
|
|
|
|
|
Let's say I have a dialog-based program. The main dialog is CMainDlg.
CMainDlg has as members of the class 2 sub-dialogs: CSubDlg1 and CSubDlg2 (or pointers to them).
I would like easy access from within the sub-dialogs to some other members
of the CMainDlg. How do I most easily accomplish this?
It seems that it would be easiest to have a pointer to the CMainDlg as a member
of each sub-dialog class -- but the necessary #include statements seem to
cause a conflict (understandably).
Alternately, it would be nice for each sub-dialog to have easy access to the other
sub-dialog members. So, again, it would be nice for each sub-dialog to have a pointer
to the other sub-dialog as a member of its class. But again the necessary #include
statements fog it up.
Suggestions?
Why?, you ask? One example of why is in using a TabControl. I would like some changes
in information on one page reflected on other pages, so the pages need an easy way
to communicate with each other or with the parent dialog so that it can serve as
a liaison (so to say).
Thanks. David.
|
|
|
|
|
No need to ask why - it's an obvious need
The answer is to create the pointer when you need it, OR to put the #include for the pointer in your .cpp file and in the .h file declare a dummy class. At least that has worked for me, but in this specific case I would just grab it as I need it
CMainDlg * pMain = (CMainDlg*) GetParent(); ( or AfxGetMainWnd())
and away we go. The pointer is fresh out of the box, and the #include is in the cpp file. The only thing is to pass this as the parent when creating the dialog.
Christian
#include "std_disclaimer.h"
People who love sausage and respect the law should never watch either one being made.
The things that come to those who wait are usually the things left by those who got there first.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
