← Back to team overview

kicad-developers team mailing list archive

Re: Advanced rendering techniques for KiCad


Hi Lorenzo,

I believe we have already discussed about this subject :)

Not to ruin your work/enthusiasm but... who cares? :D

At least Dick, Wayne & Jerry seem to care :)
But I think there is a demand for hardware acceleration / high quality rendering - this was often posted on the list.

Especially when, in a PCB cad system, the *absolutely most useful*
blending mode for layer is the XOR one (which IIRC was retracted from
OpenGL with color index mode, maybe it can be done with fragment

Sorry, I have to disagree. Sure, XOR is the simplest way - but has not the advantages of the modern blending methods. With XOR you don't have any control of the transparency, you can't implement custom dimming of the layers, anti-aliasing is almost impossible. Please check kicadocaml - or my personal favorite:

Proteus PCB

They use also OpenGL for the hardware acceleration. I've tried the demo version and the look&feel is clearly superiour to KiCad. It's not just "eye candy" - I think there are many productive advantages, like stepless zoom, panning, more control of the contrast for layer inspection etc.

OpenGL supports also logical operators. I've not tried it, but I'm sure even XOR is possible, if someone really needs this.

I say that because I tried gerbv high-quality mode (i.e. cairo blending,
software slow as hell) and, in fact, antialiasing/blending *detracted*
from the usefulness of visualization!

Well, I don't know if gerbv is the best example. We should rather have a look at commercial tools, like the mentioned Proteus PCB, the Altium Designer or FAB-3000 (we use that Gerber tool). All have now some kind of hardware acceleration. Cairo was recently improved, but I agree it's not the best API for drawing speed. For this purpose we have OpenGL. Although the antialiasing mode of gerbv is pretty slow, in fact I found the quality much better. I've used it also to export layers and have even created PNGs for our manufacturer this way.

In any case, the only 'correct' way to render alpha blendings in OpenGL
is to sort by layer, no Z-buffer technique can help you with that: it's
simply the way blending works!

That's not correct. Perhaps I'm wrong - but I'd assume you have not read the latest computer graphics papers or you have not implement such stuff yourself. There are many alternative methods to do alpha blending, for example NVIDIA has some nice papers about depth peeling / transparency etc. With my algorithm you still have to sort the layers by the depth; but it doesn't solve the problem. Let's say we have two overlapping objects on one layer, how to prevent that the overlapping area doesn't get another color when using half-transparency? One answer is to use the Z-Buffer; I've got the idea from Tim Henson (author of kicadocaml).

In our case it's fairly easy to separate
stuff, just use a display list for each layer... and, no, FBOs won't be
useful in the general case to 'optimize' redrawings, you *have* to
repaint everything, unless you only change the top layer, to keep
correct blending. You *could* try with a FBO for each layer but it would
gobble heaps of video memory!
That's exactly one thing that I don't want to do. I need only one FBO. When you're panning or zooming usually you have to do a redraw with any method. Sure you could put every layer on a separate texture/FBO but I don't think that would have any benefit. BTW I don't redraw the full scene for the cursor, I just restore the drawing area. Display lists are already supported with the "Group"-method.

A truly optimized way to handle it for
simple modifications (i.e. track drawing) would be an FBO for the layers
under the one being modified and another one for the layers above: so
you could update using an unblended blit, then the blended drawing of
the current stuff (being modified) and finish with a blended blit of the
'upper' layers.
I've considered already this method for rubberbanding. That means I'd put the moved object on a textured quad. I'm using a similar method already for the cursor.

Also think about all these people with open source drivers and/or low
end graphics :D heck, on my work machine I don't even HAVE opengl acceleration:P

My goal is to create something that offers superiour quality/speed to any known tool. Sure that means it doesn't work on >10 years computers, but even then we can develop a fallback method. I've choosen a modular architecture, this means of course other APIs than OpenGL are possible. Currently I've written the interface for OpenGL and Cairo. For another APIs someone has just to implement the interface. If you like to contribute, you're welcome.


Follow ups