Updated compilation environment on Windows.

We have completely recreated our Win64 build environment, and rely now on recent versions of g++ & 3rd-party libs. We are interested by your feedback on possible speed improvements.
Want to test new installer ?

1 Like

Is Krita version available? I do not use GIMP.

Yes Krita version is here: https://gmic.eu/files/prerelease/gmic_krita_win64.zip

A few words about the technical changes, in comparison to the binaries I was providing before (for Windows) :

  • g++ version has been updated from version 7 to version 10.
  • This now allows to enable the -flto optimization flag (LTO=Link-Time Optimization), which is supposed to optimize the generated binary even more.

I wrote a short section on the G’MIC Download page, to explain all the steps required to compile G’MIC executables on Windows:

:arrow_forward: https://gmic.eu/download.shtml#source_windows

Let me know, if you encounter issues while trying to compile.

I tried your windows build procedure.
All is ok until link:
C:/msys64/mingw64/bin/…/lib/gcc/x86_64-w64-mingw32/10.2.0/…/…/…/…/x86_64-w64-mingw32/bin/ld.exe: cannot find -lfftw3_threads

I have a remark: when you install MSYS2, you get two shells: MSYS2 shell that should be used only for MSYS2 updating and Mingw64 shell that permits to build applications by providing the necessary environment. I don’t see the distinction in your procedure.

fftw3_threads is actually not used in Windows, only used in Linux.
It shouldn’t tell you you need it (if you look at the Makefile or the qmake, this is enabled only for Linux).

I use the Mingw64 shell for all steps, this didn’t make any difference for installing required packages.

Only had tested it a few, not rigorously. I think there might be a speed improvement on the Krita G’MIC-QT (I tested with Thorn Fractal, and Attractor as well MadJik Newton Fractal). I will get back to you once this test ( Render 10x sublevel Thorn Fractal on a 8192x8192 image with max iterations of 255. Which means 6,710,886,400 loops and cpu usage of 27000 MB ) finishes.

Stylize has a different behavior, it does not work, however it crash instead of doing nothing in the end.

EDIT: I do not think there is drastic speed improvement. At most, it’s pretty mild after running it.

@David_Tschumperle I don’t have the resources or time to compile. Would you mind building and uploading the standalone? I would like to give it a try. Thanks!

You can find it here : https://gmic.eu/files/prerelease/gmic_qt_win64.zip

Under MSYS2 or mingw shell:
$ uname

$ echo $OS

So I think that the test permitting to require fftw3_threads is true.

That was a mistake I’ve fixed, but only in the develop branch, my fault.
This should be now fixed in master as well.

Thanks it is ok now

I know the preferred way to compile is using MinGW/g++ on Windows, but just for the sake of it, I also tried Visual Studio, with versions from VS2012 up to the latest VS2019, and while this was never a problem in the past (aside from the template optimisation issue of course), with the latest G’MIC sources it will no longer compile due to “invalid template function initialisation”. This can be fixed by removing the default parameters for two functions, then it will compile again also under Visual Studio. Just wanted to let you know about that, let me know if you need any specific info on what I changed or if you want to keep it as it is.

Interested by this. I’ll try compiling with MSVC this afternoon, but if you already know what to change, that would save me some time !

In gmic.h on line 269:
gmic(const char *const commands_line,
const char *const custom_commands=0,
const bool include_stdlib=true,
float *const p_progress=0, bool *const p_is_abort=0,
const T& pixel_type=(T)0);

error C4519: default template arguments are only allowed on a class template

In gmic.h on line 282:
gmic& run(const char *const commands_line,
float *const p_progress=0, bool *const p_is_abort=0,
const T& pixel_type=(T)0);

error C4519: default template arguments are only allowed on a class template

Now the error above only happens with VS2012, since the first C++11 standard iteration did indeed not allow default template arguments for template functions, only class templates (there was seen no need to allow this). Fortunately, VS2012 has an unsupported feature by adding “4519” in the project property settings under “C/C++ - Advanced - Disable Specific Warnings” that makes this error go away, even though it is an error and not a warning.

The other error is however still happening with latest C++ compilers like VS2019 or the Intel C++ compiler:
In gmic.cpp on line 15163:
template CImg& CImg::assign(const unsigned int size_x, const unsigned int size_y=1,
const unsigned int size_z=1, const unsigned int size_c=1); \

error C2572: ‘cimg_library::CImg::assign’ : redefinition of default parameter : parameter 4
error C2572: ‘cimg_library::CImg::assign’ : redefinition of default parameter : parameter 3
error C2572: ‘cimg_library::CImg::assign’ : redefinition of default parameter : parameter 2

Here I just removed the three default parameters from line 15163 in the assign functions and it still seems to work fine.

Ha interesting, thanks. What I propose then is to remove the value of the default template parameter. I really prefer to no use “recent” C++ features if the code can still compile on older compilers.

Seems legit indeed. I’ll remove them too.

I’ve made the changes in the ‘develop’ branch of the git repo.
Couldn’t test on my Windows, as my version of MSVC 2019 was a trial, and date is expired :frowning:

@Tobias_Fleischer, about the information missing in the JSON feature. What do you need and what is your proposal to add them ?
I can change the parse_cli_json to add these info.

According to the description of parse_gui, it seems the info is already available and just needs to be put in the output string for JSON.
I think the following data makes sense to include in the JSON:
$_fF_commandpreview: Filter preview command
And for each parameter:
$_fF_pP_visibility: Parameter visibility