The-OpenROAD-Project
Optimizes LayoutViewer performance
This PR optimizes the LayoutViewer performance by removing anti aliasing routines from axis aligned boxes and replaces our Pixmap target with a QImage instead.
I experimented with threaded rendering, but found the code unsavory in its current iteration. We should explore using an OpenGL paint device instead since a lot of the rendering we're doing is very suboptimal.
Potential Areas of Improvement
-
50% of render loop is spend in drawing the PinLabels. This is being eaten up by both the layout code and all the calls to getBoundingBox for the text. We should make sure that we are caching these layouts and not rendering text if it falls off screen.
-
Using OpenGL instead of our own custom rasterizer. A lot of time is spent drawing rectangles that are occuluded by other rectangles. On a CPU renderer this is killing our performance. Filling pixels is the single most expensive thing we could be doing. By moving to OpenGL (even a software implementation) we would benefit from its occlusion culling algorithms which would be faster than our implementation.
-
Distance based culling, possibly with QuadTree. When rendering the power grid at low resolution our framerate dips significantly. We should try to throw away geometry if it's not going to visibile. I can think of a few methods to doing this, but it's not exactly a simple optimization.
-
MipMapping/Caching different tile based renders of the layout. As a opposed to dynamically rendering them.
We already drop small objects when rendering unless you have 'detailed view' turned on. I guess you have it on if you see pin labels taking that long.
The layout is alpha blended so nothing is fully occluded.
You will find some people don't have opengl available and will still need a fallback (I did a GL enabled gui before and it happens with thin-client workstations or companies whose IT won't support a GL enabled vnc no matter how much you ask). I think it is better to treat this as a slippy map like google maps with more caching.
The pin grid labels around the block are the killers not the instance labels.
We could include a software opengl implementation, and statically link it in.
The pin grid labels around the block are the killers not the instance labels.
Those can be turned off too but I'm surprised they matter so much. How many pins do you have?
We could include a software opengl implementation, and statically link it in.
What package would you suggest here?
Something seems out of whack - the bbox of 600 pieces of text should be very fast compared to rendering all the layout shapes. Is this a fully routed design you are viewing?
Nope it's just that text shaping with harfbuzz is very very slow. Text rendering is some of the most complicated code you'll run across.
In the profile above you'll see that drawRect which accounts for almost all the geometry in the layoutviewer is only 20% of the profile. The line I added about PreferNoShaping makes the text rendering engine stop using harfbuzz, which is required for nonlatin scripts, and makes it closer to a 50/50 split.
Do you have a count of how many times these APIs are being called? Does it match you pin count?
I haven't Instrumented it to that level, but that shouldn't impact the goodness of this patch set.
I'll also point out that time is relative here. I think the pin grids are eating 20 fps of time or roughly 50ms of frame time.
If we want to hit 60fps we need to complete each frame in less than 16ms. That's going to require some very smart planning on our side without graphics accelerators.
This looks to be stale and will have a lot of conflicts with the threading changes. Reopen if you are going to work on this.