Cut outs in pcbnew don't work with newest boost

[Sebastian Schumb]

I've already reported this bug on the Archlinux bugtracker here : https://bugs.archlinux.org/task/31559
Where I've been told that it was an upstream issue, so I'm reporting a slightly updated version here as well.

Description:
Pcbnews 'cut out' zones seem to have stopped working recently under Atchlinux.
The cut outs get filled as well.

Additional info:
* Archlinux package version : 20120119-2
* Installed from community
Should be kicads stable branch rev. 3256 here on launchpad.

* gcc version : gcc (GCC) 4.7.1 20120721 (prerelease)
* g++ version : g++ (GCC) 4.7.1 20120721 (prerelease)
* boost version : 1.50.0-2
* mesa version : 8.0.4-3
* wxgtk version : 2.8.12.1-3

I've test this under x86_64 and i686, same bug on both architectures.
Also I've tested the same kicad version under ubuntu 12.04 and windows where I could not reproduce the bug.

Steps to reproduce:
1. Install kicad from community
2. Start kicad, create a new project
3. Start pcbnew
4. Create a new Zone (leave all zone options to defaults)
5. Rightclick the border of the Zone and click Zones -> Add cut out
6. Draw the cut out area anywhere you like, but fully inside the zone
7. Rightclick the border of the Zone again and click Zones -> Fill Zone

Expected result : The zone is filled except for the cut out area.
Actual result : The zone is completely filled.

For easier reproduction I've attached a small test project including a pcbnew file.
In that file I defined a zone with a cut out and filled it using the windows version, so the filling works correctly and I could make sure it's not just a wrong setting.
If you remove the filling and try filling it again under archlinux, the zone will become completely filled.

I did some further research on my own regarding the unbutu package as suggested on the Arch Linux bugtracker.
While preparing this report I tried to build kicad using the sources used in the ubuntu package.
As far as I can tell there are no patches included in the ubuntu package (sources can be found http://packages.ubuntu.com/source/precise/kicad).
It seems to be build from a clean upstream bzr checkout.
Building the kicad package with the ubuntu packages sources didn't solve the problem as well.

[jean-pierre charras (jp-charras)]

It could be tricky.
Test.brd works fine for me, and your filled zone has a cutout (not filled) and is good on my screen.
The polygon built by Pcbnew to draw the zone with its cutout is good.
You can easly see it when selecting the option "show outlines of filled areas only in zone" by the left vertical toolbar.
Seems there could be an issue in a polygon drawing routine (outside Kicad).
Can you verify test.brd on an other PC (under an other Linux version) ?

[jean-pierre charras (jp-charras)]

Sorry, I did not see you have already tested it on an other PC.

[Sebastian Schumb (longhairedhacker)]

Maybe I need to clarify this a bit :

The test file was made using windows because cut outs work there.
Also when I open it the filling always looks correct, the bug shows up when you refill it.
I've attached a screenshot showing the outlines. So it's only a polygon filling bug.
The postscript and the gerber output are affected by this bug as well.
I forgot to mention that earlier.

It was tested on the following platforms always using rev. 3256 :
desktop x86_64 Arch Linux : fails
laptop i386 Arch Linux : fails
a friends laptop x86_64 Arch Linux : fails
desktop using ubuntu 12.04 : works
Virtualbox VM with Windows : works

So I guess this problem is somehow related to the library versions used in Arch Linux.

[Dick Hollenbeck (dickelbeck)]

On 09/26/2012 10:04 AM, Sebastian Schumb wrote:
> * gcc version : gcc (GCC) 4.7.1 20120721 (prerelease)
> * g++ version : g++ (GCC) 4.7.1 20120721 (prerelease)
> * boost version : 1.50.0-2

Random shots in the dark:

Maybe try the testing branch, not stable branch?

boost version, since it is stated, sounds like it is de-coupled from KiCad. This should
not be the case. We supply all the boost you need in our tree.

The compiler is prerelease.

[Sebastian Schumb (longhairedhacker)]

Okay, I did not know that the boost stuff is already inside the kicad tree. It is listed as a buildtime dependency by the archlinux package.
So I thought the version was important.

The compiler is the standard version that you get when you install gcc under arch linux.
I can try downgrading it, but since all other packages build fine with it I don't think that's the problem.

Also I'm going to try a testing version later.

[Sebastian Schumb (longhairedhacker)]

Just a short update :
I had the time to test (2012-09-28 BZR 3746)-testing today.
It has the same bug.

[Sebastian Schumb (longhairedhacker)]

Moin

Annother update :
I've just rebuild the package using gcc 4.4.6, since 4.4 is version used in ubuntu.
Using this compiler I was able to compile rev. 3256 with working cut outs.

So it seems like dickelbeck was right. It's related to my compiler version.
As far as I can tell from my limited knowledge about gcc/g++ and boost, I'd guess that the rather old boost version (1.40 from 2009 iirc) doesn't build correctly with a newer compiler.

I'll try the same with the lastest code from the testing branch testing later.

[Sebastian Schumb (longhairedhacker)]

I've just compiled rev 3750 from testing using gcc 4.4.6.

Cut outs worked with this revison as well.

[Dick Hollenbeck (dickelbeck)]

On 10/04/2012 12:38 PM, Sebastian Schumb wrote:
> Moin
>
> Annother update :
> I've just rebuild the package using gcc 4.4.6, since 4.4 is version used in ubuntu.
> Using this compiler I was able to compile rev. 3256 with working cut outs.
>
> So it seems like dickelbeck was right. It's related to my compiler version.
> As far as I can tell from my limited knowledge about gcc/g++ and boost, I'd guess that the rather old boost version (1.40 from 2009 iirc) doesn't build correctly with a newer compiler.

Your problem compiler was labeled a "pre-release" version. For major releases the gcc
team will continually strive for better code generation. This means tweaks to
optimizers. Shortcuts can be introduced which should have corner cases, so there is some
risk in using a pre-release compiler. This is true regardless what you are trying to
compile, i.e. it is not a function of "old boost" necessarily.

We cannot hold this against the gcc team, they warned you, in the version labeling.

On the other hand, one might question the arch linux folks, who bet on a horse before it
was mature enough to depend on. That seems like unnecessary risk to me.

[LordBlick (lordblick)]

I've got same problem with:
$ gcc -v
Reading specs from /usr/lib64/gcc/x86_64-pld-linux/4.7.2/specs
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-pld-linux/4.7.2/lto-wrapper
Target: x86_64-pld-linux
Configured with: ../configure --prefix=/usr --with-local-prefix=/usr/local --libdir=/usr/lib64 --libexecdir=/usr/lib64 --infodir=/usr/share/info --mandir=/usr/share/man --x-libraries=/usr/lib64 --disable-bootstrap --disable-build-with-cxx --disable-build-poststage1-with-cxx --enable-c99 --enable-checking=release --disable-cld --enable-cloog-backend=isl --enable-cmath --enable-decimal-float --enable-gnu-unique-object --enable-initfini-array --enable-languages=c,c++,fortran,objc,obj-c++,ada,java,go --enable-libgomp --enable-libitm --enable-libmudflap --enable-linker-build-id --enable-linux-futex --enable-long-long --enable-nls --enable-lto --enable-plugin --enable-shared --enable-threads=posix --disable-werror --with-cloog --with-demangler-in-ld --with-gnu-as --with-gnu-ld --with-linker-hash-style=gnu --with-long-double-128 --with-ppl --with-slibdir=/lib64 --without-system-libunwind --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-libstdcxx-threads --enable-libstdcxx-time=rt --enable-libstdcxx-visibility --enable-symvers=gnu --with-gxx-include-dir=/usr/include/c++/4.7.2 --disable-gconf-peer --enable-gtk-cairo --enable-java-awt=xlib,gtk --enable-jni --enable-libgcj --enable-libgcj-multifile --enable-libgcj-database --disable-libjava-multilib --enable-static-libjava --enable-xmlj --with-pkgversion=PLD-Linux --with-bugurl=http://bugs.pld-linux.org x86_64-pld-linux
Thread model: posix
gcc version 4.7.2 20120920 (release) (PLD-Linux)
It's not prerelease
boost-1.51.0-5.x86_64
Builded revision 3261 with attached patch is affected with "no cutout" bug.
Also it's nessary to cut ^r Windows endline bonus:
sed -i -r "s/\r$//g" \
 include/boost/polygon/polygon_90_set_data.hpp
Maybe I'm on wrong way ? I have not alternative to gcc-4.7 in my prefered distro...

[Dick Hollenbeck (dickelbeck)]

On 10/09/2012 09:13 AM, LordBlick wrote:
> It's not prerelease

I am not volunteering to fix this bug, but I would suggest that you make it as easy as
possible for someone to step up and do that.

What you can do is prepare the simplest board file possible which exhibits the problem. I
think this is a new mostly empty board (few or no tracks or components), with only two
zones if that will cause it.

From that a separate test program may be able to be written using only the boost library
and the two rectangles.

Just a suggestion, but it might be helpful. This bug may not be easy to fix without these
simplifications.

[LordBlick (lordblick)]

My problem is that simplificity is not possible in my project, because my trademark logo on PCB is as few zones with cutouts and it works before... ;)
I suppose that adapting to newest boost will be best point.
Regardless thank you for the advice.

Example in inconvenience with newer boost ( rm -rf include/boost & use /usr/include/boost):

[ 58%] Building CXX object eeschema/CMakeFiles/eeschema.dir/class_libentry.cpp.o
cd build/eeschema && /usr/bin/c++ -DKICAD_STABLE_VERSION -DwxUSE_UNICODE -DKICAD_KEEPCASE -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -DEESCHEMA -m64 -O2 -fwrapv -pipe -Wformat -Werror=format-security -gdwarf-4 -fno-debug-types-section -fvar-tracking-assignments -g2 -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -fPIC -march=x86-64 -gdwarf-4 -fno-debug-types-section -fvar-tracking-assignments -g2 -pthread -isystem /usr/lib64/wx/include/gtk2-unicode-release-2.8 -isystem /usr/include/wx-2.8 -Iinclude -Ishare -Ibuild -Ieeschema -Ieeschema/dialogs -Icommon -Icommon/dialogs -o CMakeFiles/eeschema.dir/class_libentry.cpp.o -c eeschema/class_libentry.cpp
In file included from /usr/include/boost/ptr_container/detail/reversible_ptr_container.hpp:24:0,
                 from /usr/include/boost/ptr_container/ptr_sequence_adapter.hpp:20,
                 from /usr/include/boost/ptr_container/ptr_vector.hpp:20,
                 from include/base_struct.h:12,
                 from include/class_drawpanel.h:10,
                 from eeschema/class_libentry.cpp:33:
