Jump to content
  • Advertisement
Sign in to follow this  
fathom88

OpenGL Question Speeding Up 2D Graphics

This topic is 4850 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm trying to speed up my 2D Windows App. I've tried display list and making my own functions to replace the included quadric functions. Is there anything that OpenGL turns on by default which I should turn off explicitly to improve performance. I'm just drawing data points; beauty is not a factor. I've toyed with the idea of using only 256 colors in my app (via color indexing/altering the PIXELFORMATDESCRIPTOR for 8 bit color). Would this improve performace on a machine which has a high end video card? I always thought this was only done to allow apps to run on low end video cards because they don't support true color. I can't think of anything obvious to improve performance. I've enabled double buffering and placed as many calls inside begin/end as possible. I've limited my state changes. Thanks.

Share this post


Link to post
Share on other sites
Advertisement
What's your current FPS? How many polygons are you drawing? Are you using textures? What do you mean by, 'just drawing data points'? It's a little hard to make suggestions unless you provide some more information.

Share this post


Link to post
Share on other sites
I draw my data as slices on a circle (basically a pie chart). Each slice has a color to represent a value in my data. The data value never exceeds 256; so 8 bit color pixel is more than enough. The problem is I have to literally draw thousands of pie slices. Hence, I make a few thousand calls to gluPartialDisk per frame. It takes 3 sec to draw one frame. I've tried creating a function to draw the pie slice myself, but the overhead of the trig math involved slows things down even more. I can't use a look up table for the math because the slices are of different sizes depending on the data (it would work if I were drawing a clock with defined constant segments). I don't need any special lighting or shader effects. I'm already using the lowest parameters possible for the gluPartialDisk call (higher values produce a finer picture; I have so many slices, the poor quality of the slices does not show). I haven't found a call to replace gluPartialDisk.

Share this post


Link to post
Share on other sites
I was going to suggest you sort things by texture to minimise texture binding, but it doesn't sound like you're using texturing. Equally I doubt 256 colour mode will be any faster (on any semi recent card this tends to slow things down I've found).

If you're calling thousands of gluPartialDisk you're probably either vertex limited or (more likely) the actual function overhead is the cause of the slowness.

gluPartialDisk is usually just done with immediate mode rendering (glBegin/End etc.) which is pretty damn slow. Easiest would be to just cache the whole lot in a display list, assuming your data doesn't change too often. If the data is changing more frequently then I'd suggest changing your drawing to work with vertex arrays.

It'd depend on your data, but a set of vertex array data for each pie chart could be suitable. When the data changes you'd recalculate all the vertices and fill the vertex array. Rendering overhead is then vastly improved (even with doing all the trig yourself, it's got to be done somewhere).

Share this post


Link to post
Share on other sites
Thanks for the suggestion. However, my data is constantly changing. I think I'll lose the benefits of a display list when the data changes and I have to create a new list.

Share this post


Link to post
Share on other sites
How can you draw thousands of pie slices and make sense of any of it? You would have slices that are only as wide as a pixel, if not less. The reasoning behind what you're trying to do is still a bit unclear.

Have you looked into making the pie chart out of a GL_TRIANGLE_FAN? It only requires 1 vertex per triangle past the first triangle, and if you truly have thousands of slices, making the edges of your slices flat will not be noticeable.

Share this post


Link to post
Share on other sites
Quote:
Original post by Mantear
Have you looked into making the pie chart out of a GL_TRIANGLE_FAN? It only requires 1 vertex per triangle past the first triangle, and if you truly have thousands of slices, making the edges of your slices flat will not be noticeable.

gluPartialDisk already does that (or at least, this implementation I'm looking at does). However it does it with immediate mode, so it's far from optimal. Using vertex arrays (possibly with triangle fans) would be a better solution.

Share this post


Link to post
Share on other sites
Thanks for the suggestion. I'll look into the vertex array with triangle fan. I tried the display list. Even if my data wasn't constantly changing, the display list is so large that Windows starts "thrashing" the memory. Any advantage from the point of OpenGL is lost through the OS trying to handle the large memory chunk.

Share this post


Link to post
Share on other sites
I tried the vector array with triangle fan. It is faster but still too slow. I'm getting 2 frames a secomd now. And, I have not implemented the color array yet. Is there any way to draw a picture without using primitives. How about creating a grid (maybe mesh would be a better word) in the shape of a circle and turning the diferent squares into specified colors. Hence, getting the pie chart form. Yes, I realize this is basically what the draw primitives are doing on a pixel level. Thanks again for any help.

Share this post


Link to post
Share on other sites
Could you post some code? It sounds like there may be costly state changes being done. Drawing a few thousand lines should not make you crawl down to 2 FPS.

Also, what kind of PC are you using? Maybe it's reverting to software rendering for some reason.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!