How to speed up drawing

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
Report Content as Inappropriate

How to speed up drawing

Vivian Crompton
Hi Louis,
I was having a little browse through your drawing routines and was wondering why you aren't using display lists?
Here;s a tutorial if you are unfamiliar with them.

you would get a huge performance gain from using them, which from what I saw in another post somewhere, you were having issues with.

Another thing you might want to consider doing is drawing your notes and other music notation (and letters too) using glyphs from a texture. You basically set up one texture containing all the glyphs for your notation symbols and letters, and set up a structure that maps the the rectangular bounds of each glyph in the texture, so when you want to draw a note, your glyph drawing routine just draws that bit of the texture to the target location on screen. Because the glyph is in video ram, this all happens very very fast. If your glyphs are all white on black, you can control their color with the material color settings in opengl. If you make the glyphs big enough, with anti aliasing settings you will get a very smooth result on the edges. Additionally, because the notation is all from a drawing, it's easy to set up different versions (music fonts if you like) just by replacing the source image.

if you want to chat i'm on skype as crompviv.
Reply | Threaded
Open this post in threaded view
Report Content as Inappropriate

Re: How to speed up drawing

Louis B.
Hi Vivian,
Thanks for your post and yes it would be great to chat to you. What time zone are you on? I am in London.

First I think you missed the fact that I am using display lists. Grep for glNewList and for glCallList in the code. Basically the call lists are chained together so the single call to glCallList in scroll.cpp 174 draws all the moving notes. Basically I have managed to off load as much drawing to the GPU as I can with just three calls to glCallList which are then chained to other callists.

There are some technical difficulties with PB that I did note realise at first. These are:

(1) To read the notes on screen needs a gl frame rate of 60Hz. Otherwise the note movement appears to be jerky.  This is not so apparent in a computer game where blurring/jerking at the edges of the computer screen which scroll horizontally is not so noticeable.

(2) Scrolling horizontally the screen tearing is a problem that does not show it self with vertical scrolling games like guitar hero. To fix the tearing the gl frame rate need to synced to the screen refresh rate (usually 60Hz)

 (3) the software syth eg fluidsynth eats up CPU. especially with low latency.

Maybe I am concentrating too much on my Ubuntu netbook and PB has been optimised too much for my Linux underpowered netbook, but it works very well even when running fluidsynth. PB does not run very well on XP.

I have also tried an optimisation that works very well on linux but not on windows.  the optimisation is not to redraw the whole screen on every refresh.

I tried the some examples from lighthouse3d.com  but still could not get them to work well on my eeepc netbook. I tried changing the examples to simulate the PB horizontal scrolling but they did not work well on my netbook. Also I could not get bitmaps with transparency (required for the smooth edges of the notes) to work at a satisfactory speed. In fact I could get bitmaps with transparency to work at all.

Do glyphs have transparency? Again I think i tried these but I could not get them to work when the rectangles overlap. There is not proper transparency in GL (at least not in the free red book which is now out of date).

If we/you could find an example that could scroll 30 bitmap items with transparency at low CPU usage then that would be great.