kicad-developers team mailing list archive

[Torsten Hüter <torstenhtr@xxxxxx>]

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
> shaders).

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
http://www.labcenter.com/support/video/demo-movies.cfm?videoType=pcb&tab=7

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.

Thanks,
Torsten