kicad-developers team mailing list archive
Mailing list archive
Re: Advanced rendering techniques for KiCad
On 10/3/2011 3:18 PM, Torsten Hüter wrote:
> 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.
Please don't let this discourage you. IMO OpenGL support is very important for
the future of Kicad. It seems silly to me not to take advantage of hardware
accelerated graphics available on most modern computers.
>> 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
> Proteus PCB
This video really shows why OpenGL support is important. The smooth scrolling
and cursor fly-over highlighting are really slick. I doubt we could duplicate
these features with comparable quality and speed with wxDC. It also points out
that we have some work to do to catch up with our graphics rendering. I'm sure
I'm not alone when I say that I appreciate your efforts.
> 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
>> 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
>> 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
>> 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.
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp