Speeding up blenders edit mode view

I tried searching the source code to find out where it even draws the edit overlay. I could not find it. I don’t want to spend months learning the blender source code. So instead I decided to drop my idea onto the forum.

It’s my hypotheses that blender is blotting the vertices and edges using things like putpixel(). This has been historically very slow.

It’s my idea that replacing the vertice drawing function, with drawing cubes instead. I believe if the vertices are drawn as cubes, it would significantly increase the blender edit mode performance.

Your hypothesis is incorrect. You don’t fill individual pixels manually. Instead, you send data to the GPU and tell it how to draw it, and it draws it very, very, very, VERY fast. But even if you were to fill individual pixels manually, drawing more complex shapes instead of simpler would’ve degraded performance, not improved it.

Drawing isn’t the problem here - Blender fluently redraws heavy scenes as you navigate around them. The actual bottlenecks are way more complex than a trivial task of writing data to a buffer.

I’d recommend to leave this stuff to the experts, especially if you don’t want to spend months learning how things are actually done.


The problem is not rendering the object. I am talking about the view of the vertices. I am talking about rendering cubes rather than putting pixels for vertices in edit mode. Provide proof that blender is drawing an object using the GPU in source code, rather than putting a pixel.

I know how a GPU and polygons work. I am talking about something else.

You could easily try out whether drawing the vertices/edged/faces is the issue. Just create an object which is slow in edit mode. Now, deactivate “Show Overlays”, such that the vertices/edges/faces aren’t drawn at all. If the performance is now significantly better, your hypothesis might be right.

In my quick test, there was a slight difference as expected, but nothing major.

Edit: When you make that sort of claims, you should be the one to proof you are right. Just assuming they don’t know what they are doing proofs nothing and helps no one. The developers have been working with that sort of stuff for years or even decades. Assuming they are using the worst of the worst ways to draw something as fundamental as this appears like a Dunning-Kruger in action to me.

1 Like

Easy, you can start here:


Again, all this stuff aside, just take a step back and analyze what you’re saying. Let’s just pretend that the edit mode overlay was drawn manually straight into an image buffer. In that case, what would “render a cube” mean? You’d need to project eight vertices of a cube from 3D space onto a 2D canvas, and then… somehow fill it on that canvas. Using, in your terms, this made up “putpixel”. As opposed to projecting just the one vertex that you’re drawing and filling a 2D circle (or square) around it.

@DeepBlender that hypothesis cannot be confirmed by tinkering with settings, only by looking at the source.

The bottleneck in editmode is not the drawing, read the task on the developer site to know what is really slowing things down.

You can verify this with the fact that Blender is pretty snappy when moving around a mesh with tons of vertices, but very slow when doing an actual editing operation. Start with the points listed by Campbell if you want your dev. work to really speed things up.

1 Like

After the test I suggested, it is highly unlikely that the hypothesis is correct. That’s all I am saying. But you are certainly right that it is not a precise way to figure it out! Even without looking at the source code, it is quite easy to figure out whether it is a bottleneck.

If the conjecture is that edit mode is slow due to the way the overlay is drawn, one has to verify that by looking at how the overlay is drawn :wink: Disabling the overlay would test whether it has an effect on performance, not what causes that effect or its magnitude.

Perhaps, humanartist, it is not quite clear what you are “talking about.”

To this fairly-disinterested observer, this sounds very much like an “XY Problem.”

The XY Problem is a communication problem encountered in help desk and similar situations in which the person asking for help obscures the real issue, because instead of asking directly about issue X, they ask how to solve a secondary issue, Y, which they believe will allow them to resolve issue X.