Question

If you begin to render points, render a ton of vertices, and then end, you get noticeably better performance than if you begin points, render a vertex, end, and repeat a ton of times (e.g., redraws during pan and zoom actions for, say, 200,000 points are MUCH smoother).

I guess this might make sense, but it’s disappointing. Is there a way to get back the performance while still rendering each point in its own begin-end block?

BACKGROUND:

I wanted to design a control that could contain a ton (upwards of a million in an extreme case) of “objects” that each do its own rendering. Many of these objects will represent themselves as points.

If I let a hundred-thousand points individually render themselves in their own begin-end blocks, I get a major performance hit (as opposed to rendering them all in a single begin-end block). It thus seems I might have to make the container aware of the way the objects render themselves (for example, beginning points, telling everything that needs to render a point to do so, and then ending).

This messes up the independent nature of the display-object relationship I wanted. It also messes up hit testing by selection because I don’t think you can add a name to a vertex inside a begin-end block of points, right?

FYI (in case this helps) my project will be displaying a 2D scene (using an ortho projection) and requires hit testing to determine which related object a user might click. In general, the objects will represent “tracks” containing individual points connected with lines. The position data is generally static, but point and track colors and display representations may change due to user settings and selection information. One exception–a “playback” mode may allow the user to see only one track point at a time (the “current” point in the playback) and step through time from one point to the next. However, even in that case I assumed I would simply change which point on each track is actually displayed (at its “static” location) depending on the current time in the playback. If any of that brings to mind further suggestions for an OpenGL newbie, then much thanks!

Answer 1

To solve this issue, I started by using VBOs (which did speed things up). I then allowed my “track” objects to each draw their own set of points as well as the lines connecting the points (each track using two DrawArrays: one for the line strip and one for the points). Each point does not have to draw itself independent of the other points–this was the major performance improvement.

BUT, I still needed hit-testing against the points, so..

Finally, I needed allowed each displayed object (in this case, the tracks) to do its own selection routine so each object can do what it needs for efficient selection. For tracks, they took a two-step process. First, a track names its entire line strip with one name (0) and performs the select. IF that results in a hit, then the track does a second render pass, naming each individual point and line segment to hit-test against each part of the track. This makes hit-testing against each point quite fast.

As an aside, I’m using .Net (C#) for my programming. With it, I created a class (SelectEventArgs) derived from EventArgs to describe selection criteria to objects being displayed. My SelectEventArgs class includes a list meant to be filled with selected objects. The display class then has an EventHandler<SelectEventArgs> event. When an object is added to a display, it subscribes to that event. When the event fires, each object determines whether it’s been selected and fills the list of selected objects (in the SelectEventArgs passed in the event) with its information. After the event fires, I can access the list of objects returned in the SelectEventArgs instance to handle the user interaction. I find this to be a nice pattern for creating flexible display objects and selection tools.