/usr/include/boost/ptr_container/clone_allocator.hpp: In instantiation of 'T* boost::new_clone(const T&) [with T = LIB_ITEM]':
/usr/include/boost/ptr_container/clone_allocator.hpp:68:33: required from 'static U* boost::heap_clone_allocator::allocate_clone(const U&) [with U = LIB_ITEM]'
/usr/include/boost/ptr_container/detail/reversible_ptr_container.hpp:110:63: required from 'static boost::ptr_container_detail::reversible_ptr_container<Config, CloneAllocator>::Ty_* boost::ptr_container_detail::reversible_ptr_container<Config, CloneAllocator>::null_clone_allocator<allow_null_values>::allocate_clone(const Ty_*) [with bool allow_null_values = false; Config = boost::ptr_container_detail::sequence_config<LIB_ITEM, std::vector<void*, std::allocator<void*> > >; CloneAllocator = boost::heap_clone_allocator; boost::ptr_container_detail::reversible_ptr_container<Config, CloneAllocator>::Ty_ = LIB_ITEM]'
/usr/include/boost/ptr_container/detail/reversible_ptr_container.hpp:95:71: required from 'static boost::ptr_container_detail::reversible_ptr_container<Config, CloneAllocator>::Ty_* boost::ptr_container_detail::reversible_ptr_container<Config, CloneAllocator>::null_clone_allocator<allow_null_values>::allocate_clone_from_iterator(Iter) [with Iter = boost::void_ptr_iterator<__gnu_cxx::__normal_iterator<void* const*, std::vector<void*, std::allocator<void*> > >, const LIB_ITEM>; bool allow_null_values = false; Config = boost::ptr_container_detail::sequence_config<LIB_ITEM, std::vector<void*, std::allocator<void*> > >; CloneAllocator = boost::heap_clone_allocator; boost::ptr_container_detail::reversible_ptr_container<Config, CloneAllocator>::Ty_ = LIB_ITEM]'
/us...

[Wayne Stambaugh (stambaughw)]

On 10/9/2012 10:13 AM, LordBlick wrote:
> I've got same problem with:
> $ gcc -v
> Reading specs from /usr/lib64/gcc/x86_64-pld-linux/4.7.2/specs
> COLLECT_GCC=gcc
> COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-pld-linux/4.7.2/lto-wrapper
> Target: x86_64-pld-linux
> Configured with: ../configure --prefix=/usr --with-local-prefix=/usr/local --libdir=/usr/lib64 --libexecdir=/usr/lib64 --infodir=/usr/share/info --mandir=/usr/share/man --x-libraries=/usr/lib64 --disable-bootstrap --disable-build-with-cxx --disable-build-poststage1-with-cxx --enable-c99 --enable-checking=release --disable-cld --enable-cloog-backend=isl --enable-cmath --enable-decimal-float --enable-gnu-unique-object --enable-initfini-array --enable-languages=c,c++,fortran,objc,obj-c++,ada,java,go --enable-libgomp --enable-libitm --enable-libmudflap --enable-linker-build-id --enable-linux-futex --enable-long-long --enable-nls --enable-lto --enable-plugin --enable-shared --enable-threads=posix --disable-werror --with-cloog --with-demangler-in-ld --with-gnu-as --with-gnu-ld --with-linker-hash-style=gnu --with-long-double-128 --with-ppl --with-slibdir=/lib64 --without-system-libunwind --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --e

nable-libstdcxx-threads --enable-libstdcxx-time=rt
--enable-libstdcxx-visibility --enable-symvers=gnu
--with-gxx-include-dir=/usr/include/c++/4.7.2 --disable-gconf-peer
--enable-gtk-cairo --enable-java-awt=xlib,gtk --enable-jni
--enable-libgcj --enable-libgcj-multifile --enable-libgcj-database
--disable-libjava-multilib --enable-static-libjava --enable-xmlj
--with-pkgversion=PLD-Linux --with-bugurl=http://bugs.pld-linux.org
x86_64-pld-linux
> Thread model: posix
> gcc version 4.7.2 20120920 (release) (PLD-Linux)
> It's not prerelease
> boost-1.51.0-5.x86_64
> Builded revision 3261 with attached patch is affected with "no cutout" bug.
> Also it's nessary to cut ^r Windows endline bonus:
> sed -i -r "s/\r$//g" \
> include/boost/polygon/polygon_90_set_data.hpp
> Maybe I'm on wrong way ? I have not alternative to gcc-4.7 in my prefered distro...
>
> ** Patch added: "kicad-gcc-4.7.patch"
> https://bugs.launchpad.net/kicad/+bug/1056926/+attachment/3389624/+files/kicad-gcc-4.7.patch
>
Is your distro building KiCad with the version of Boost included in the
KiCad source or the native version installed by your distro? You can
check this by looking at the KiCad source that your distro uses and
seeing if the following lines are uncommented in the main CMakeList.txt
file:

