ReferenceIntersector causing significant delays due to 3D view graphics

[tebogo.schultzH5FH3]

My automated add-in is using some code that calls into ReferenceIntersector with the default {3D} view in a document several times in a loop.  The doc has reference links to other external revit files.  When I don't load these files (ignore the links and load without them), the ReferenceIntersector completes reasonably quickly.  However, with the links, I get continued progress bars in the bottom for "Generating graphics for 3D view {3D}" and the process takes an order of magnitude longer time.   Revit is essentially generating the 3D view graphics and throwing them away and regenerating them again and again on each iteration.  Is there anything I can do here to avoid these unnecessary delays?

I tried using an idle handler to pre-open the 3D view via `uiapp.ActiveUIDocument.ActiveView = default3DView;` in advance of running my code but it has zero effect (won't change or open the 3D view).  

Pretty much out of ideas here.

[jeremytammik]

> Revit is ... regenerating them again and again on each iteration.  Is there anything I can do ... ?

Yes: avoid the iterations.

[tebogo.schultzH5FH3 · Accepted solution]

In contract, here's an actually helpful response.

The solution was to make sure the sheet was displayed properly by calling the correct method to do so.

            var default3DView = new FilteredElementCollector(doc).OfClass(typeof(View3D)).ToElements()
                                .Cast<View3D>().FirstOrDefault(v => v != null && !v.IsTemplate && v.Name.Equals("{3D}"));

            if(pendingIdle && GlobalState.measure3D && !GlobalState.is3DViewOpened && default3DView != null && uiapp.ActiveUIDocument.ActiveView != default3DView)
            {
                Logger.log("Setting 3d view..");
                uiapp.ActiveUIDocument.RequestViewChange(default3DView);
                GlobalState.is3DViewOpened = true;
                return;
            }

[jeremytammik]

Wow! That is a fantastic answer indeed!

Please excuse my previous flippant answer; I did not understand the need for the iterations nor could I understand why something was being regenerated unnecessarily, or why delays could occur that are not necessary.

In fact, I still do not understand that.

Now you point to even more exciting information that I do not understand. 

I have never previously heard of the RequestViewChange method:

https://www.revitapidocs.com/2020/a2e920d4-2849-282e-c25f-40a4d2cbef2d.htm

"Requests an asynchronous change of the active view in the currently active document... This method requests to change the active view by posting a message asynchronously. Unlike setting the ActiveView property, this will not make the change in active view immediately. Instead the request will be posted to occur when control returns to Revit from the API context. This method is permitted to change the active view from the Idling event or an ExternalEvent callback."

Thank you very much for pointing it out.

Actually, now that I put together the two aspects that I previously did not understand, your problem and this method, things begin to come into place a bit more...

Cheers,

Jeremy