kicad-developers team mailing list archive

[Lorenzo Marcantonio <l.marcantonio@xxxxxxxxxxxx>]

On Fri, 16 Jul 2010, "Torsten Hüter" wrote:

> XOR drawing is one of the simplest ways for erasing the old drawing; but artifacts are the problem (this is rather a bug than a feature). In theory OpenGL for instance supports the XOR operator; but only in color index mode.

Well, in opengl you're forced to redraw *everything* at each frame
(excluding clever FBO usage), so the xor approach isn't feasible. Also
note that bit operation require an extension and that index mode is
being dropped from opengl (also: I think that index mode is nearly not
accelerated... my old FireGL simply didn't provided it!)

> I'd prefer not to use XOR, instead I'd first try the redrawing of the scene (a double buffer is already used) - if that's too slow I'd save the old frame buffer to an aux buffer, overdraw the screen with the moved object and then restore the old contents via blitting. Blitting is already done for the cursor.

Yep, the 'clever' FBO usage is exactly what you called an 'aux buffer'
(which in opengl is another kind of thing:P) Also double buffering is
mandatory for acceleration these days, anyway. OTOH maybe you could
simply stuff the 'other' things in a display list and replay it. Just
because FBO are not a core feature but yet another extension, IIRC.

> > Again, I do think the feature you Lorenzo highlight would be slick, and
> > would actually be a little more intentional than some of the artifacts
> > we have now.  Those current artifacts are more like litter left behind
> > after a picnic :), but seem to have been found useful.

I'd suggest so simply draw them in subdued color, like an 808080 gray or
something like that.

> AFAIK the Radeon 200 is based on the X300 Mobility; which is older than 5 years. It's true that there could be a better support for Linux, but the newer products have a good OpenGL support - both ATI and NVIDIA offer drivers, which have the same code base like their Windows variants.

This box was bought less than 3 years ago and it's a perfectly working
dual core machine... also a lot of people doesn't use accelerated ATI
drivers for their... innate suckitude :D

I keep wondering what kind of graphic primitive do you need to use
opengl instead of 2D graphics primitives (which are already being
accelerated by the X server). Also keep in mind that most consumer cards
are optimized for full screen opengl only (at least in the times of
nvidia-8, years ago, I know). If the card doesn't have a UBB or
something similar you get a blit instead of a page flip (which is really
bad). Of course performance could be good anyway, depending on the kind
of GPU and CPU you target to.

/me is usually working more in software to go on cheaper hardware since
we produce the hardware too (so, in the end, hardware is *more expensive*
than development time). And don't forget that kicad is, at the moment,
an entry level product... while Mentor could ask for a ginormous box
(since anyway with their licence you can buy about 4-6 top-class PCs,
these days:D) we would risk to loss some of the eagle-level audience.

At the moment the only thing is a little slow on kicad is zone filling
(which I usually keep disabled anyway because it distracts from the
track layout...). I guess it could be a little sluggish on my box with
an 8-plane in 6 mil technology (well, such a board could use a faster
box anyway).

> I think the wxGCDC (backend is Cairo on Linux) variant is slow, because for every graphics primitive a new path for the pen is created. This is very ineffective - ideally when you're drawing something with Cairo the paths should be as long as possible. One good example is text drawing, there one path could be used.

Cairo is slow by definition until it isn't accelerated some way... gerbv
with cairo is absolutely not useful! (BTW transparency in a gerber
viewer is not useful for checking stuff. XOR combining IS useful)

--
Lorenzo Marcantonio
Logos Srl