#find_package(Boost 1.36 QUIET)
#check_find_package_result(Boost_FOUND "Boost")

If these lines have been uncommented, then you are using the version of
Boost installed on you distro. Otherwise, you are using the version
that is included with the KiCad source that your distro used to build KiCad.

If your distro is building with a version of Boost newer that 1.49 ( the
current version in the testing branch of KiCad ), then that could be a
problem and you could try build KiCad with the version of Boost in the
KiCad source. If your using the version of Boost in the KiCad source,
try uncommenting the lines above and rebuild w...

[jean-pierre charras (jp-charras)]

Le 09/10/2012 18:56, Wayne Stambaugh a écrit :
> If your distro is building with a version of Boost newer that 1.49 ( the
> current version in the testing branch of KiCad ), then that could be a
> problem and you could try build KiCad with the version of Boost in the
> KiCad source. If your using the version of Boost in the KiCad source,
> try uncommenting the lines above and rebuild with a newer version of
> Boost. I cannot guarantee this will work as it's been a long time since
> I've tried building KiCad using and external Boost version.
>

I tested and used BOOST 1.50 and 1.51 with no problem (under mingw + gcc 4.6 and Ubuntu 1.10)
(However I did not tested the 64 bits version).
So the problem is tricky.

--
Jean-Pierre CHARRAS

[Dick Hollenbeck (dickelbeck)]

On 10/09/2012 11:20 AM, LordBlick wrote:
> My problem is that simplificity is not possible in my project,

I was asking you to create a new simple board, as simple as possible which exhibits the
problem.

I had assumed that you wanted to be part of the community and invest a little time in
helping the developers help you.

If you cannot see past your problem and invest in a community/team effort to improve
KiCad, then your response makes sense.

[LordBlick (lordblick)]

Indeed I'm trying to build stable and fully functional revision 3261 by myself spec. Building with the previously mentioned patch goes with only that bug, but patch apply the included in KiCAD boost.
Uncomenting boost stuff in Cmake conf does nothing, cause first in search path is project tree. To build with newer boost it's nessary to locally remove source subtree include/boost.
Jean-P. C., should you quote your cmake and make calls to build with boost-1.50/1.51 ? Did you try it with gcc 4.7 ?

[Wayne Stambaugh (stambaughw)]

On 10/9/2012 1:35 PM, jean-pierre charras wrote:
> Le 09/10/2012 18:56, Wayne Stambaugh a écrit :
>> If your distro is building with a version of Boost newer that 1.49 ( the
>> current version in the testing branch of KiCad ), then that could be a
>> problem and you could try build KiCad with the version of Boost in the
>> KiCad source. If your using the version of Boost in the KiCad source,
>> try uncommenting the lines above and rebuild with a newer version of
>> Boost. I cannot guarantee this will work as it's been a long time since
>> I've tried building KiCad using and external Boost version.
>>
>
> I tested and used BOOST 1.50 and 1.51 with no problem (under mingw + gcc 4.6 and Ubuntu 1.10)
> (However I did not tested the 64 bits version).
> So the problem is tricky.
>
>
I may have just stumbled on to something that is related to this
problem. I just tried to duplicate this error using the MinGW32 build
on Windows 7 and have run into some odd zone editor behavior. I created
a zone with a small cut out and everything appeared to work fine. So I
deleted the zone and the cut out and created another zone without a
cutout. Now when I attempt to edit the new stand alone zone, Pcbnew
always shows the keep out dialog instead of the zone dialog. Is it
possible that your zone types are getting mixed up? If so, could this
be related to the filling problem described in this bug report?

[LordBlick (lordblick)]

W odpowiedzi na wiadomość z dnia 09.10.2012 20:02, od Dick Hollenbeck:
> On 10/09/2012 11:20 AM, LordBlick wrote:
>> My problem is that simplificity is not possible in my project,
>
> I was asking you to create a new simple board, as simple as possible
> which exhibits the problem.
OK, I didn't understand your ask. Asked file in attachment.
--
Best Regards,
Lord Blick

[Wayne Stambaugh (stambaughw)]

On 10/9/2012 1:35 PM, jean-pierre charras wrote:
> Le 09/10/2012 18:56, Wayne Stambaugh a écrit :
>> If your distro is building with a version of Boost newer that 1.49 ( the
>> current version in the testing branch of KiCad ), then that could be a
>> problem and you could try build KiCad with the version of Boost in the
>> KiCad source. If your using the version of Boost in the KiCad source,
>> try uncommenting the lines above and rebuild with a newer version of
>> Boost. I cannot guarantee this will work as it's been a long time since
>> I've tried building KiCad using and external Boost version.
>>
>
> I tested and used BOOST 1.50 and 1.51 with no problem (under mingw + gcc 4.6 and Ubuntu 1.10)
> (However I did not tested the 64 bits version).
> So the problem is tricky.
>
>
Thanks for the heads up. I saw several different versions of Boost
reported in this thread and I was beginning to think that it might be
related to distros using the native version instead of the KiCad version
of Boost.

I have just duplicated this problem on MinGW32 using GCC 4.7.0 so it
appears to be GCC version dependent. I also saw a dialog box flash up
and disappear before I could read it. Please tell me we are not using
those insane self dismissing message boxes again. I thought I rooted
all of those out of KiCad. I have attached the board file that causes
the problem. I doesn't get much more simple than this. There is not
even a net list imported into the board. Just a board outline, the
zone, and the zone cut out.

