PolyLine and autoscrolling canvas
in [MFC]
|
From: Luigino on 26 Jan 2010 11:04 Hello everyone!!!! I'm creating a task manager's-like-scroll-graphic. So for this I was thinking to create a vector of vectors of values, where the main vector is to draw more sources, and inside each "internal" vector there are a set of values. The size of each vector containing values would be the same as rect.right converted in points using ((float)rc.right / (float)dwDPI) * 72) where dwDPI was read from the registry to get the current DPI screen. BUT, since I thought to have a wide size of array due for resizing/ enlarging window, since I was thinking to use PolyPolyLine, how I can make it drawing so the last element of the array would be drawn at rc.right of the drawing region?... Or maybe there's a better way to draw it avoiding also flickering?.... Thanks to everyone in advance Ciao, Luigi
From: Stephen Myers on 26 Jan 2010 12:29 Luigino wrote: > Hello everyone!!!! > > I'm creating a task manager's-like-scroll-graphic. > So for this I was thinking to create a vector of vectors of values, > where the main vector is to draw more sources, and inside each > "internal" vector there are a set of values. The size of each vector > containing values would be the same as rect.right converted in points > using ((float)rc.right / (float)dwDPI) * 72) where dwDPI was read from > the registry to get the current DPI screen. > BUT, since I thought to have a wide size of array due for resizing/ > enlarging window, since I was thinking to use PolyPolyLine, how I can > make it drawing so the last element of the array would be drawn at > rc.right of the drawing region?... Or maybe there's a better way to > draw it avoiding also flickering?.... > > Thanks to everyone in advance > Ciao, > Luigi The trick to avoiding flickering is to double buffer. Draw into an offscreen DC and then bitblt to the actual device. This means that stationary features don't change and the polyline drawing seems to move over the top of it. I would capture the information without any particular regard to the screen size and let PolyLine() deal with it. You can manipulate the viewport to show the part of the vector that you're interested in. I would use a std::deque which would allow you to remove data that you can no longer display. You will have to do some research to determine the available size for you X axis. I believe the limit is on the order of 28 bits, but don't quote me. Steve
From: Luigino on 27 Jan 2010 05:35 Hello Stephen, first, thank you for your reply... What I'm making is a CWnd class component that will be integrated in another application which will pass some data. I'm thinking about a DLL component because in this component I will have to draw lines with sliding screen in a tab of the application, and some vertical rectangle bars in another tab of same application. I was in doubt about the calculation of drawing position basing on DPI because if I move the application in another PC which could have different screen resolution or different monitor... I was thinking first to put values in a vector, sized as the whole screen width so if I want to maximize the application those values that are "hided" in the left would appear, and at the same time to calculate the Y axis in a vector of POINT (a precisation, both vectors, values and POINT, could be also vector of vector if I have more than one source) starting from the end of the vector (I guess) so PolyPolyLine will draw the vector from the right side of the client... Would that be a good idea?... If yes, since values are simply double values, to represent them on the screen, is there something like a formula which would put convert a certain value in POINT Y considering an interval from 0 to clientrect.bottom? And considering this way I'm doing, do you think is good using vector or would be better using std::deque as you suggested for performance (I see in the help it has resize() so I could set n-elements as ParentWndRect.right )?... Thanks again in advance for the little help Ciao Luigi
From: Stephen Myers on 27 Jan 2010 10:38 Luigino wrote: > Hello Stephen, > > first, thank you for your reply... > What I'm making is a CWnd class component that will be integrated in > another application which will pass some data. I'm thinking about a > DLL component because in this component I will have to draw lines with > sliding screen in a tab of the application, and some vertical > rectangle bars in another tab of same application. > I was in doubt about the calculation of drawing position basing on DPI > because if I move the application in another PC which could have > different screen resolution or different monitor... > > I was thinking first to put values in a vector, sized as the whole > screen width so if I want to maximize the application those values > that are "hided" in the left would appear, and at the same time to > calculate the Y axis in a vector of POINT (a precisation, both > vectors, values and POINT, could be also vector of vector if I have > more than one source) starting from the end of the vector (I guess) so > PolyPolyLine will draw the vector from the right side of the client... > > Would that be a good idea?... If yes, since values are simply double > values, to represent them on the screen, is there something like a > formula which would put convert a certain value in POINT Y considering > an interval from 0 to clientrect.bottom? > And considering this way I'm doing, do you think is good using vector > or would be better using std::deque as you suggested for performance > (I see in the help it has resize() so I could set n-elements as > ParentWndRect.right )?... > > Thanks again in advance for the little help > Ciao > Luigi Luigi, I would try to separate the data collection and storage from the display of the data. Sort of like the MFC document/view. Collect each data point and store it in a vector (or deque) as a CPoint(). The x value being time and y your measurement. I'd then let the CDC drawing methods do the manipulations required to get from your data point to the window's canvas. Look at CDC::SetMapMode(MM_ANISOTROPIC). Your X and Y coordinates will need to be integer, and can be scaled as the data is collected. This means that resizing the window requires you to reinitialize the memory DC and then you plot the captured data. Let CDC do all the hard stuff. The selection of deque or vector depends on how many data points you need to keep around and under what circumstances they become obsolete. Trying to plot exactly as many points as are needed is probably more trouble than it's worth. It might make sense to limit the size of the vector/deque to 2000 points (or some other fairly arbitrary value such as screen width), but that's as much as I would do. Steve
From: Luigino on 29 Jan 2010 04:36
Hello Steve, > I would try to separate the data collection and storage from the display > of the data. Sort of like the MFC document/view. Collect each data > point and store it in a vector (or deque) as a CPoint(). The x value > being time and y your measurement. I'd then let the CDC drawing methods > do the manipulations required to get from your data point to the > window's canvas. I'm trying to let CDC doing the hard stuff as you suggested.... just only a thing I would ask: Is there a way to assign the POINT.x the current time as LONG since time functions are most string functions and time_t is the time elapsed since 1970?... Thanks Ciao Luigi |