Inputs for the road-map

Forums: 

Although we discussed the below items with Sergey (san), let me repeat them here as reminders:

1. Optimizing memory footprint/performance for displaying assemblies by *reusing* visual representations of instances (not recomputing them). Example: 100,000 instances of the same cylinder should rather be displayed as 100,000 located instances of 1 visual rep (of ~100 triangles), not 100,000x100 triangles (current approach).

2. Fix memory leaks when working with multiple OpenGL contexts. Currently in MDI (multiple document interface) scenarios OpenGL resources effectively leak upon closing each document.

thanks,
Roman

Kirill Gavrilov's picture

Thanks for a reminder,

but I want to notice that instancing is delicate question in graphics.
Although it looks reasonable to reuse the same geometry data for identical objects - this situation is quite rare in real applications. Also it is difficult to implement common approach for arbitrary data.

When there are a lot of small similar objects, hardware instancing might dramatically improve performance by reducing CPU calls. However such techniques require straight knowledge of rendered geometry as well as grouping restrictions. The more objects share the same attributes (color, line width, materials, orientation, etc.) the more performance improvement could be achieved. This especially applicable for simple 2D objects but not so good for 3D objects.

Roman Lygin's picture

http://tracker.dev.opencascade.org/view.php?id=23854
Kirill,
We might likely be talking about different things here. You are probably focused on low-level (near OpenGL calls) reusage, while my concern is mainly reuse of already performed (pre-)processing (creation of triangulation, of Graphic3d_Group, etc).
My point is that when displaying large assemblies the code should try to reuse as much information as possible. If cloning has to happen somewhere close to hardware, let it be. It is important to ensure that higher-level data (which is most expensive in terms of time, and perhaps memory footprint) should be reused.
The above tracker (23854) is one that Sergey has created based on our discussion.
Thanks,
Roman

Sergey Anikin's picture

Dear Roman,

1. This task is in the queue, waiting for someone to take care of more detailed analysis. In fact, the optimization you mention here should be applied with care, because simply detecting unique instances in a large assembly might impact performance in some cases. For the sake of clarity, let me note that we are speaking here about optimization somewhere at the level of AIS_Shape class or tools from StdPrs package.

2. Concerning OpenGL resources management, please refer to OCCT visualization tools project, there is already corresponding item in the "Agenda" section.

Best regards,
Sergey