OpenCascade is a mature geometry kernel. It is used by FreeCAD, IfcOpenShell, and XBim. However, the problem is a bit more complex.
The reason Revit and ArchiCAD perform so well geometrically in its ability to convert from 3D objects to hidden line renderings and therefore 2D representations is because it limits the geometric representation to perfectly manifold solids, and especially in Revit's case, even doesn't allow small dimensions to prevent numerical tolerance issues. This has a pro and con: the pro is that shapes can be highly optimised for boolean and HLR algorithms, but the con is that the modeling capabilities become really limited. As you can see, their geometry kernel is powerful, yes, but more importantly are the restrictions they have placed on the users' ability to create geometry.
In IFC, the story is different. IFC supports a huge variety of geometric representations - from surfaces, meshes, NURBs, extrusions, sweeps, booleans, point clouds, mixtures between the two, and even I-beam shaped profiles. There isn't a single geometry kernel in the world that treats all of these representations as native data types. Therefore, to allow consistent manipulation of geometry, the geometry kernel needs to be processed to a common geometric representation. This is a slow procedure that prioritises compatibility over speed, regardless of geometry kernel, and does not mean the kernel is not capable, but simply the strategy in which we have to use the kernel is restricted.
This is true of any application dealing with IFC - even in Revit, their geometry kernel has to parse the dozens of geometric representations possible with IFC and then convert it into their own format. This is a huge challenge, especially given the internal restrictions of their geometry kernel. For this reason, IFC takes a long time to import into Revit, and many IFC objects (depending on the representation) will become uneditable once imported.
Currently the approach taken with OpenCascade in all of its end-user applications (e.g. FreeCAD, XBim, etc) is to convert all IFC geometry into a brep. This is very good for compatibility, but perhaps less ideal for HLR algorithms. However, it is perhaps a necessary evil first implementation strategy when you are dealing with IFC's dozens of representation types.
That isn't to say that it is the only solution - OpenCascade can be used differently and parse shapes in different ways, which would drastically change its abilities to quickly represent and draw geometry. For example, this is happening now with rebar - a circle swept along a path. A Brep conversion of rebar is ridiculous, but FreeCAD bypasses IfcOpenShell's conversion, and directly reads the profile curve and does its own rebar. This makes a huge difference in scalability - much faster imports, lighter models, and therefore efficient rendering.
This discussion isn't complete with mentioning other geometry kernels. For example, CGAL is also extremely capable as a kernel, but comes with pros and cons too - for example, although it is much more modern as opposed to the small community around OpenCascade, there is a strong reason all of the BIM programs so far have chosen OpenCascade: really good STEP support, which the most common format of IFC is based on. However, IfcOpenShell is actually geometry-kernel agnostic. Version 0.7.0 of IfcOpenShell actually allows you to switch between OpenCascade and CGAL. I wouldn't call it stable, though :)
I hope this explains some of the complexities in looking at the geometry kernel.
In my current implementation of construction documentation, there is a three step process:
The IFC file geometry is converted into OpenCascade Breps, thanks to IfcOpenShell. This is the slowest process currently.
OpenCascade does a boolean slice where the section cut is. This is also slow, but slightly faster as only a subset of geometry is booleaned.
I don't even process the shapes in the background, I delegate that to a rasterised Blender render, which is practically instant. The bottleneck in this step is the file writing.
The first two steps have some basic optimisations: the first step is cached, for subsequent cuts from any direction in the model. The second step uses bounding box checks to ensure only the relevant geometry is booleaned.
These are just the beginning of the optimisations. Here are a list off the top of my head which could make things so much faster:
Multicore geometry processing in IfcOpenShell (half implemented)
Certain geometry is processed differently, especially swept solids
Process geometry only where the cut is - requires bounding boxes.
Write it in C++! My prototype is in Python. This is slow. Very slow.
Send hints from the Blender (or FreeCAD?) UI with its rasterised render to tell the OpenCascade kernel what to process - this can lead to huge speed improvements.
I hope this made sense.