Enabling Empty Custom Conduit Causes Lags in V6

I noticed that viewport with empty but enabled custom conduit causes lags in v6 in v5 it doesn’t matter - interesting is that if i only put one box in conduit everything works smooth but unless conduit is enabled and empty i have rather slideshow in vp.

Not sure who should look at this @nathanletwory ?

Maybe @stevebaer or @jeff

1 Like

Thanks @nathanletwory! I found where was the issue i had point list in postdraw which wasn’t null since it was just empty list so if statment had to be not == null but .Count > 0 - Anyway v5 dealt better with that kind of stuff so this could be investigated for v6 :wink:

Can we please get an example of this? I’m not following what you did that was slow and what you changed to fix it. Checking for null vs. a Count > 0 would have no impact on performance for a conduit. But, if you’re calling draw routines in some cases and not others, then I could see potential performance differences…but a simple example would help us understand exactly what you did.


@jeff im not sure if here sample is needed just put list without any points to postdraw override and run you will see that framedrop instatly for sure i’ll post my example for this as soon as i’ll be near computer.

@jeff create normal plug with custom conduit and put this for postdraw:

protected override void PostDrawObjects(Rhino.Display.DrawEventArgs e)
                if (boxes.Count > 0)
                    foreach (var item in boxes)
                        e.Display.DrawBox(item, Color.Yellow);

register boxes as: List<Box> boxes; but don’t construct boxes - i think it is throwing exceptions internally that boxes are null - in v5 somthing like this doesn’t have impact on viewport performance and kept doing further code in v6 this causes huge performance drop and it stops doing code at line with bug.

Constantly throwing exceptions in your conduit is going to cause the display to slow down. I don’t plan on making any changes to try and improve performance in this case. I would rather spend the effort in letting you know that there is faulty conduit code.

1 Like

That’s for sure better approach :+1: for now i wonder how i could wrap this in try catch.

While you’re developing your plug-in with Visual Studio you should enable at least breaking on NullReferenceException. It isn’t enabled by default.


You can get there through Debug > Windows > Exception Settings

1 Like

Thanks Nathan! I had earlier null exceptions so i thought they was on but indeed this was off.