← Back to team overview

kicad-developers team mailing list archive



On 08/mag/2012, at 06:16, Lorenzo Marcantonio wrote:

> On Mon, May 07, 2012 at 02:18:57PM -0500, Dick Hollenbeck wrote:
>> OSX
> OSX is handled in GRSetDrawMode (as it should be). GRSetColorPen uses MakeColour which only sets the alpha from the upper bits (are you referring to this?)
> Compositing mode has nothing to do with EDA_COLOR_T

Lorenzo, you got the point about bezier curves on bitmap conversion library and is there at disposition for further library conversion tools moreover is a 2d primitive of wxGraphicPath.

About OSX i'll resume again the status, OSX has not a raster interface but vectorial interface with alpha enabled by default called Quartz 2D.
The advantage of using a vectorial interface could be the possibility of zooming in hardware and having a virtually infinite resolution, etc , and I know that you are well aware of that.

I'm waiting from years that we could migrate to some of more "modern" than wxDC, i hope in the GAL will ship soon or that could be used wxGraphicsContext interface also on windows (there were performance problems) or some GAL that can be casted in wxGC.

In the meanwhile i had the not nice task to "CAST" the raster algorithm into the vectorial one, and wasn't a nice task, like cast a Blue Ray storage in punched cards.

The algorithm used by kicad to draw relies and is optimized to raster and there were some issues casted in the best effort way:

	All bit enabled operations are unusable like: XOR erasing and XOR color additions so:
		In redraw (zooming too) all is erased and redrawn - one reason why is "slow"
		Moving cursor has required wxOverlay (i've customized/patched wxWidgets to use native one after the Zoom hack change I can't use BITMAP one)
		Adding colors needs Alpha (that is enabled by default)
	Subpixels are DRAWN and blurred
	Zero size is respected (i become mad until few months ago)
	Being HW accelerated the expected primitive is not a point or a line but a complete PATH, roundtrip is expensive - other reason why is "slow"

All this "cast" is injected in the old code and now STABLE and usable, before do a revolution please take in account this, i don't want to stop you but make a change that has the right value added.
This code now compiles on 4 architecture (ppc,ppc64,x86,x86_64) just imagine how much it takes only to compile to test something, have mercy and do something that makes the worth to begin from scratch.