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