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

[Mike C. F. <mcf...@vr...>]

On 11-01-18 03:31 PM, Christopher Barker wrote:
> 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.
OpenGL is reasonably well suited to this kind of thing, but modern 
graphics cards focus more on textured throughput than pushing huge 
numbers of vertices.  On my GeForce 7600 I get ~90fps for the kind of 
data-set we are talking about (from VBOs with a single call to 
glMultiDrawArrays).  With regular (numpy) arrays that tops out at 
~40fps.  With the Mesa software renderer, 2fps.  Workstation drivers 
will tend to be better at optimizing this kind of thing, but it's still 
a heck of a lot of geometry to push through the pipeline.  A single 
textured quad only generates 6 vertices (though, of course, it generates 
a fragment per pixel)...
>> 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.
Honestly I don't do this kind of stuff myself as my playing tends to be 
focused on "wandering around in 3D", where caching generally works 
better at the pre-computed geometry level.
>> 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.
Which reminds me, we have a long-standing wart that glMultiDrawElements 
is implemented in Python at the moment... really should revisit that 
issue (pointer type auto-wrapping didn't work very well there).

Have fun,
Mike

-- 
________________________________________________
   Mike C. Fletcher
   Designer, VR Plumber, Coder
   http://www.vrplumber.com
   http://blog.vrplumber.com