The "key" difference between cygwin and mingw is the "OS API" they expose to your code - cygwin uses it's DLLs to wrap up various services (e.g. threads, fork, etc) so that they appear "Posix-like", the idea being to allow *nix code to be compiled for Windows "as-is".
The mingw tools expose the Win32 APIs instead, in effect emulating what MS own tools do.
So... If you have only used fltk-isms in your code, it should Just Compile Anywhere, and all is well, cygwin and mingw and VS become "equivalent" at that point.
If you have used any (platform specific) Posix-like features in your code, then cygwin may still be your best bet - the alternative is to #ifdef around the portability issues and drop in the equivalent (but inevitably different) MS feature.
That cygwin emulation costs you a bit (from my experience, it was this emulation layer that impacted performance, though the hit was not that great and would likely not matter in many cases.) It also ties you to the cygwin DLL's, and my experiences with that have not been stellar.
(Things may be better now, but there was a time when many dev tools were being ported from *nix to Windows, and using cygwin. Some ports were well behaved and put their copy of the DLL in a private place, others scattered the DLL around in system folders. Chaos often ensued. I was often unhappy...)
The mingw-cross tools under Linux might be your path of least resistance then? Just build on your Linux host but cross-compiling for Windows. Means you can just use the environment you are familiar with and so on.
Or if you want a "native" Windows setup and mingw is OK for your use-case, I'd probably go for Msys2 (which provides a bash-like shell on Windows) and then use their package manager to install the various tools you are familiar with, but on the Windows machine.