kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 1/6/2011 12:57 PM, Wayne Stambaugh wrote:
> 
> On 1/6/2011 11:46 AM, "Torsten Hüter" wrote:
>> Hi Dick,
>>
>>> Thank you *very* much.  I appreciate your time and expertise.
>>>
>>> For clarification, Are you saying that the implementation on top of 2.9 is
>>> different and superior in a significant way?
>>
>> The implementation is superior because I can manipulate a wxBitmap directly with the wxNativePixelData and don't need to allocate memory. So it's surely faster. However, when I can figure out a platform independent way to get the color order, it should be as fast on wxWidgets 2.8 . I'll try to write a workaround.
>>
>>> Obviously the stuff under
>>> wxWidgets has not changed, and to a large extent you are simply doing a
>>> bypass of wxWidgets from GAL to cairo or open gl, no?
>>
>> OpenGL is no problem with 2.8/2.9, it's just the Cairo interface that has to be changed for the native backends or the current image backend.
>>  
>>> Is the 2.8 "good enough" for GAL to make a decent impression on first time
>>> observers?  Or do you recommend 2.9?  Or can be put a little of 2.9 into
>>> the
>>> GAL?
>>
>> Well, on 2.8 it's slower - but for pure speed you need hardware acceleration, that OpenGL provides. I think for a useful impression a complex scene is also required. The quality looks of course already with Cairo much better than the OR-mode of the current KiCad implementation (OpenGL looks good as well with antialiasing forced). Another good thing is that you can define transparency for any object or layer.
>>
>> Cairo is a software rasterizer; I've choosen it for a fallback solution when OpenGL doesn't work and it's useful as printing backend (PDF, SVG, PS, etc.) With Cairo you have also the option to use Freetype fonts. 
>>
>> Cairo should be a good candidate for eeschema, for instance GEDA Gschem uses Cairo and the schematic quality looks much better than eeschema in my opinion.
>>
>> Also for the best impression I think Cairo 1.10 should be used; because the image backend was much improved.
> 
> You may want to hold off using Cairo 1.10 until it is the default for most
> Linux distros.  AFAIK most distros are still shipping the 1.8 branch.
> 
> Wayne

Torsten,

Is there a reason why you chose to include a copy of the glew source instead of
using the version installed on your distro?  The reason I ask is that it does
not build properly on Windows using MinGW/MSYS.  I download the latest glew
source code an built as a DLL, installed it, commented out glew.c in the
sources list, and successfully built gal_test.exe and test_rubberbanding.exe.
Both programs run properly on Windows.  I also validated that it still builds
on Linux.  If there is no specific reason to include the glew source with GAL,
I will remove it and commit the changes.

Wayne

> 
>>
>> The drawing speed of Cairo depends on the effective use of the paths. A long path is better than drawing a lot of short paths. I'm trying that already, ideally many similar objects should be drawn after each other to maximize the path length. For example Text with the same stroke width or pads of the same diameter.
>>
>> Bye ..
>> Torsten
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>