Here is the build information:

Application: Pcbnew
Version: (2012-10-08 BZR 3759)-testing
Build: wxWidgets 2.9.3 (wchar_t,compiler with C++ ABI 1002,GCC 4.7.0,wx
containers,compatible with 2.8)
Platform: Windows 7 (build 7601, Service Pack 1), 64-bit edition, 64
bit, Little endian, wxMSW
Boost version: 1.49.0
Options: USE_PCBNEW_SEXPR_FILE_FORMAT=OFF
          USE_PCBNEW_NANOMETRES=OFF
          USE_PCBNEW_SEXPR_FOOTPRINT_LIBS=OFF
          KICAD_GOST=OFF
          USE_WX_GRAPHICS_CONTEXT=OFF
          USE_WX_OVERLAY=OFF
          USE_BOOST_POLYGON_LIBRARY
          KICAD_SCRIPTING=OFF

I'm running the 64 bit version of Debian Testing at home where the
default version of GCC is 4.7.1. I'll see if I can duplicate the error
with the default version of Boost.

[jean-pierre charras (jp-charras)]

Le 09/10/2012 20:52, Wayne Stambaugh a écrit :
> On 10/9/2012 1:35 PM, jean-pierre charras wrote:
>> Le 09/10/2012 18:56, Wayne Stambaugh a écrit :
>>> If your distro is building with a version of Boost newer that 1.49 ( the
>>> current version in the testing branch of KiCad ), then that could be a
>>> problem and you could try build KiCad with the version of Boost in the
>>> KiCad source. If your using the version of Boost in the KiCad source,
>>> try uncommenting the lines above and rebuild with a newer version of
>>> Boost. I cannot guarantee this will work as it's been a long time since
>>> I've tried building KiCad using and external Boost version.
>>>
>>
>> I tested and used BOOST 1.50 and 1.51 with no problem (under mingw + gcc 4.6 and Ubuntu 1.10)
>> (However I did not tested the 64 bits version).
>> So the problem is tricky.
>>
>>
> Thanks for the heads up. I saw several different versions of Boost
> reported in this thread and I was beginning to think that it might be
> related to distros using the native version instead of the KiCad version
> of Boost.
>
> I have just duplicated this problem on MinGW32 using GCC 4.7.0 so it
> appears to be GCC version dependent. I also saw a dialog box flash up
> and disappear before I could read it. Please tell me we are not using
> those insane self dismissing message boxes again. I thought I rooted
> all of those out of KiCad. I have attached the board file that causes
> the problem. I doesn't get much more simple than this. There is not
> even a net list imported into the board. Just a board outline, the
> zone, and the zone cut out.
>
> Here is the build information:
>
> Application: Pcbnew
> Version: (2012-10-08 BZR 3759)-testing
> Build: wxWidgets 2.9.3 (wchar_t,compiler with C++ ABI 1002,GCC 4.7.0,wx
> containers,compatible with 2.8)
> Platform: Windows 7 (build 7601, Service Pack 1), 64-bit edition, 64
> bit, Little endian, wxMSW
> Boost version: 1.49.0
> Options: USE_PCBNEW_SEXPR_FILE_FORMAT=OFF
> USE_PCBNEW_NANOMETRES=OFF
> USE_PCBNEW_SEXPR_FOOTPRINT_LIBS=OFF
> KICAD_GOST=OFF
> USE_WX_GRAPHICS_CONTEXT=OFF
> USE_WX_OVERLAY=OFF
> USE_BOOST_POLYGON_LIBRARY
> KICAD_SCRIPTING=OFF
>
> I'm running the 64 bit version of Debian Testing at home where the
> default version of GCC is 4.7.1. I'll see if I can duplicate the error
> with the default version of Boost.
>
>
> ** Attachment added: "zone-cutuout-test-empty-ne.brd"
> https://bugs.launchpad.net/bugs/1056926/+attachment/3390576/+files/zone-cutuout-test-empty-ne.brd
>

I'll be away these next 3 days, so I can't work on this issue.

For the flashing dialog, it could be the dialog which shows the progression of the zone filling.
(which is dismissed at the end of calculations).

There are 2 reasons for this dialog:
- Large boards take a while to fill zones:
   30 sec to 1 minute witch some of my boards
   (one has more than 5400 pads and 30000 tracks and vias, and 120 zones),
   so the activity report has some interest.
- but mainly, for an obscure reason I never be able to fix (under Windows),
   without this display, the screen become white after a delay,...

[jean-pierre charras (jp-charras)]

I had a look to this issue.

Gcc 4.7 has certainly a more efficiency optimization that breaks at least one function
in boost::polygon.
Polygon inflate operation is fully broken, when using -O2 optimization level.

A workaround is to used a less aggressive optimization:
currently optimization is -O2, but using -O1 fixes this issue (under mingw + gcc 4.7.0),
and does not changes many things in Pcbnew (I made some tests which show only 1% calculation time slower).

So: Edit the main CMAkeLists.txt, and modify CMAKE_CXX_FLAGS_RELEASE and CMAKE_C_FLAGS_RELEASE
options to use -O1 instead of -O2 optimization level, and see if this issue is also fixed under ArchLinux.

