Re: [PyOpenGL-Users] Pyopengl - slow performance using

[Christopher B. <Chr...@no...>]

On 1/17/11 8:50 PM, Mike C. Fletcher wrote:
> The most effective speedup I can think of would be to pre-render the
> static geometry into (mostly transparent) image-maps and then using a
> single textured quad to present it.  Modern cards handle large image
> maps pretty well, and a single textured quad should render pretty fast.

Wow, I"m surprised -- it seems OpenGL should be well suited to this kind 
of thing (that is, simple vector drawing). But I suppose what you're 
talking about is basically double buffering, which is an age-old technique.

However, if you've going to go that route, you might want to pre-render 
much prettier rasters with Mapnik or MapServer, and then use those.

> If you're letting users do a lot of zooming you'll want your zoom-UI to
> be regenerating the texture according to some heuristic regarding how
> different the current zoom is from that used to generate the texture.
> On "release" of the zoom widget you'd regenerate again for the final zoom.

hmmm... that does let you get the zooming and double buffering, both. 
I"ll need to consider this for some of our stuff, though vector rending 
as been working well for us so far.

> Even with 350,000 vertices, using VBOs for the indices and the vertices
> should produce an almost-C-speed render.  That is, define a vertex
> array, an index array that says which vertices to render, and then use a
> single call to render the whole set.  If your card can pull that much
> geometry, I'm guessing that should be faster than 50,000 calls to render.

much, I think -- this approach is working well for us.

-Chris



-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...