Decreasing display time for a large amount of surfaces

I didn't know PythonOCC wraps OCCT 3D Viewer - interesting to know.

Why are using BRepBuilderAPI_MakePolygon? This tool generates a valid B-Rep structure, which is, however, extremely inefficient from memory/performance point of view.
If you create this TopoDS_Shape only for displaying on the screen, it would be much better creating a single Poly_Triangulation from many polygons and displaying TopoDS_Face from this triangulation (see BRep_Builder::MakeFace() taking triangulation on input).

Do you have an idea why displaying a Poly_Triangulation Mesh is so much faster than displaying exactly the same thing but in BRep?

I don't quite understand the question. Graphic cards render only triangles, not B-Rep, so that displaying B-Rep would first require meshing. As soon as meshing is already done, displaying TopoDS_Shape via AIS_Shape should be as fast as displaying just triangulation (with Prs3d_Drawer::IsAutoTriangulation() disabled to avoid implicit remeshing of the same shape twice). This is not something specific to OCCT - any library working with B-Rep and B-Spline surfaces should perform meshing to display geometry on the screen.

It is important to understand, that parameters of BRepMesh_IncrementalMesh algorithm control not only a casual look of a shape on a screen in terms of "nice"/"rough". Their real purpose is to define a mesh following original surface close enough to be used in other algorithms with a trusted precision - visualization is only one of use cases. That's why linear and angular deflection parameters are main inputs of meshing algorithm - in this context an overtessellated geometry is better than undertessellated.

What make BRepMesh_IncrementalMesh slower?

• Single-threaded execution.
  BRepMesh_IncrementalMesh supports multi-threaded execution, but it should be enabled explicitly. Parallelization is done on Faces level, so that to benefit meshing algorithm should be called on as much shapes as possible - e.g. by putting everything into a temporary TopoDS_Compound and passing it to meshing algorithm.
• Overtessellation parameters.
  Passing too small deflection parameters will produce an overtessellated result taking a lot of time. It is desirable putting values actually meaningful for specific domain (e.g. based on application knowledge that shape is for a large vessel, a robot, or a microcontroller - each having very different precision criteria). It is important to understand the difference between a real (absolute) and relative (relative to bounding box) deflection parameter definition and use them appropriately.
• Overcomplicated geometry/topology definition.
  Exactly the same geometry may be defined in numerous ways in B-Rep. Spherical surface may be defined by B-Spline, and B-Spline might be defined by redundant number of knots; continuous surface might be defined via single TopoDS_Face or may be split into large number of connected small Faces.
• Broken or bad geometry.
  Invalid geometry may cause unexpected slowdown of the algorithm on trying to cope with unsolvable geometry issues.

If you are curious what might make  BRepMesh_IncrementalMesh faster or what could be an alternative, then it is better starting from understanding main meshing stages:

• Tessellation of geometry boundaries (TopoDS_Edge).
  • This step is more involving (linear/angular deflection parameters are also involved), but relativelly fast on normal geometry.
• Initial tessellation of TopoDS_Face in UV parametric space as 2D polygon with boundaries and holes.
  • There are different 2D polygon meshing algorithms varying in performance and robustness. OCCT has built-in algorithm called IMeshTools_MeshAlgoType_Watson and also provides an alternative IMeshTools_MeshAlgoType_Delabella.
• Splitting initial triangulation into smaller triangles to meet surface/triangle deflections criteria (linear/angular deviation parameters) as well as a set of additional parameters.
  • This is an iterative process that might take a while due to numerous expensive computations (computing new 3D points on surface, classifying them to boundaries, estimating deviation).

Other meshing algorithms like ExpressMesh or Netgen use very different approaches to 2D polygon tessellation and sub-division, although they do this to generate a mesh structure more suitable to various solvers / simulation algorithms rather than for an algorithm speed up.

You may imagine what would happen if we stop meshing algorithm on earlier stages:

• Ignoring Face boundaries.
  • Consider displaying a surface with natural boundaries or with trivial boundaries (e.g. TopoDS_Edge might be ignored).
    In this case 2D polygon tessellation can be defined as a trivial subdivision of rectangle (in UV parametric space) into desired number of triangles.
    This might work pretty well for displaying analytical surfaces with predictable appearance like a full sphere or cylinder.
    In fact, Draw Harness has a small command "tessellate" implementing this feature (src/MeshTest/MeshTest.cxx), basically intended for testing purposes, but implementation itself might have also practical cases.
• Ignoring deflection parameters.
  • It could be technically possible to stop TopoDS_Face tessellation on 2D polygon step, and edges tessellation might be done using simple sub-division parameters or faster algorithms like GCPnts_QuasiUniformAbscissa/GCPnts_QuasiUniformDeflection as alternative to GCPnts_TangentialDeflection.
    Result triangulation might not meet deflection criteria (but knowing surface properties in advance it is technically possible defining predictable sub-division parameters resulting in desired mesh quality) but might be computed faster and have a tolerable quality for visualization purposes.