Others issues in boost::polygon seem fixed in 1.52 version (still a beta version), but not this issue.

--
Jean-Pierre CHARRAS

[Sebastian Schumb (longhairedhacker)]

I've just tested some of my boards with the Archlinux package, that I've rebuild using -O1.

As far as I can tell it seems to 'fix' the problem.

[Fabio Varesano (fabio-varesano)]

Still broken in gcc 4.7.2 on Archlinux as of today. Note that the workaround above will be enabled if you compile Kicad as release, but if you compile it as development edition, then you'll see the bug since the hack won't be enabled.

[Nick Østergaard (nickoe)]

I can confirm this behaivour on arhclinux with gcc 4.9.2. But I have a PCB that I made a few months ago where I have used it, here the keepout do work.

Version: (2014-11-27 BZR 5304)-kicad Release build
wxWidgets: Version 3.0.2 (debug,wchar_t,compiler with C++ ABI 1002,GCC 4.9.2,wx containers,compatible with 2.8)
Platform: Linux 3.17.4-1-ARCH x86_64, 64 bit, Little endian, wxGTK
Boost version: 1.57.0
         USE_WX_GRAPHICS_CONTEXT=OFF
         USE_WX_OVERLAY=OFF
         KICAD_SCRIPTING=ON
         KICAD_SCRIPTING_MODULES=ON
         KICAD_SCRIPTING_WXPYTHON=ON
         USE_FP_LIB_TABLE=HARD_CODED_ON
         BUILD_GITHUB_PLUGIN=ON

[LordBlick (lordblick)]

Made some test with https://svn.boost.org/trac/boost/ticket/7983 - all positive, so the reason lies else other…
$ x86_64-pld-linux-g++ -O0 test_polygon_diff.cpp -o testpoly
$ x86_64-pld-linux-g++ -O1 test_polygon_diff.cpp -o testpoly1
$ x86_64-pld-linux-g++ -O2 test_polygon_diff.cpp -o testpoly2
$ x86_64-pld-linux-g++ -O3 test_polygon_diff.cpp -o testpoly3
$ x86_64-pld-linux-g++ -Os test_polygon_diff.cpp -o testpolys
$ ls -ln testpoly*
-rwx------ 1 1000 1000 659K 11-29 02:06 testpoly*
-rwx------ 1 1000 1000 156K 11-29 02:07 testpoly1*
-rwx------ 1 1000 1000 152K 11-29 02:07 testpoly2*
-rwx------ 1 1000 1000 151K 11-29 02:07 testpoly3*
-rwx------ 1 1000 1000 123K 11-29 02:08 testpolys*
$ ./testpoly
// polyset polygons count 1
**** polygon 0, corners count 12
  10, 10
  5, 10
  5, 5
  5, -5
  -5, -5
  -5, 5
  5, 5
  5, 10
  -10, 10
  -10, -10
  10, -10
  10, 10
$ ./testpoly1
// polyset polygons count 1
**** polygon 0, corners count 12
  10, 10
  5, 10
  5, 5
  5, -5
  -5, -5
  -5, 5
  5, 5
  5, 10
  -10, 10
  -10, -10
  10, -10
  10, 10
$ ./testpoly2
// polyset polygons count 1
**** polygon 0, corners count 12
  10, 10
  5, 10
  5, 5
  5, -5
  -5, -5
  -5, 5
  5, 5
  5, 10
  -10, 10
  -10, -10
  10, -10
  10, 10
$ ./testpoly3
// polyset polygons count 1
**** polygon 0, corners count 12
  10, 10
  5, 10
  5, 5
  5, -5
  -5, -5
  -5, 5
  5, 5
  5, 10
  -10, 10
  -10, -10
  10, -10
  10, 10
$ ./testpolys
// polyset polygons count 1
**** polygon 0, corners count 12
  10, 10
  5, 10
  5, 5
  5, -5
  -5, -5
  -5, 5
  5, 5
  5, 10
  -10, 10
  -10, -10
  10, -10
  10, 10
Version: (2014-jul-16 BZR unknown)-BZR5304 Release build
wxWidgets: Version 3.0.1 (release,wchar_t,compiler with C++ ABI 1002,GCC 4.8.3,wx containers,compatible with 2.8)
Platform: Linux 3… x86_64, 64 bit, Little endian, wxGTK
Boost version: 1.57.0
         USE_WX_GRAPHICS_CONTEXT=OFF
         USE_WX_OVERLAY=OFF
         KICAD_SCRIPTING=ON
         KICAD_SCRIPTING_MODULES=ON
         KICAD_SCRIPTING_WXPYTHON=ON
         USE_FP_LIB_TABLE=HARD_CODED_ON
         BUILD_GITHUB_PLUGIN=OFF

[LordBlick (lordblick)]

Embeded boost v1.54 works fine, but it's strange to use so old software with many patches.
Application: kicad
Version: (2014-jul-16 BZR unknown)-BZR5304 Release build
wxWidgets: Version 3.0.1 (release,wchar_t,compiler with C++ ABI 1002,GCC 4.8.3,wx containers,compatible with 2.8)
Platform: Linux 3.… x86_64, 64 bit, Little endian, wxGTK
Boost version: 1.54.0
         USE_WX_GRAPHICS_CONTEXT=OFF
         USE_WX_OVERLAY=OFF
         KICAD_SCRIPTING=ON
         KICAD_SCRIPTING_MODULES=ON
         KICAD_SCRIPTING_WXPYTHON=ON
         USE_FP_LIB_TABLE=HARD_CODED_ON
         BUILD_GITHUB_PLUGIN=OFF

