kicad-developers team mailing list archive

["Torsten Hüter" <torstenhtr@xxxxxx>]

Hi Marco & Lorenzo,

>I'm still stuck but i can wait, which is the deadline for the shipment >of the GAL in the trunk ?
>I'm proposing this approach because is a viable way to start to redesign >the drawing code before GAL is ready.

Well, I'm sure that still needs a while; but I think it should be a smooth transition - and the old code will be there for a while. Dick has proposed a painter class for this purpose - it's a collection of all drawing routines for board/schematic objects. I could imagine one of the next steps would be to implement this class - We have just to discuss first how we do it the best way.

My question is why you're stuck; does the old code not run well on OSX?
Another thing is that we should't build up two competing solutions; is the redesign on the same road?

>I'm almost scared to fight with a new Custom Graphics Abstration Layer.
>I'vent much time to dedicate and i'm afraid that debugging and correct >implementation on the platform will require months of frustrating work >to make it just work, this situation summed with the frustrating work i >were required to do for making it work until now (wxOverlay addition) >and added those months of Freeze the situation begins to approach the >limits of the allowable for a Gratis/Free work (as Dick reminds us >frequently).

Shure, but I've investigated lots of hours into this project (thus indirectly money). If someone likes to have OSX supported, he has to help me or - like Dick has written - organize/finance me a MAC. 
Perhaps even a remote login would help. 
I'm sure we can find a solution, when we're at this point.

The GAL is in my opinion not a custom layer. Like the name says it's an abstract approach; something that should be easily to extend. My goal is to solve some inherent problems of KiCad - that we get features like layer dimming, transparency, stepless zoom, smooth panning, a consistent vector algebra etc.

I'd assume there has not much to be changed on the OSX platform - because OpenGL is multi-platform and Cairo should also run well. That's why I've choosen these two backends.

---

> CAIRO is a showstopper on Linux without gallium (i.e. hw acceleration),
> so the problem remain...

Well, I've found it not that bad. It depends how you're using cairo. I think the wxGCDC approach is pretty inefficient - because the paths are not used optimally.

>The 'main' problem is that consumer cards (and drivers) are usually
>*awful* in performance in geometry-mode (i.e. wireframe, not filled
>polygons), just look at the opengl demos (which usually have a framerate
>counter and a filled/wireframe switch).

I don't believe that this statement is really true today. Simply because now graphics cards are general purpose computing units (GPGPUs). Even my notebook has 48 stream processors and it's rather a low end GPU.
Geometry is programmed and computed by the geometry shader for instance (when the fixed pipeline is not used). 

A lower end consumer graphics card like the Radeon HD 7770 for ~100 Euro has 1280 GFLOPS. That should be really fast enough :)

At least the examples that I've tried with the OpenGL-GAL run pretty smooth. It gets interesting, when we're able to show some real boards with it.

Bye,
Torsten
-- 
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de