Thread: Best way to render a graph?

I would think both ways would work the same. The real difference is how you plan to draw the lines.

If you are just calculating some points and connecting them with straight lines you won't see a lot of differences. If you are trying to calculate curves to connect the points thats hard to say. Windows has a decent set of drawing functions for arcs, I'm not sure what GL has but I would image its just as good.

One thing to consider is the controls. GL does not provide a nice method for taking in user input. You would have to create text boxes, buttons and the like to accept the functions to graph. In Windows you can rely on the window classes in place that do that.

Originally Posted by jverkoey

The GL version would merely render the frame once every time it needed to be updated and theoretically it would be easiest to implement as far as rendering goes.

Thats not necessarily true. If the GL app is full screen taht would work, but if its a windowed GL app you would need to redraw it in the same places as with a windows app.

Even with a GL app, if another window was placed on top of it or dragged across it you would have to redraw the graph. Granted with GL it would be possible to keep an offscreen buffer with the graph that cn be copied into place for a redraw.

Also consider redraws required if the X and Y axis scale is changed. If the user zooms in or something like that.

If you use standard windows controls you can't go full screen, at least not easily. Its been a while since I read about this so I may be off. As I recall, you end up creating two drawing surfaces (if not more) one that is being displayed and a second that you actually draw onto. Now, using GL drawing commands you can draw to the offscreen buffer easily enough, but the standard windows controls are not smart enough to do that and try to draw direct to the screen. So if at any time you try to switch buffers the windows controls won't be rendered and will appear to vanish to the user. Thats where my comment of needed to make your own controls came from.

Were I doing the project, I would use the standard windows stuff, no GL. Calculate whatever points you need to render the graph and store those in a dynamic array. Anytime a redraw is needed use those calculated points to draw the graph by playing connect the dots with straight lines. Thats assuming you are dealing with 2D graphs, if you are doing 3D graphs I would reconsider using GL.

try a search here. there have been some other questions asked that may help.

>>Its been a while since I read about this so I may be off.

Yep, sorry, but totally wrong.

>>If you use standard windows controls you can't go full screen,

not true. You create the controls on the main window. You can create controls inside controls ie combobox in listview.

>>So if at any time you try to switch buffers the windows controls won't be rendered and will appear to vanish to the user.

not true. Windows will draw the controls even if you draw over them.

>>you end up creating two drawing surfaces (if not more) one that is being displayed and a second that you actually draw onto.

double buffering. search here for plenty of info and code.

>>if another window was placed on top of it or dragged across it you would have to redraw the graph.

it generates a paint msg that you have to handle.

>>Also consider redraws required if the X and Y axis scale is changed.

StretchBlt() changes image sizes [back buffer to front buffer then call for a paint]

>>draw the graph by playing connect the dots with straight lines.

PolyLine(), a GDI function, does this

>>Calculate whatever points you need to render the graph

by calc the ratio between the range in your data and the client area you will draw to (minus labels, axis ect)

I then convert to int array and call PolyLine(). This approx works well, in most cases.

>>Anytime a redraw is needed use those calculated points to draw the graph

Too slow. Better to draw the graph once and just copy (BitBlt() ) the graph as required (by paint msgs).