[jean-pierre charras (jp-charras)]

Is the test file zone-cutuout-test-empty-ne.brd exhibit this issue ?
If no, can you send us a board file which shows this issue?

[Nick Østergaard (nickoe)]

@Jean-Pierre, yes that is the file I tested, which shows the bug. The other board I have where ot works I will need to simplify to narrow down the issue.

[Wayne Stambaugh (stambaughw)]

On 11/29/2014 2:28 AM, jean-pierre charras wrote:
> Is the test file zone-cutuout-test-empty-ne.brd exhibit this issue ?
> If no, can you send us a board file which shows this issue?
>
I just tested this file on my 64 bit mingw build and it fails with Boost
1.57. Below is the build information.

Application: pcbnew
Version: (2014-11-29 BZR 5307)-product Debug build
wxWidgets: Version 3.0.2 (debug,wchar_t,compiler with C++ ABI 1002,GCC
4.9.2,wx containers,compatible with 2.8)
Platform: Windows 8 (build 9200), 64-bit edition, 64 bit, Little endian,
wxMSW
Boost version: 1.57.0
         USE_WX_GRAPHICS_CONTEXT=OFF
         USE_WX_OVERLAY=OFF
         KICAD_SCRIPTING=ON
         KICAD_SCRIPTING_MODULES=ON
         KICAD_SCRIPTING_WXPYTHON=ON
         USE_FP_LIB_TABLE=HARD_CODED_ON
         BUILD_GITHUB_PLUGIN=ON

Interestingly when I load the board in my 32 bit mingw build with the
custom Boost 1.54, the zone cut out is filled in until I refill the
zone. Then it is displayed correctly. Refilling does not work on my
Boost 1.57 build. I don't know if this information is of any use or
not. Here is my 32 bit build information.

Application: kicad
Version: (2014-11-26 BZR 5302)-product Release build
wxWidgets: Version 3.0.2 (debug,wchar_t,compiler with C++ ABI 1002,GCC
4.7.2,wx containers,compatible with 2.8)
Platform: Windows 8 (build 9200), 64-bit edition, 64 bit, Little endian,
wxMSW
Boost version: 1.54.0
         USE_WX_GRAPHICS_CONTEXT=OFF
         USE_WX_OVERLAY=OFF
         KICAD_SCRIPTING=OFF
         KICAD_SCRIPTING_MODULES=OFF
         KICAD_SCRIPTING_WXPYTHON=OFF
         USE_FP_LIB_TABLE=HARD_CODED_ON
         BUILD_GITHUB_PLUGIN=ON

[LordBlick (lordblick)]

So we have proof that is not platform dependend.
Maybe some new feature ?
http://www.boost.org/doc/libs/1_57_0/libs/polygon/doc/index.htm

[LordBlick (lordblick)]

The longest well I worked on version 1.55. 1.56/1.57 seems to be incompatible with present area fill code.
http://www.boost.org/users/news/

[jean-pierre charras (jp-charras)]

Looks like the inflate/deflate polygon function is now broken.
It works for basic shapes, but not for all shapes.
Inflate/deflate polygon function is used in zone filling algorithms, and also to create solder mask when the min width is not 0 in Gerber files.

[LordBlick (lordblick)]

If cutout rectangle in rectange is simple shape, then cut out doesn't work too. The code is not broken, but outdated relative to boost. One thing is for check - does upgrade embeded boost from boost_1_54_0.tar.bz2 to boost_1_57_0.tar.bz2 with removing rejected patches from patches/boost_*.path helps or not…

[jean-pierre charras (jp-charras)]

Cutout rectangle in rectangle is *not* a simple shape.
It is a non convex polygon.

Try to draw this kind of shape with a pencil using only *one* polygon, and your could easily seen it is a complex shape.

Still, inflate/deflate polygon function (needed in zone calculations) seems broken with these polygons in 1.57

[Wayne Stambaugh (stambaughw)]

On 11/29/2014 2:09 PM, jean-pierre charras wrote:
> Cutout rectangle in rectangle is *not* a simple shape.
> It is a non convex polygon.
>
> Try to draw this kind of shape with a pencil using only *one* polygon,
> and your could easily seen it is a complex shape.
>
> Still, inflate/deflate polygon function (needed in zone calculations)
> seems broken with these polygons in 1.57
>
I'm beginning to wonder if we should use a different geometry library or
possibly write our own. Between this and the context library issues,
keeping up with the Boost problems is getting tedious.

[LordBlick (lordblick)]

http://www.angusj.com/delphi/clipper.php ?

[LordBlick (lordblick)]

