Why Gerber Viewers are slow to display, zoom, and pan?

Question

My machine has quad core i7 and should have enough ram. I tried different free Gerber viewers. They are slow to zoom or pan. There is always this "lag" feeling.

Does the gerber format contain too much data? What do you use for Gerber viewing?

Answer 1

Gerber files aren't 'images'. They're manufacturing data that need to be rendered into an image each time. For complex PCBs, this can be slow. Things like polygons needs to be rendered. Smooth and rounded corners need to be rendered. Its sort of like taking a vector graphics image and then adding more metadata to it. Gerbv has an option for fast rendering which skips over the smoothening of edges stage. That should help with lag.

Some CAD software let you specify a fill size option for polygons. In eagle, its based on the line thickness you use to draw the polygon outline. The thinner this line is, the more complicated the polygon becomes and the longer it'll take the gerber to render. This happens because polygons are rendered line by line.

Answer 2

They are slow to display mainly because the implementations of most Gerber viewers:

1. Don't treat geometry as geometry, but as primitives that are to be left alone.
2. Are single threaded.
3. Don't use hardware acceleration.

It's is very easy to leverage some existing library like cairo or Qt's QPainter to make a proof-of-concept Gerber viewer that runs great for low complexity files. It perhaps seems that many of them don't make it past that stage.

A hardware-assisted viewer will still deal with scenes that have on the order of 1 triangle per each D01 Gerber command (line). A project I've just been reviewing has ~2 million D01 Gerber primitives spread across 14 layers (I've forcibly disabled higher primitives). They triangulate to about ~30 million triangles if you try to treat Gerber commands as primitives. Sane Gerber output, using RS-274X primitives as they were meant to be used, is still rendered by converting polylines to polygons and then filling those - again, they're treated as primtives, each one treated independent of all others.

Once you properly merge the geometry, there are no more overlapping primitives on any of the layers - instead, you have nonoverlapping, disjoint polylines with holes. For the particular project I'm revieweing, the triangulation of those is well under a million triangles - a lot of the geometry is just large filled areas that can be represented by very few triangles.

Depending on how good of a triangulator you have, and how lucky you are with the source files, you can go down to 1 triangle per 10 Gerber D01 lines, or about one triangle per coordinate. Now we're talking of things that regular graphics cards can handle without breaking a sweat, and you don't even have to care to remove invisible triangles. Since there are no textures, the fill rates are phenomenal.

A more modern approach would probably encode the data in a different form - instead of triangles, distance fields in a square or triangular grid work well, and then you can have the shaders actually do some work instead of just pouring paint into triangles :) In such representation, even integrated graphics cards do rather well. On my laptop, a 40 million primitive Gerber file can be viewed, in its entirety, at screen refresh rate on the discrete graphics (Nvidia 950M), or at 5FPS with integrated graphics, and that's without any preprocessing other than merging overlapping primitives and cutting it up with a square grid. I'm sure that someone with actual experience in GPU programming could make the integrated one perform many times better, so at this point it all comes down only to getting the right people working on that problem.

But this good of a performance requires a radical departure from the proof-of-concept approach, and Gerber viewers aren't exactly high on everyone's totem pole, so they languish.