Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I'd like to put a computer screen that is running an OpenGL programs in a room. It has to run all day long (not in the night).

I'd like to draw lines that are slowly fading in the background. The setting is simple: a uniform color background (say, black) and colored lines (say, white) that are slowly fading out.

With slowly I mean.. hours. Say that the first line I draw is with alpha 255 (fully visible), after one hours is 240. After 10 hours is 105.

One line could have 250 points and there will be like 300 line in one day.

For now I have done a prototype with very rudimentary method like:

glBegin( GL_LINE_STRIP );
iterator = point_list.begin();
for (++iterator, end = point_list.end(); iterator != end; ++iterator) {
    const Vec3D &v = *iterator;
    glVertex2f(v.x(), v.y());
}
glEnd();

More efficient method?

share|improve this question
    
Never ever use GL_LINES modes and similar. Their implementations vary among GPU's and may give you totally different results on two machines. Use GL_QUADS instead. –  Devdalus Jun 26 '13 at 12:18
1  
You should also profile the code in long runs checking for memory leaks. Those get to be a problem when you're planning on long runs :) –  Byte56 Jun 26 '13 at 13:28

1 Answer 1

up vote 4 down vote accepted

Efficiency when drawing a mere 300 lines is probably not something you need to worry too much about. Even the old OpenGL screensavers available with Windows 95 and which used Microsoft's software implementation were able to handle that kind of workload with ease, so I suggest that looking for a more efficient method of doing something that's already an incredibly lightweight task falls squarely into the realm of micro-optimization.

If glBegin/glEnd works fine for you in this use case, then by all means continue using it. Yes, be aware that it's not the best way of drawing stuff, but you're already going to have sub-millisecond frametimes, so why bother with a program like this? If you're already getting over 1000fps then being able to boost that to 2000fps really won't mean much at all. This isn't a performance-critical program, 10fps would be fine, 1fps would be fine. You've better things to be spending your time doing.

Remember - Quake used glBegin/glEnd back in 1996, had much heavier workloads than a mere 300 lines, and ran quite well despite that.

More important things here are that you don't accidentally fall back to software emulation, and that you don't chew through too much power while running this all day.

You can avoid software emulation by either drawing quads (if you need wide lines) or by strictly restricting yourself to width-1 lines (which are more likely to be hardware-accelerated).

For power-saving, this is one case where using Sleep in your main loop is appropriate (don't even think about using it to control framerate though; it's not for that, it's for power-saving). So by all means go stick a great big Sleep call in there; you're dropping alpha by 1/255 every four minutes so Sleeping for 15 or even 30 milliseconds between frames is perfectly alright here.

This is all in the spirit of fitting a solution to the problem, rather than trying to force the problem to meet a pre-concieved idea of what the solution should be, and the approach you've currently got is fine for the problem as you describe it.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.