http://www.boost.org/users/history/version_1_56_0.html
[…]
Geometry:
Additional functionality
New algorithm buffer for inflating/deflating geometries (buffer itself already existed but that was only to enlarge a box)
New algorithm remove_spikes, algorithm to remove spikes from a ring, polygon or multi_polygon.
New algorithm point_on_surface, generating a point lying on the surface (interior) of the polygon
New algorithm is_simple, returning true if a geometry is simple according to the OGC standard
New algorithm is_valid, returning true if a geometry is valid according to the OGC standard
New algorithm crosses for checking this spatial relation according to the OGC standard
The set operation algorithms (difference, intersection, sym_difference and union_) now support as input pairs of pointlike or linear geometries
The distance and comparable_distance algorithms now support all pairs of geometry combinations
The spatial relations which didn't support it (covered_by, touches, within, etc.) now support as input linear and/or areal geometries
The support for boost::variants as input geometries in various algorithms
The rtree support for indexing segments
The rtree nearest() predicate support for arbitrary geometries
Solved tickets
8310 Wrong results with overlapping polygons (fixed using point_on_surface for disjoint)
8375 sym_difference of non-closed polygons returns closed polygon
8376 difference of non-closed polygons returns closed polygon
9081 Booleans create self-intersecting polygons from non-self-intersecting polygons
9245 Check for process errors in make_qbk.py
9563 (Sym)difference not successful, fixed by rescaling to robust type
9628 Wrong result of within() due to the winding strategy not working correctly for nearly-horizontal segments
9871 Remove spike in polygon with only a spike
9947 Missing info about WKT in documentation
9759 Invalid results of R-tree knn queries for non-cartesian coordinate systems
10019 Difference of Linestring and Box returns their intersection
10077 Wrong types in concept checks in boost/geometry/arithmetic/arithmetic.hpp
[…]
http://www.boost.org/users/history/version_1_57_0.html :
Geometry:
Improvements
The support of parameters convertible to value_type in rtree insert(), remove() and count() functions
Solved tickets
8402 Implicit conversion warnings
9354 Bug in winding strategy affecting within() and covered_by() for non-cartesian coordinate systems
10177 Missing include
10345 Distance fails to compile for some coordinate types
10398 Wrong neighbour check in buffer, calculating turns
10421 Invalid Point-Box distance for spherical CS
10615 Rtree constructor feature request
10643 Invalid point_on_surface() result for big coordinates
10668 Implicit conversion warnings (duplicated 8402)
Bugfixes
Several fixes of bugs in algorithm buffer
Bug in point_on_surface() for CCW Polygons (extreme_points()) and numerical issue (thanks to Matt Amos)
Bug in disjoint() for A/A fixed by replacement of point_on_surface() with point_on_border() (thanks to Matt Amos)
The result of convex_hull(), duplicated Point in open output, too small number of Points for 1- and 2-Point input
Imprecision for big coordinates in centroid(),...

[LordBlick (lordblick)]

Maybe it helps:
http://www.boost.org/doc/libs/1_57_0/libs/geometry/doc/html/geometry/examples/example_source_code__adapting_a_legacy_geometry_object_model.html#adaption_of_qpolygon_source_code

[jean-pierre charras (jp-charras)]

Context library issue is our major problem.

Clipper is already in use in Kicad.

Boost::polygon is the third polygon lib we are using (after GPC, buggy and with a stupid license, and kbool, also buggy)
Boost::polygon is not easy to replace (it is fast, and still maintained).
Clipper is very useful, easy to use but not as fast as Boost::polygon
It is not yet heavily used in Kicad, so we don't really know its issues.
(Neither Clipper nor boost::polygon has all features needed in Pcbnew, we need both libs)

Only specialists can write a polygon library, fast and numerically stable. This is a very tricky task.

There is not a lot of libraries candidates.
(Algos must be fast, numerically stable, maintained and the license acceptable)
The only one possible candidate I know is CGAL, but I never used it.
We don't know if the polygon lib has more or less bugs than boost.

Changing a polygon library is possible but not easy.
And be sure there are less bug than boost is also not easy:
the first annoying bug found using boost was found more than one year after releasing Pcbnew with boost.
(Bug not fixed, and which could be due to a numerical instability)

[jean-pierre charras (jp-charras)]

In rev: 5308 I modified the way Inflate/deflate polygon is made in zone calculations.
Inflate/deflate polygons does not work very well (neither with boost::polygon >= 1.56 nor with Clipper) for polygons which have holes linked by overlapping segments, i.e. polygons with holes which can be drawn, because they are see as only one polygon.
It is hard to say if this is really a bug.

Now, Inflate/deflate functions are applied only to usual polygons.

Can you try it (I could have missed a code which still uses inflate/deflate for polygons having linked holes somewhere)

[Nick Østergaard (nickoe)]

Sorry for the late response, but testing with the zone-cutuout-test-empty-ne.brd file. I get the following behaivour.

On 5307 with boost 1.57.
When I open the file, the cutout is filled, that is non empty as expected. I can add a _keepout_ including the copper areas, which will make a hole in the copper, but the _cutout_ which is added with the normal zone tool, by right clicking the zone and going to Zone -> Add Cutout Area , will not be filled.

On 5308 with boost 1.57.
Here the _cutout_ seem to work just fine (remeber to refill when adding a cutout or to see the original one).

So Jean-Pierre your commit in 5308 seems to fix this issue at my end again.

I guess this can be marked as fix comitted again, but I will wait for LordBlick to answer also.

[Nick Østergaard (nickoe)]

https://lists.launchpad.net/kicad-developers/msg15972.html