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 _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
