So all this talk of the wireframe slider made me actually want to use it for something, and I’ve discovered that Stan is right, it’s definitely broken. It doesn’t reasonably respond to the angle between the faces at all. I said before that it worked fine, but I was wrong, I just hadn’t played with it enough. It works less like a slider and more like a switch.
Now, I don’t really care enough about the slider to report this, but someone might 
It does. Just not in the way Stan expects it to. Its not about hiding the edges that make up planar polygons. Its about reducing overall edge “clutter” while still giving a somewhat recognizable representation of what the model looks like outside of a fully rendered wireframe.
It is purely a visual aid. The way it decides where to draw edges is where there are abrupt changes in the surface curvature of the mesh. I think it uses the pointiness of the geometry; at least it appears that way to me. Its very similar to how people usually create edge wear masks in materials.
This is all it does, even to an extend at its own detriment. If you have a perfect sphere then even with tons of polygons it will still only draw a very thin outline even with the wireframe slider almost maxed out. So its definitely not perfect even if its only goal is to reduce virtual clutter.
Also before anyone jumps down my throat. I am not saying this makes it good; just that there is intention behind its design (reduce visual clutter) and there is a method to its choice of which edges to draw. Its not random as implied.
I thought this too. But no. It doesn’t. It doesn’t even behave like a slider, there are a few distinct steps and nothing in between. And setting it to zero doesn’t remove them all. It makes no sense to me.
But, I don’t really care. ¯\_(ツ)_/¯
Yeah, but as you can see from my screenshot, apparently it does neither of those things 
Unless removing literally a few edges counts as reducing clutter.
When you keep my previous observations in mind it really should not surprise you that on the model you used as an example, which is both really light geometry wise and has lots of big planar surfaces, the effect of the wireframe slider would be minimal.
Like I stated before its goal seems to be to reduce visual clutter and presumably at some point in the past, also to increase performance.
So you are most likely working from the scenario where you are talking about models whose polygonal density is so great they almost turn solid when viewed in wireframe. Objects that are scanned at a high resolution are a good example of such a case.
Lets take the Stanford Dragon as an example this time and see the effect the wireframe slider has:
So in specific cases it seems to do its job quite well.
Then again, I am not really arguing for keeping or removing it. I am personally indifferent to it, that scan is not particularly heavy for current hardware and I seldom work in scenes which get so cluttered I’d need to optimize my wireframe views.
That said other people have expressed its useful for them so from that point of view it seems valuable to keep it. Perhaps it could be renamed so its intended purpose is a little clearer.
Let’s just have a round of applause for the devs getting the viewport to a state where Blender no longer chokes badly on models like these, and we can comfortably talk about not needing the once-important slider anymore 
Thats in every way worse in my opinion.
Honestly the existing falloff effect wireframe has had since 2.8 completely removes the need for this wireframe slider imho.
That is not a problem of tesselation against decimation.
That is a problem of intent of import.
Why do you import a CAD model in Blender ?
Is it to make a softbody, cloth, fracturing simulation ? Or is it to obtain a beauty render ?
In the first case, that is weird because CAD or CFD software are probably more indicated by that is okay to keep a mesh tessellated with triangles all over the place.
If it is the second case, then, just replace all planar surfaces by Ngons.
In fact, that is not a problem that should be handled by Blender Team. That are CAD software that should offer correct .obj export.
that’s all fine and good till you have a nurbs surface with 1000 trims (e.g. holes) - I doubt blenders ngons will be able to handle that. And even then youll have all the connecting edges between the trims
Yes, that is what I meant.
It’s never “just” anything when you’re dealing with tens of thousands objects. Everything is impacted in Blender. Even little things add up to big slow downs when trying to manage this stuff.
For example, the only way to apply a modifier to an object through the Python API is to actively select it, you can’t just apply a modifier to the python object representing it. Selection gets slower and slower the more objects you have in your scene, this means adding a Decimate modifier to every object you import is incredibly slow when you’re in the 50,000+ object range. (45 min vs. 68 hour import for approximately 52,000 objects, no decimate vs. adding decimate)
First time I hear of this.
for o in bpy.data.objects:
if o.type == 'MESH':
mod = o.modifiers.new('Decimate', 'DECIMATE')
#set options on `mod`
Sorry, I meant you have to select the object to apply it, not add it.
edit: Hmm, thinking about it in a different way, instead of using modifier_apply, I wonder if I could use to_mesh or convert instead to avoid selection. Thanks!
@moderators
Now we’re 38 (-ish) posts into the ‘wireframe’-slider discussion. I believe a thread-split might be starting to be in order?
greetings, Kologe
Yip, I was just going to suggest that. Or you can also use
dg = context.evaluated_depsgraph_get()
mesh = bpy.data.meshes.new_from_object(object.evaluated_get(dg), preserve_all_data_layers=True, depsgraph=dg)
…and switch out the mesh.
Done. 
Have a nice weekend everyone.