Welcome to Fractal Forums

Fractal Software => Kalles Fraktaler => Topic started by: claude on March 05, 2017, 12:58:26 PM

Title: compiling Kalles Fraktaler with mingw
Post by: claude on March 05, 2017, 12:58:26 PM

I finally managed to cross-compile Kalles Fraktaler 2.9.3 with mingw64 on Linux (Debian Stretch). I uploaded a git repository with my modifications here: https://code.mathr.co.uk/kalles-fraktaler-2

Unfortunately it's about 50% slower than the binary of 2.9.4 from the upstream site, at least in one benchmark (which was quite heavy on the reference computations, light on per-pixel iterations).

EDIT I made a simple page about this project with downloads of binaries and sources, and compilation instrucctions, benchmarks, etc: https://mathr.co.uk/kf/kf.html

Title: Re: compiling kf 2.9.3 with mingw64
Post by: zebastian on March 05, 2017, 02:05:59 PM

hi claude,

well done! you may try to use
-msse2 -ffast-math
as additional cxx flags in the makefile: https://code.mathr.co.uk/kalles-fraktaler-2/blob/81653f04efbad9ff34f08d9af7dc721c55707cc5:/Makefile
These are more aggressive performance steps which will
- take longer to compile
- produce bigger binaries
- make the binary bound to the CPU you are running on
+ But the runtime will be much better.
When i am compiling Mandelbulber on my machine for rendering i use these flags to compile a "production" binary.

Title: Re: compiling kf 2.9.3 with mingw64
Post by: Kalles Fraktaler on March 06, 2017, 12:37:44 AM

Excellent achievement claude! :joy:

I guess the hardest point was the CFixedFloat class, in which I heavily relied on MSVC perhaps non-standard non-strict overloaded functions?

I have some issues uploading the latest code, but will do as soon as the issues are solved :)

Title: Re: compiling kf 2.9.3 with mingw64
Post by: Kalles Fraktaler on March 07, 2017, 12:08:56 PM

I have uploaded the lastest code on http://www.chillheimer.de/kallesfraktaler/
Direct link: http://www.chillheimer.de/kallesfraktaler/fractal_src_2.11.1.zip

Title: Re: compiling kf 2.9.3 with mingw64
Post by: claude on March 07, 2017, 08:14:27 PM

Major thanks for the updated code - lots of changes!

But there is a small problem, the sources for the ldbl64.dll are out of date, 2014 in my file listing, and the resulting compiled dll is incompatible with the main program...

Anyway, I've been hacking away, here's source:

https://code.mathr.co.uk/kalles-fraktaler-2

this branch tracks kalles source zips, no changes
https://code.mathr.co.uk/kalles-fraktaler-2/shortlog/refs/heads/master

this branch makes kalles source compileable with mingw, plus some bug fixes
https://code.mathr.co.uk/kalles-fraktaler-2/shortlog/refs/heads/claude
(the 2.11.1 zip commit is mislabeled as 2.9.3, oops)

this branch allows building with GMP mpf_t or MPFR mpfr_t instead of custom code - in my benchmarks mpf_t is faster at deeper zooms (e1000 or so), plus less code to maintain
https://code.mathr.co.uk/kalles-fraktaler-2/shortlog/refs/heads/claude-gmp
(the 2.11.1 zip commit is mislabeled as 2.9.3, oops)
no instructions yet on how to install GMP for usage by mingw, possibly mightymandel has some relevant docs; also the C++ bindings from boost::multiprecision are needed, that can just be unpacked and symlinked so that the C++ #include find the right files..

here are some binaries (64bit, tested in wine on linux):

first version forked from 2.9.3, mostly working fine in my tests (just regular mandelbrot so far):
https://mathr.co.uk/mandelbrot/kf-2.9.3%2Bgmp.20170307.zip
https://mathr.co.uk/mandelbrot/kf-2.9.3%2Bgmp.20170307.zip.sig

second version forked from 2.11.1, crashes if long double is needed (workaround is to menu -> special -> use floatexp always), not tested as much:
https://mathr.co.uk/mandelbrot/kf-2.11.1%2Bgmp.20170307.zip
https://mathr.co.uk/mandelbrot/kf-2.11.1%2Bgmp.20170307.zip.sig

both binaries have corresponding tags in the git repository, so you can find out which sources were used

some crude timing results:

Code:

benchmarks              upstream exes   cross-mingw 2.9.3 fork  additional notes
                        2.9.4   2.11.1  custom  gmp     mpfr    zoom    delta type
evolution-of-trees.kfr  3:58.7  3:43.3  6:10.3  4:16.7  4:41.6  e227    double
Ssssssssss.kfr          7.537   8.363   9.041   6.605   6.731   e533    scaled double
e1000.kfr w/  dll       7.279   7.370   8.674   6.343   6.510   e1000   long double
e1000.kfr w/o dll       7.752   7.905   fail    6.737   6.782   e1000   floatexp
glitch33.kfr w/  dll    9.483   9.551   11.170  7.448   7.691   e1277   long double
glitch33.kfr w/o dll    10.112  10.185  fail    7.982   8.033   e1277   floatexp

Title: Re: compiling kf 2.9.3 with mingw64
Post by: Kalles Fraktaler on March 07, 2017, 08:48:52 PM

Thanks claude
Yes you are right it was an old version, sorry for that.
I have updated fractal_src_2.11.1.zip on the site, and if there is a cache problem, I uploaded it separately as well, http://www.chillheimer.de/kallesfraktaler/ldbl.cpp

Will your changes make it possible to compile the whole program in gcc now?
If so, no need to put ldbl in a separate dll, because the reason for that is that I compile ldbl with gcc.

Looks like some locations you tested are faster with gmp/mpfr!? :)

Title: Re: compiling kf 2.9.3 with mingw64
Post by: claude on March 08, 2017, 05:10:27 PM

Quote from: Kalles Fraktaler on March 07, 2017, 08:48:52 PM

Thanks for the code.

Yes it can all be compiled with gcc now, so it could be merged without a separate dll.

I haven't got Windows to test compiling there, but mingw/msys might be able to do it with appropriate changes to the Makefile.

GMP and MPFR are faster at higher precisions, it seems.

Title: Re: compiling kf 2.9.3 with mingw64
Post by: quaz0r on March 08, 2017, 05:24:35 PM

gmp/mpfr is explicitly vectorized, which shows the most noticeable performance boost with larger mantissas

Title: Re: compiling kf 2.9.3 with mingw64
Post by: claude on March 13, 2017, 05:24:05 AM

some small changes in my claude-gmp branch:

* fixed the crash at long double (which turned out to be a stack overflow) by increasing stack size to 64MB (from 32MB)
* long double code updated to kalles upstream
* compiled into one exe, no need for separate dll for long double any more
* no -msse2 (should be enabled by default on x86_64/amd64 anyway)
* no -march=native (not suitable for distributing binaries)
* does use -ffast-math, though I didn't benchmark its effect

fresh binary:
https://mathr.co.uk/mandelbrot/kf-2.11.1%2Bgmp.20170313.zip
https://mathr.co.uk/mandelbrot/kf-2.11.1%2Bgmp.20170313.zip.sig

additional benchmarks:
* Newton-Raphson zooming is significantly faster with GMP: zooming into center pixel of glitch33.kfr (e1277) calculates new location in 18 seconds as opposed to over 4 minutes with kf-2.11.1
* rendering is significantly faster with GMP at deep enough zooms: Dinkydau's hyperbolic tiling pistil location (e2293, 640x360) takes 3 hours with upstream kf-2.11.1, with GMP it takes 1 hour 18 minutes, plus an additional 10 minutes if compiled to use MPFR instead of GMP.

EDITED to add: there are some warnings that are concerning with respect to 64bit safety - it seems to work, but chances are some address space layout changes could make it explode? I don't know what Microsoft Windows guarantees, but there exist functions like SetClassLongPtr which should be used instead of SetClassLong for pointers (which are 64bit on 64bit...). Here's the warning dump:

Code:

fraktal_sft/listbox.cpp: In function ‘int SubclassListProc(HWND, UINT, WPARAM, LPARAM)’:
fraktal_sft/listbox.cpp:14:62: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
   CListBox*pList = (CListBox*)GetWindowLong(hWnd,GWL_USERDATA);
                                                              ^
fraktal_sft/listbox.cpp:19:62: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
   CListBox*pList = (CListBox*)GetWindowLong(hWnd,GWL_USERDATA);
                                                              ^
fraktal_sft/listbox.cpp:24:62: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
   CListBox*pList = (CListBox*)GetWindowLong(hWnd,GWL_USERDATA);
                                                              ^
fraktal_sft/listbox.cpp:28:62: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
  return CallWindowProc((WNDPROC)GetClassLong(hWnd,GCL_WNDPROC),hWnd,uMsg,wParam,lParam);
                                                              ^
fraktal_sft/listbox.cpp: In constructor ‘CListBox::CListBox(HWND, HWND, char*, int, COLORREF, COLORREF, BOOL)’:
fraktal_sft/listbox.cpp:108:44: warning: cast from ‘CListBox*’ to ‘LONG {aka long int}’ loses precision [-fpermissive]
  SetWindowLong(m_hwList,GWL_USERDATA,(LONG)this);
                                            ^~~~
fraktal_sft/listbox.cpp:109:43: warning: cast from ‘int (*)(HWND, UINT, WPARAM, LPARAM) {aka int (*)(HWND__*, unsigned int, long long unsigned int, long long int)}’ to ‘LONG {aka long int}’ loses precision [-fpermissive]
  SetWindowLong(m_hwList,GWL_WNDPROC,(LONG)SubclassListProc);
                                           ^~~~~~~~~~~~~~~~
fraktal_sft/listbox.cpp: In constructor ‘CListBoxEdit::CListBoxEdit(HWND, HWND, HWND, HWND, HWND, HWND__**, int)’:
fraktal_sft/listbox.cpp:250:35: warning: cast from ‘HWND {aka HWND__*}’ to ‘int’ loses precision [-fpermissive]
   m_stEdits.AddInt((int)phwEdits[i]);
                                   ^
fraktal_sft/listbox.cpp: In member function ‘int CListBoxEdit::ProcessMessage(HWND, UINT, WPARAM, LPARAM)’:
fraktal_sft/listbox.cpp:259:54: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
     nLen+=GetWindowTextLength((HWND)atoi(m_stEdits[i]))+1;
                                                      ^
fraktal_sft/listbox.cpp:265:41: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
     GetClassName((HWND)atoi(m_stEdits[i]),szClass,sizeof(szClass));
                                         ^
fraktal_sft/listbox.cpp:267:46: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
      itoa(SendMessage((HWND)atoi(m_stEdits[i]),BM_GETCHECK,0,0),szTmp+strlen(szTmp),10);
                                              ^
fraktal_sft/listbox.cpp:269:44: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
      GetWindowTextA((HWND)atoi(m_stEdits[i]),szTmp+strlen(szTmp),nLen+1);
                                            ^
fraktal_sft/listbox.cpp:284:54: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
     nLen+=GetWindowTextLength((HWND)atoi(m_stEdits[i]))+1;
                                                      ^
fraktal_sft/listbox.cpp:290:41: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
     GetClassName((HWND)atoi(m_stEdits[i]),szClass,sizeof(szClass));
                                         ^
fraktal_sft/listbox.cpp:292:46: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
      itoa(SendMessage((HWND)atoi(m_stEdits[i]),BM_GETCHECK,0,0),szTmp+strlen(szTmp),10);
                                              ^
fraktal_sft/listbox.cpp:294:44: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
      GetWindowTextA((HWND)atoi(m_stEdits[i]),szTmp+strlen(szTmp),nLen+1);
                                            ^
fraktal_sft/listbox.cpp:322:42: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
      GetClassName((HWND)atoi(m_stEdits[i]),szClass,sizeof(szClass));
                                          ^
fraktal_sft/listbox.cpp:324:42: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
       SendMessage((HWND)atoi(m_stEdits[i]),BM_SETCHECK,atoi(stT[0][i+1]),0);
                                          ^
fraktal_sft/listbox.cpp:326:45: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
       SetWindowTextA((HWND)atoi(m_stEdits[i]),stT[0][i+1]);
                                             ^
fraktal_sft/main.cpp: In function ‘long int ShowProc(HWND, UINT, WPARAM, LPARAM)’:
fraktal_sft/main.cpp:754:62: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
  return CallWindowProc((WNDPROC)GetClassLong(hWnd,GCL_WNDPROC),hWnd,uMsg,lParam,wParam);
                                                              ^
fraktal_sft/main.cpp: In function ‘int CustomZoomSize(HWND, UINT, WPARAM, LPARAM)’:
fraktal_sft/main.cpp:3157:56: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
    char *szTmp = (char*)GetWindowLong(hWnd,GWL_USERDATA);
                                                        ^
fraktal_sft/main.cpp: In function ‘int SkewProc(HWND, UINT, WPARAM, LPARAM)’:
fraktal_sft/main.cpp:3455:57: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
    HWND hwParent = (HWND)GetWindowLong(hWnd,GWL_USERDATA);
                                                         ^
fraktal_sft/main.cpp:3666:56: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
   HWND hwParent = (HWND)GetWindowLong(hWnd,GWL_USERDATA);
                                                        ^
common/FolderBrowser.cpp: In function ‘int lpfnEdit(HWND, UINT, WPARAM, LPARAM)’:
common/FolderBrowser.cpp:66:62: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
  return CallWindowProc((WNDPROC)GetClassLong(hWnd,GCL_WNDPROC),hWnd,uMsg,wParam,lParam);
                                                              ^
common/FolderBrowser.cpp: In function ‘int Browse(HWND, char*, int)’:
common/FolderBrowser.cpp:102:40: warning: cast from ‘LPITEMIDLIST {aka _ITEMIDLIST*}’ to ‘int’ loses precision [-fpermissive]
  int nRet = (int)SHBrowseForFolderA(&bi);
                                        ^
common/FolderBrowser.cpp: In function ‘long int FilterProc(HWND, UINT, WPARAM, LPARAM)’:
common/FolderBrowser.cpp:114:62: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
  return CallWindowProc((WNDPROC)GetClassLong(hWnd,GCL_WNDPROC),hWnd,uMsg,wParam,lParam);
                                                              ^
common/FolderBrowser.cpp: In function ‘int lpfnCallBack2(HWND, UINT, WPARAM, LPARAM)’:
common/FolderBrowser.cpp:132:41: warning: cast from ‘long int (*)(HWND, UINT, WPARAM, LPARAM) {aka long int (*)(HWND__*, unsigned int, long long unsigned int, long long int)}’ to ‘LONG {aka long int}’ loses precision [-fpermissive]
   SetWindowLong(hEdit,GWL_WNDPROC,(LONG)FilterProc);
                                         ^~~~~~~~~~
common/FolderBrowser.cpp: In function ‘int Browse(HWND, char*, int, char*, char*, int)’:
common/FolderBrowser.cpp:160:39: warning: cast from ‘LPITEMIDLIST {aka _ITEMIDLIST*}’ to ‘int’ loses precision [-fpermissive]
  int nRet = (int)SHBrowseForFolder(&bi);
                                       ^
common/StringVector.cpp: In member function ‘char* CStringVektor::GetString(int, int*)’:
common/StringVector.cpp:439:29: warning: invalid conversion from ‘const char*’ to ‘char*’ [-fpermissive]
  return m_pszStrings[nIndex]?m_pszStrings[nIndex]:"";
         ~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~
common/tooltip.cpp: In function ‘long int ToolTipProc(HWND, UINT, WPARAM, LPARAM)’:
common/tooltip.cpp:153:28: warning: cast from ‘HWND {aka HWND__*}’ to ‘int’ loses precision [-fpermissive]
   wsprintf(szTmp,"%d",(int)hw);
                            ^~
common/tooltip.cpp: In function ‘void CollectObjects(HWND, HWND, LPARAM)’:
common/tooltip.cpp:226:52: warning: cast from ‘HWND {aka HWND__*}’ to ‘int’ loses precision [-fpermissive]
   g_stWindows.AddInt(g_stWindows.GetCount()-1,(int)hwNext);
                                                    ^~~~~~
common/tooltip.cpp:227:52: warning: cast from ‘HWND {aka HWND__*}’ to ‘int’ loses precision [-fpermissive]
   g_stWindows.AddInt(g_stWindows.GetCount()-1,(int)hwParent);
                                                    ^~~~~~~~
common/tooltip.cpp: In function ‘void ExitToolTip(HWND)’:
common/tooltip.cpp:283:36: warning: cast from ‘HWND {aka HWND__*}’ to ‘int’ loses precision [-fpermissive]
   if(atoi(g_stWindows[i][1])==(int)hWnd)
                                    ^~~~

Title: Re: compiling kf 2.9.3 with mingw64
Post by: Dinkydau on March 14, 2017, 02:06:11 AM

Thanks for these great speedups. This will be useful.

I just noticed the coordinates are written in scientific notation. I assume that's something unintentional?

Title: Re: compiling kf 2.9.3 with mingw64
Post by: claude on March 14, 2017, 03:22:30 PM

Quote from: Dinkydau on March 14, 2017, 02:06:11 AM

I just noticed the coordinates are written in scientific notation. I assume that's something unintentional?

Yes unintentional, just using the default string format of the underlying libraries - I'll see if it's an easy fix, but I don't think it will cause many problems?

Title: Re: compiling kf 2.9.3 with mingw64
Post by: Kalles Fraktaler on March 14, 2017, 05:04:46 PM

Quote from: claude on March 13, 2017, 05:24:05 AM

Code:

fraktal_sft/listbox.cpp: In function ‘int SubclassListProc(HWND, UINT, WPARAM, LPARAM)’:
fraktal_sft/listbox.cpp:14:62: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
   CListBox*pList = (CListBox*)GetWindowLong(hWnd,GWL_USERDATA);
                                                              ^
fraktal_sft/listbox.cpp:19:62: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
   CListBox*pList = (CListBox*)GetWindowLong(hWnd,GWL_USERDATA);
                                                              ^
fraktal_sft/listbox.cpp:24:62: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
   CListBox*pList = (CListBox*)GetWindowLong(hWnd,GWL_USERDATA);
                                                              ^
fraktal_sft/listbox.cpp:28:62: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
  return CallWindowProc((WNDPROC)GetClassLong(hWnd,GCL_WNDPROC),hWnd,uMsg,wParam,lParam);
                                                              ^
fraktal_sft/listbox.cpp: In constructor ‘CListBox::CListBox(HWND, HWND, char*, int, COLORREF, COLORREF, BOOL)’:
fraktal_sft/listbox.cpp:108:44: warning: cast from ‘CListBox*’ to ‘LONG {aka long int}’ loses precision [-fpermissive]
  SetWindowLong(m_hwList,GWL_USERDATA,(LONG)this);
                                            ^~~~
fraktal_sft/listbox.cpp:109:43: warning: cast from ‘int (*)(HWND, UINT, WPARAM, LPARAM) {aka int (*)(HWND__*, unsigned int, long long unsigned int, long long int)}’ to ‘LONG {aka long int}’ loses precision [-fpermissive]
  SetWindowLong(m_hwList,GWL_WNDPROC,(LONG)SubclassListProc);
                                           ^~~~~~~~~~~~~~~~
fraktal_sft/listbox.cpp: In constructor ‘CListBoxEdit::CListBoxEdit(HWND, HWND, HWND, HWND, HWND, HWND__**, int)’:
fraktal_sft/listbox.cpp:250:35: warning: cast from ‘HWND {aka HWND__*}’ to ‘int’ loses precision [-fpermissive]
   m_stEdits.AddInt((int)phwEdits[i]);
                                   ^
fraktal_sft/listbox.cpp: In member function ‘int CListBoxEdit::ProcessMessage(HWND, UINT, WPARAM, LPARAM)’:
fraktal_sft/listbox.cpp:259:54: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
     nLen+=GetWindowTextLength((HWND)atoi(m_stEdits[i]))+1;
                                                      ^
fraktal_sft/listbox.cpp:265:41: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
     GetClassName((HWND)atoi(m_stEdits[i]),szClass,sizeof(szClass));
                                         ^
fraktal_sft/listbox.cpp:267:46: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
      itoa(SendMessage((HWND)atoi(m_stEdits[i]),BM_GETCHECK,0,0),szTmp+strlen(szTmp),10);
                                              ^
fraktal_sft/listbox.cpp:269:44: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
      GetWindowTextA((HWND)atoi(m_stEdits[i]),szTmp+strlen(szTmp),nLen+1);
                                            ^
fraktal_sft/listbox.cpp:284:54: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
     nLen+=GetWindowTextLength((HWND)atoi(m_stEdits[i]))+1;
                                                      ^
fraktal_sft/listbox.cpp:290:41: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
     GetClassName((HWND)atoi(m_stEdits[i]),szClass,sizeof(szClass));
                                         ^
fraktal_sft/listbox.cpp:292:46: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
      itoa(SendMessage((HWND)atoi(m_stEdits[i]),BM_GETCHECK,0,0),szTmp+strlen(szTmp),10);
                                              ^
fraktal_sft/listbox.cpp:294:44: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
      GetWindowTextA((HWND)atoi(m_stEdits[i]),szTmp+strlen(szTmp),nLen+1);
                                            ^
fraktal_sft/listbox.cpp:322:42: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
      GetClassName((HWND)atoi(m_stEdits[i]),szClass,sizeof(szClass));
                                          ^
fraktal_sft/listbox.cpp:324:42: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
       SendMessage((HWND)atoi(m_stEdits[i]),BM_SETCHECK,atoi(stT[0][i+1]),0);
                                          ^
fraktal_sft/listbox.cpp:326:45: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
       SetWindowTextA((HWND)atoi(m_stEdits[i]),stT[0][i+1]);
                                             ^
fraktal_sft/main.cpp: In function ‘long int ShowProc(HWND, UINT, WPARAM, LPARAM)’:
fraktal_sft/main.cpp:754:62: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
  return CallWindowProc((WNDPROC)GetClassLong(hWnd,GCL_WNDPROC),hWnd,uMsg,lParam,wParam);
                                                              ^
fraktal_sft/main.cpp: In function ‘int CustomZoomSize(HWND, UINT, WPARAM, LPARAM)’:
fraktal_sft/main.cpp:3157:56: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
    char *szTmp = (char*)GetWindowLong(hWnd,GWL_USERDATA);
                                                        ^
fraktal_sft/main.cpp: In function ‘int SkewProc(HWND, UINT, WPARAM, LPARAM)’:
fraktal_sft/main.cpp:3455:57: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
    HWND hwParent = (HWND)GetWindowLong(hWnd,GWL_USERDATA);
                                                         ^
fraktal_sft/main.cpp:3666:56: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
   HWND hwParent = (HWND)GetWindowLong(hWnd,GWL_USERDATA);
                                                        ^
common/FolderBrowser.cpp: In function ‘int lpfnEdit(HWND, UINT, WPARAM, LPARAM)’:
common/FolderBrowser.cpp:66:62: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
  return CallWindowProc((WNDPROC)GetClassLong(hWnd,GCL_WNDPROC),hWnd,uMsg,wParam,lParam);
                                                              ^
common/FolderBrowser.cpp: In function ‘int Browse(HWND, char*, int)’:
common/FolderBrowser.cpp:102:40: warning: cast from ‘LPITEMIDLIST {aka _ITEMIDLIST*}’ to ‘int’ loses precision [-fpermissive]
  int nRet = (int)SHBrowseForFolderA(&bi);
                                        ^
common/FolderBrowser.cpp: In function ‘long int FilterProc(HWND, UINT, WPARAM, LPARAM)’:
common/FolderBrowser.cpp:114:62: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
  return CallWindowProc((WNDPROC)GetClassLong(hWnd,GCL_WNDPROC),hWnd,uMsg,wParam,lParam);
                                                              ^
common/FolderBrowser.cpp: In function ‘int lpfnCallBack2(HWND, UINT, WPARAM, LPARAM)’:
common/FolderBrowser.cpp:132:41: warning: cast from ‘long int (*)(HWND, UINT, WPARAM, LPARAM) {aka long int (*)(HWND__*, unsigned int, long long unsigned int, long long int)}’ to ‘LONG {aka long int}’ loses precision [-fpermissive]
   SetWindowLong(hEdit,GWL_WNDPROC,(LONG)FilterProc);
                                         ^~~~~~~~~~
common/FolderBrowser.cpp: In function ‘int Browse(HWND, char*, int, char*, char*, int)’:
common/FolderBrowser.cpp:160:39: warning: cast from ‘LPITEMIDLIST {aka _ITEMIDLIST*}’ to ‘int’ loses precision [-fpermissive]
  int nRet = (int)SHBrowseForFolder(&bi);
                                       ^
common/StringVector.cpp: In member function ‘char* CStringVektor::GetString(int, int*)’:
common/StringVector.cpp:439:29: warning: invalid conversion from ‘const char*’ to ‘char*’ [-fpermissive]
  return m_pszStrings[nIndex]?m_pszStrings[nIndex]:"";
         ~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~
common/tooltip.cpp: In function ‘long int ToolTipProc(HWND, UINT, WPARAM, LPARAM)’:
common/tooltip.cpp:153:28: warning: cast from ‘HWND {aka HWND__*}’ to ‘int’ loses precision [-fpermissive]
   wsprintf(szTmp,"%d",(int)hw);
                            ^~
common/tooltip.cpp: In function ‘void CollectObjects(HWND, HWND, LPARAM)’:
common/tooltip.cpp:226:52: warning: cast from ‘HWND {aka HWND__*}’ to ‘int’ loses precision [-fpermissive]
   g_stWindows.AddInt(g_stWindows.GetCount()-1,(int)hwNext);
                                                    ^~~~~~
common/tooltip.cpp:227:52: warning: cast from ‘HWND {aka HWND__*}’ to ‘int’ loses precision [-fpermissive]
   g_stWindows.AddInt(g_stWindows.GetCount()-1,(int)hwParent);
                                                    ^~~~~~~~
common/tooltip.cpp: In function ‘void ExitToolTip(HWND)’:
common/tooltip.cpp:283:36: warning: cast from ‘HWND {aka HWND__*}’ to ‘int’ loses precision [-fpermissive]
   if(atoi(g_stWindows[i][1])==(int)hWnd)
                                    ^~~~

Very cool indeed, thanks a lot.
I don't recall these warnings occur when compiling in VS.

What is the difference between MPFR and GMP?
GMP seems preferable if it is faster :)

Title: Re: compiling kf 2.9.3 with mingw64
Post by: claude on March 14, 2017, 06:55:19 PM

Quote from: Kalles Fraktaler on March 14, 2017, 05:04:46 PM

What is the difference between MPFR and GMP?
GMP seems preferable if it is faster :)

MPFR is correctly-rounded to the desired precision, supports infinity and NaN, and has many special functions (trigonometry etc). GMP's mpf_t floating point is quick and dirty, with only bare minimum of operations and only approximate precision.

Title: Re: compiling kf 2.9.3 with mingw64
Post by: Kalles Fraktaler on March 16, 2017, 12:55:11 PM

It seems the reference is calculated faster in KF CFixedFloat class up to e300, then GMP is faster, and there is a very big difference at e10000.
Perhaps GMP are using other method than simple school-book multiplication on high precision?

Title: Re: compiling kf 2.9.3 with mingw64
Post by: claude on March 16, 2017, 01:35:17 PM

Quote from: Kalles Fraktaler on March 16, 2017, 12:55:11 PM

Perhaps GMP are using other method than simple school-book multiplication on high precision?

Yep, see: https://gmplib.org/manual/Multiplication-Algorithms.html

Title: Re: compiling kf 2.9.3 with mingw64
Post by: Kalles Fraktaler on March 23, 2017, 01:25:06 PM

claude, sorry for asking I have probably already asked this before, but...
Where can I get the GMP source code, so that I can complile the code you made?
Thanks :)

Title: Re: compiling kf 2.9.3 with mingw64
Post by: claude on March 23, 2017, 04:10:34 PM

https://gmplib.org/
http://www.mpfr.org/

Title: Re: compiling kf 2.9.3 with mingw64
Post by: jwm-art on March 24, 2017, 01:14:32 AM

GMP uses precisions which are multiples of 128 IIRC, whereas MPFR really is arbitrary.

Now here comes the anecdotal information:

When I was developing MDZ I didn't know if there would be any difference between images calculated using GMP or MPFR so I made it possible for the user to choose.

As a quick test I ran md5sum on two PNG images, 480x360 of the same location produced by GMP and MPFR respectively. At a coordinate beyond long-double precision (specifying 128bit precision), with fairly low detail, the checksums were identical, but at a coordinate with higher detail, there was a difference. Grain-extracting the two images shows 2 pixels differ.

Code:

cx -7.629452986011225709144911246318899918113e-1
cy 9.530800448400036754444994756219512453153e-2
size 2.508901897545227208260204484065216906272e-19

When I used to use MDZ, I alwasy used GMP as it was faster and given enough precision there was no perceptible difference.

Title: Re: compiling kf 2.9.3 with mingw64
Post by: Kalles Fraktaler on March 27, 2017, 11:29:34 AM

Quote from: claude on March 23, 2017, 04:10:34 PM

https://gmplib.org/
http://www.mpfr.org/

Thanks
But it seems you are using "boost" since this include
#include <boost/multiprecision/mpfr.hpp>

So I downloaded boost, and in the file gmp.hpp the following line caused problems
#include <gmp.h>

The file gmp.h is not included in the boost download zip.
I found one on the internet, https://members.loria.fr/FSur/enseignement/coursCalea/gmp.h
This made me able to compile the project, however there are link error of unresolved externals:
__gmp_get_memory_functions
__gmpf_abs
__gmpf_add

I don't know where these functions are implemented, I cannot find them neither in boost or in the gmp download packages, I only find references to these functions...
Please help :)

Title: Re: compiling kf 2.9.3 with mingw64
Post by: claude on March 27, 2017, 06:36:32 PM

sorry for not mentioning the boost dep, but your issues are lower-level I think

afaik gmp.h is created when you compile gmp properly (I don't know how to do this on windows, cross-compiling from linux I just pass the right cross-compiler options to ./configure)

Title: Re: compiling kf 2.9.3 with mingw64
Post by: Kalles Fraktaler on March 29, 2017, 09:40:24 AM

Quote from: claude on March 27, 2017, 06:36:32 PM

Thanks.
GMP is neither supporting Windows nor Visual Studio, by purpose.
I found a pre-compiled library MPIR and I succeeded compiling the program.
However the speed is much slower with MPIR, a little slower than CFixedFloat at e1000, while your gcc-program is twice as fast.

Are you making updates on your KF version? There are some small bugs that I think you are aware of...
May I wish for unlimited precision, I think the only restriction currently is the ToText functions...?

Title: Re: compiling kf 2.9.3 with mingw64
Post by: claude on March 29, 2017, 05:13:20 PM

Quote from: Kalles Fraktaler on March 29, 2017, 09:40:24 AM

Maybe you can use MINGW/MSYS or similar to compile, instead of Visual Studio? Afaik MPIR is for interval arithmetic, and will do at least twice the work as MPFR.

Yes I think precision is now only limited by the ToText static buffer - maybe would be a good time to switch to using std::string where appropriate, instead of raw char * pointers.

I'm not sure which other bugs you are referring to - I am making small changes from time to time but I have a lot of different projects to work on, haven't touched it for a few weeks I think.

Title: Re: compiling kf 2.9.3 with mingw64
Post by: Kalles Fraktaler on March 29, 2017, 08:02:49 PM

Quote from: claude on March 29, 2017, 05:13:20 PM

No bugs other than what you mentioned, about precision lost on manual zooming, which is not that critical anyway.

I think GMP wants to be installed by some Linux specific methods so I am not sure mingw on Windows would help.

Anyway, whenever you have the time :)

Title: Re: compiling kf 2.9.3 with mingw64
Post by: claude on March 30, 2017, 03:24:59 AM

New version, without limits on precision - note GMP has a high limit for precision (2^31-1 64bit limbs) and system RAM required to store precise numbers will also limit the reachable depth.

Downloads:

https://mathr.co.uk/mandelbrot/kf-2.11.1%2Bgmp.20170330.zip (64bit Windows binary)
https://mathr.co.uk/mandelbrot/kf-2.11.1%2Bgmp.20170330.zip.sig (signature)

Other changes:
- fixed the scientific notation bug that Dinkydau reported
- separate compilation (so make -j8 can use multiple cores, and small changes can recompile only the affected parts)
- deleted an operator new() that couldn't be made static and was causing strange issues
- reordered some nested loops for improved cache coherency
- fixed some "narrowing" warnings

Title: Re: compiling kf 2.9.3 with mingw64
Post by: Kalles Fraktaler on March 30, 2017, 09:20:32 AM

Quote from: claude on March 30, 2017, 03:24:59 AM

Thanks for this.
I'm sorry but it crash when I try to open some kfr files, example attached

Title: Re: compiling kf 2.9.3 with mingw64
Post by: claude on March 30, 2017, 09:38:14 AM

Quote from: Kalles Fraktaler on March 30, 2017, 09:20:32 AM

Thanks for this.
I'm sorry but it crash when I try to open some kfr files, example attached

Arrgh, you're right. And worse, it doesn't crash 100% of the time (at least in my tests), so it's probably some race condition that will be hard to debug. I have a hunch about what it might be, though, so will work on it today...

Title: Re: compiling kf 2.9.3 with mingw64
Post by: Kalles Fraktaler on March 30, 2017, 10:26:21 AM

Quote from: claude on March 30, 2017, 09:38:14 AM

It also crash when I pass the e300 limit, where the scaling kicks in, it may be related.
I hope you find it worth solving, because the speed improvement you have achieved is really great :)

Title: Re: compiling kf 2.9.3 with mingw64
Post by: knighty on March 30, 2017, 01:20:55 PM

Great project!

Quote from: Kalles Fraktaler on March 29, 2017, 08:02:49 PM

I think GMP wants to be installed by some Linux specific methods so I am not sure mingw on Windows would help.

MSYS2 (http://www.msys2.org/) comes with prebuilt GMP and mpfr libraries (among lots of other libraries) so no need to compile them from sources.

Title: Re: compiling kf 2.9.3 with mingw64
Post by: claude on March 30, 2017, 02:10:34 PM

I think I fixed it:

https://mathr.co.uk/mandelbrot/kf-2.11.1%2Bgmp.20170330.1.zip
https://mathr.co.uk/mandelbrot/kf-2.11.1%2Bgmp.20170330.1.zip.sig

The problem I fixed was a buffer overflow - the CDecNumber::ToText() was writing '0' beyond the end of the string, a problem masked before because the buffer was very big. I don't know what that code is doing, I hope I translated it to safe std::string operations correctly. There may be other issues still, please test.

This build uses latest GMP release 6.1.2, I forgot which earlier version was used for previous builds.

Title: Re: compiling kf 2.9.3 with mingw64
Post by: Kalles Fraktaler on March 30, 2017, 02:50:37 PM

Quote from: claude on March 30, 2017, 02:10:34 PM

Crash-bug solved :)
I have also found that there are some issues entering location parameters manually in the location dialog (Ctrl+L)
In particular the "easy deep zoom test", e.g. Re:-1.97, Im:0, Zoom:1e100

Quote from: knighty on March 30, 2017, 01:20:55 PM

Great project!MSYS2 (http://www.msys2.org/) comes with prebuilt GMP and mpfr libraries (among lots of other libraries) so no need to compile them from sources.

I downloaded and installed MSYS2, but then what? There is a file called msys-gmp-10.dll but no gmp.h or any .lib files...

Title: Re: compiling kf 2.9.3 with mingw64
Post by: claude on March 30, 2017, 02:57:27 PM

Quote from: Kalles Fraktaler on March 30, 2017, 02:50:37 PM

Great that the crash is fixed.

I guess that problem is because the precision for re/im (and thus the view bounds, and reference too probably) is set based on re/im string length instead of being based on zoom depth as it should be - I don't know an easy fix, mainly because I don't know where all the places that view parameter strings are converted to view parameter bigfloats.

Title: Re: compiling kf 2.9.3 with mingw64
Post by: Kalles Fraktaler on March 30, 2017, 04:02:35 PM

Quote from: claude on March 30, 2017, 02:57:27 PM

I used to set the precision in the SetPosition function, I think only the one with string parameters is important for precision
1. Check if there is an 'E' or 'e' - if it is, get the number of needed decimals from the followed number (plus some value)
2. Else, check if there is a dot, if it is, use the length to the dot as the needed decimals (plus some value)
3. Else, use the total string length
SetPosition with CFixedFloat input is used only when resetting to zoom=1, or the hidden function (Ctrl+V) that takes parameters from earlier programs I've made, which can be ignored.

Title: Re: compiling kf 2.9.3 with mingw64
Post by: knighty on March 30, 2017, 09:49:46 PM

Quote from: Kalles Fraktaler on March 30, 2017, 02:50:37 PM

I downloaded and installed MSYS2, but then what? There is a file called msys-gmp-10.dll but no gmp.h or any .lib files...

Follow the instructions on that site. ;D
The installer installs only msys2. You will need to install mingw (32 or 64 or both) and the libraries by invoking pacman from MSys2 shell (as shown in the web page).

Title: Re: compiling kf 2.9.3 with mingw64
Post by: knighty on April 03, 2017, 03:01:57 PM

Finally, I've managed to compile it using Msys2/mingw64/gcc. The process was not straightforward as I expected though. I had a 2 years old msys2 installation with mingw. At the time mingw64 was installed just by following the instructions. It is not the case any more. I also couldn't compile fraktal-sft64 with it, maybe because of mingw headers issues (the compiler said so :D).

So here is what I did (windows 7 OS):

1- remove the old Msys2.
2- Uploaded latest version of msys2 (msys2-x86_64-20161025.exe (http://www.msys2.org/)). This is the 64 bit version. msys2-i686-20161025.exe is the 32 bit version.
3- after running it, it installs msys2. At the end the msys2 shell is launched.
4- In the msys2 shell, invoke pacman:

Code:

pacman -Syuu

This have to be done until is says there is nothing to do anymore.
5- close the msys2 shell:

Code:

exit

6- reopen msys2 shell (from startup menu).
7- Install mingw/gcc 64 bit:

Code:

pacman -S mingw-w64-x86_64-toolchain

(one can also install 32 bit version by: pacman -S mingw-w64-i686-toolchain)
8- close msys2 shell then open "msys2 mingw 64 bit" shell (in order to have all the environment variables properly set)
9- change directory to the kalles fraktaler sources (where Makefile resides).
10- I had to modify Makefile:
line:

Code:

WINDRES := x86_64-w64-mingw32-windres

to:

Code:

WINDRES := windres

11- compile:

Code:

mingw32-make

voila!

On my PC I have to execute it this way from (msys2 mingw 64 bit) command line:

Code:

./fraktal_sft64

because it is linked dynamically to libwinpthread-1.dll. Copying this dll next to executable will make it run from the explorer.

O0

Title: Re: compiling kf 2.9.3 with mingw64
Post by: claude on April 03, 2017, 10:06:31 PM

Quote from: Kalles Fraktaler on March 30, 2017, 04:02:35 PM

I used to set the precision in the SetPosition function, I think only the one with string parameters is important for precision

After this changeset the "easy deep zoom test" works now:
https://code.mathr.co.uk/kalles-fraktaler-2/commitdiff/ab17330796f2698774292ec515268c2e0dfb3325

Still trying to track down the bug about losing precision when zooming manually past e38 or so. Where in the code do the coordinates get updated by mouse wheel zoom? I tried inserting precision-increasing code in various places but no joy so far...

knighty I guess you compiled the 'claude' branch, any chance of instructions for the 'claude-gmp' branch too? You need boost for the multiprecision wrappers (header-only afaik, at least I don't think I compiled boost) and GMP. I'll update the Makefile to make it possible to set the windres program from the command line without editing.

Title: Re: compiling kf 2.9.3 with mingw64
Post by: Kalles Fraktaler on April 04, 2017, 12:41:47 AM

Quote from: claude on April 03, 2017, 10:06:31 PM

Still trying to track down the bug about losing precision when zooming manually past e38 or so. Where in the code do the coordinates get updated by mouse wheel zoom? I tried inserting precision-increasing code in various places but no joy so far...

All manual zooming pass the CFraktalSFT::Zoom function.
However the actual precision controlling function is CFixedFloat::SetMaxSignificant and that is only setting the precision, globally, for the CFixedFloat class.
I always used full precision for CDecNumber (except for Newton-Raphson)

Title: Re: compiling kf 2.9.3 with mingw64
Post by: claude on April 04, 2017, 02:26:36 AM

Quote from: Kalles Fraktaler on April 04, 2017, 12:41:47 AM

Good to know. The fact that you used full precision for CDecNumber makes it more difficult to adapt the code, now that I removed the maximum precision limit.

In the GMP branch CDecNumber and CFixedFloat both wrap Boost's mpfr_float<0> (or similar, I forgot the exact syntax) with precision dynamic at runtime. So I call mpfr_float<0>::default_precision(digits10) when I want to change the global precision (shared by both types), wrapping it in a class so it resets automatically when the Precision object goes out of scope and is destructed. I also sometimes call the .precision(digitis10) method of particular variables when I need to change it. There is also a .precision() getter method on the Boost types.

Title: Re: compiling kf 2.9.3 with mingw64
Post by: knighty on April 04, 2017, 12:51:13 PM

Quote from: claude on April 03, 2017, 10:06:31 PM

knighty I guess you compiled the 'claude' branch, any chance of instructions for the 'claude-gmp' branch too? You need boost for the multiprecision wrappers (header-only afaik, at least I don't think I compiled boost) and GMP. I'll update the Makefile to make it possible to set the windres program from the command line without editing.

Yes, that was the 'claude' branch. I've just compiled the 'claude-gmp' branch without any problem. I just had to download boost:

Code:

pacman -S mingw-w64-x86_64-boost

from msys shell, then after closing msys shell and opening mingw64 shell, compile KF (from its sources directory):

Code:

cd <directory of 'claude-gmp-kf'>
mingw32-make WINDRES=windres
mingw32-make clean

There are only some warnings (as with 'claude' branch)

In order to execute it from the explorer one needs to copy libgmp-10.dll and libwinpthread-1.dll from msys64/mingw64/bin next to the generated executable (kf.exe).

BTW: The list of available mingw packages is here (https://github.com/Alexpux/MINGW-packages).

Title: Re: compiling kf 2.9.3 with mingw64
Post by: Kalles Fraktaler on April 05, 2017, 03:37:23 PM

I just found an embarrasing bug, that have been there all the time.
In the file main.cpp, the small "cross-hair" window is not updated if the cursor is above the cross-hair window itself.
Then the message procedure is exited, however this check is done after GDI resources are loaded, so by holding the cursor over the cross-hair window for a long time all resources eventually runs out.
Beginning on line 1754, please move the condition and return up to just after the call to GetCursorPos, like this:

Code:

...
	else if(uMsg==WM_TIMER){
		POINT p;
		GetCursorPos(&p);
		if(hWnd==WindowFromPoint(p) || hWnd==GetParent(WindowFromPoint(p)))
			return 0;
...

Sorry for that... :embarrass:

Title: Re: compiling kf 2.9.3 with mingw64
Post by: claude on April 05, 2017, 05:19:27 PM

Quote from: Kalles Fraktaler on April 05, 2017, 03:37:23 PM

bug

Thanks for the fix! I committed it to all 3 branches in my repository.

Title: Re: compiling kf 2.9.3 with mingw64
Post by: claude on April 06, 2017, 01:32:18 PM

I fixed some bugs (and Karl fixed one too). And I made a page for the project, where you can download it: https://mathr.co.uk/kf/kf.html

This fix made it 90% faster for trivial zooms like the initial view: https://code.mathr.co.uk/kalles-fraktaler-2/commitdiff/d99f73c1cd4343dd2c2d627ef1d221dbfd916456

Title: Re: compiling kf 2.9.3 with mingw64
Post by: Kalles Fraktaler on April 06, 2017, 06:05:15 PM

Quote from: claude on April 06, 2017, 01:32:18 PM

Cool, thanks!
I have put a link to your page in the top of my page, http://www.chillheimer.de/kallesfraktaler/
:) :beer: :horsie:

Title: Re: compiling kf 2.9.3 with mingw64
Post by: Kalles Fraktaler on April 06, 2017, 07:58:03 PM

Quote from: claude on April 06, 2017, 01:32:18 PM

This fix made it 90% faster for trivial zooms like the initial view: https://code.mathr.co.uk/kalles-fraktaler-2/commitdiff/d99f73c1cd4343dd2c2d627ef1d221dbfd916456

I don't understand what you fixed, is it about inflection?
That was an experiment I did, but it didn't get to work with perturbation.
I thought I had commented all of that away..?

Title: Re: compiling Kalles Fraktaler with mingw
Post by: claude on April 06, 2017, 09:16:46 PM

I put the inflection stuff behind an if, otherwise with no inflections it was still converting from double to CFixedFloat and back again without doing anything to the coordinates. Maybe is a version mismatch? I recommend git for version control (other systems are available) - handy for keeping track of changes.

Title: Re: compiling Kalles Fraktaler with mingw
Post by: Kalles Fraktaler on May 04, 2017, 10:27:06 AM

I made a comparison test.
I rendered stardust4ever's Magnum Opus Ex, http://stardust4ever.deviantart.com/art/Magnum-Opus-Ex-3132-6-Zooms-274474754, in 3200x3200.
My version of KF used 12m32s while your version used 3m37s, so the speed-up is 3.4 times, and amazingly more that 11,000 times faster than the original render by stardust!

Title: Re: compiling Kalles Fraktaler with mingw
Post by: PieMan597 on May 04, 2017, 02:05:08 PM

Is is at all possible for this to support open cl acceleration?

Title: Re: compiling Kalles Fraktaler with mingw
Post by: claude on May 04, 2017, 03:20:28 PM

Quote from: PieMan597 on May 04, 2017, 02:05:08 PM

Is is at all possible for this to support open cl acceleration?

Not without quite a lot of work.

I did start refactoring the formulas into separate files using C preprocessor to avoid code duplication, not finished or published yet. But it allows a formula to be written concisely in 2 short files:

formula/Mandelbrot2.h

Code:

#ifndef MANDELBROT2_H
#define MANDELBROT2_H
#include "formula0.h"
#define TYPE 0
#define POWER 2
#include "formula.h"
#endif

formula/Mandelbrot2.cpp

Code:

#include "Mandelbrot2.h"
#define GLITCH 0.0000001
#define REFERENCE(T) \
	Xrn = Xr2 - Xi2 + Cr; \
	Xin = (Xr + Xi).Square() - Xr2 - Xi2 + Ci;
#define PERTURBATION(T) \
	xrn = (2 * Xr + xr) * xr - (2 * Xi + xi) * xi + cr; \
	xin = 2 * ((Xr + xr) * xi + Xi * xr) + ci;
#include "formula.inc"

Plus 6 calls like F(type,power) in the relevant places, and 1 line to add the formula to the GUI.

Possibly this simplified formula code could be used for OpenCL too - or at least make it easier to add support. But I don't know how to use OpenCL on Windows, much less how to get it to work correctly in WINE.

Another change I made is to remove the threaded reference calculation - the non-threaded sped it up by a large factor (about 3x faster by elapsed wall-clock time for Dinkydau's Hyperbolic Tiling Pistile location) - either there is too much synchronisation overhead, or WINE is terrible at it. I published a new build with this change (but not the formula refactoring), would be great to have some benchmarks from real Windows users, maybe is a WINE issue: https://mathr.co.uk/kf/kf.html

Title: Re: compiling Kalles Fraktaler with mingw
Post by: Kalles Fraktaler on May 05, 2017, 01:03:11 PM

Quote from: claude on May 04, 2017, 03:20:28 PM

Another change I made is to remove the threaded reference calculation - the non-threaded sped it up by a large factor (about 3x faster by elapsed wall-clock time for Dinkydau's Hyperbolic Tiling Pistile location) - either there is too much synchronisation overhead, or WINE is terrible at it. I published a new build with this change (but not the formula refactoring), would be great to have some benchmarks from real Windows users, maybe is a WINE issue: https://mathr.co.uk/kf/kf.html

Cool, I downloaded the latest and made comparisons.
The I tested magnum opus, the reference is calculated in about 5 seconds on the new version, compared to about 7 with the old, so that is an improvement.
Second test was with a very deep location, 5.55E3198, with more than a million iterations calculated.
It took 1m21s on the new version and only 45 seconds on the old, so that is unfortunately about half the time.

I think the trick is to choose a good point where to use multi-threaded or not.

Addition: Also the "Hyperbolic tiling with golden ratio tiling pistil" is faster with multithreaded calculation on my windows machine, however the difference is only some 30%

Title: Re: compiling Kalles Fraktaler with mingw
Post by: claude on May 07, 2017, 04:57:05 PM

Quote from: Kalles Fraktaler on May 05, 2017, 01:03:11 PM

Here (WINE) it takes over twice as long with old version. So I think the conclusion is that it is a WINE issue:

version / total time as reported by kf / refs / notes
20170504 / 19m51s289 / ref 12 / without multithreaded reference calculations
20170406 / 46m02s592 / ref 12 / wineserver uses 60% CPU when computing reference

Quote

I think the trick is to choose a good point where to use multi-threaded or not.

Yes absolutely, at least make it available as an option in the menus (so that WINE users can disable it), if automagic config isn't an option. I don't know much about Windows GUI programming but I'll try to hack it in this week.

EDIT: as of now Windows users should use the 20170406 release, WINE users should use the 20170504 release, for best performance...

EDIT: confirmed on IRC as a WINE issue:
17:19 < slackner> ClaudiusMaximus: without having reviewed the whole code, my theory would be that multithreading is done in such a way that a lot of time is wasted with synchronization
17:19 < slackner> ClaudiusMaximus: event functions always use the wineserver atm, so this would explain the performance issues
17:19 < ClaudiusMaximus> yes that's definitely the case, i'm just suprised at the huge difference between Windows and WINE (around 4x)
17:19 < ClaudiusMaximus> ok, and wineserver is single-threaded?
17:20 < nsivov> it is
17:20 < slackner> ClaudiusMaximus: yes. in most cases that shouldn't matter though, usually wineserver calls are rare and can be executed very quickly
17:21 < ClaudiusMaximus> yes this code is a bit pathological i guess

EDIT: I investigated other synchronisation methods (alternatives to SetEvent()/WaitObject()), here's some rough results:

Code:

first test comparing barrier methods: time to complete newton 5e3198 with 12 refs

version / wall-clock time / cpu load for ref / barrier method / barrier submethod
yieldin2 / 21m12s288 / 245% / centralized barrier / yielding spinlocks
barrier2 / 25m01s879 / 270% / centralized barrier / non-yielding spinlocks
yielding / 22m29s161 / 220% / semaphore barrier / yielding spinlocks
barriers / 31m17s617 / 250% / semaphore barrier / non-yielding spinlocks
20170504 / 19m51s289 / 100% / without multithreaded reference calculations
20170406 / 46m02s592 / 160% (of which 60% wineserver)                                    

second test investigating cpu thread affinity set in various ways:   

test using htilepistil.kfr 1e2293 ldbl
isbest / method / time for first pixels / cpu load for ref / notes
* / affinity /  3m31s / 200% / 3 threads on 2 cores (any thread / any core)
  / affinity /  4m35s / 290% / 3 threads on 3 cores (one thread / one core)
  / taskset4 /  4m00s / 230% / wine uses 4 cores
  / taskset3 /  3m50s / 220% / wine uses 3 cores
  / taskset2 /  3m30s / 200% / wine uses 2 cores
  / taskset1 /  4m29s / 100% / wine uses 1 core
  / yieldin2 /  3m45s / 230% 
  / 20170504 /  3m34s / 100% 
  / 20170406 / 18m47s / 175% (of which 65% wineserver)  

test using e10000.kfr 1e10002 floatexp
isbest / method / time for first ref 100% / cpu load for ref / notes
  / affinity / 3m00s / 200% / 3 threads on 2 cores (any thread / any core)
* / affinity / 2m06s / 290% / 3 threads on 3 cores (one thread / one core)
  / yieldin2 / 2m21s / 260% 
  / 20170504 / 4m18s / 100%    
  / 20170406 / 6m25s / 150% (of which 40% wineserver) 

test using newton 5e3198 ldbl
isbest / method / time for first pixels / cpu load for ref / notes
* / affinity / 0m48s / 200% / 3 threads on 2 cores (any thread / any core)
* / affinity / 0m48s / 290% / 3 threads on 3 cores (one thread / one core)
  / yieldin2 / 0m52s / 245% 
  / barrier2 / 1m08s / 270% 
  / 20170504 / 0m55s / 100% 
  / 20170406 / 2m58s / 165% (of which 65% wineserver)

To conclude I'll use SetThreadAffinityMask(3) for ldbl and SetThreadAffinityMask(1<<threadid) for floatexp, which gives the best performance in these tests in WINE 64bit / Debian Stretch / AMD64 quad core processor. I'll post again with a new build soon.

Title: Re: compiling Kalles Fraktaler with mingw
Post by: claude on May 08, 2017, 02:54:14 PM

New build up at https://mathr.co.uk/kf/kf.html with barrier() semantics for synchronisation of the threaded reference calculations; this performs well on WINE, hopefully on real Windows too. Let me know how it works for you.

Title: Re: compiling Kalles Fraktaler with mingw
Post by: Adam Majewski on May 08, 2017, 06:06:13 PM

Quote from: claude on May 08, 2017, 02:54:14 PM

wine kf.exe
fixme:heap:HeapSetInformation 0x240000 0 0x23fe10 4
fixme:heap:HeapSetInformation (nil) 1 (nil) 0
fixme:advapi:RegisterEventSourceW ((null),L"Bonjour Service"): stub
fixme:advapi:ReportEventA (0xcafe4242,0x0004,0x0000,0x00000064,(nil),0x0001,0x00000000,0x54dfc0,(nil)): stub
fixme:advapi:ReportEventW (0xcafe4242,0x0004,0x0000,0x00000064,(nil),0x0001,0x00000000,0x6f9c0,(nil)): stub
fixme:winsock:WSAIoctl WS_SIO_UDP_CONNRESET stub
fixme:winsock:WSAIoctl -> SIO_ADDRESS_LIST_CHANGE request: stub
fixme:iphlpapi:DeleteIpForwardEntry (pRoute 0x54e350): stub
fixme:iphlpapi:CreateIpForwardEntry (pRoute 0x54e318): stub
fixme:advapi:ReportEventA (0xcafe4242,0x0004,0x0000,0x00000064,(nil),0x0001,0x00000000,0x54dfc0,(nil)): stub
fixme:advapi:ReportEventW (0xcafe4242,0x0004,0x0000,0x00000064,(nil),0x0001,0x00000000,0x70240,(nil)): stub
fixme:service:EnumServicesStatusW resume handle not supported
fixme:service:EnumServicesStatusW resume handle not supported
fixme:advapi:ReportEventA (0xcafe4242,0x0004,0x0000,0x00000064,(nil),0x0001,0x00000000,0x54dfc0,(nil)): stub
fixme:advapi:ReportEventW (0xcafe4242,0x0004,0x0000,0x00000064,(nil),0x0001,0x00000000,0x70240,(nil)): stub
fixme:netapi32:NetGetJoinInformation Semi-stub (null) 0x54e038 0x54e030
fixme:winsock:WSAIoctl WS_SIO_UDP_CONNRESET stub
fixme:advapi:ReportEventA (0xcafe4242,0x0001,0x0000,0x00000064,(nil),0x0001,0x00000000,0x54d4d0,(nil)): stub
fixme:advapi:ReportEventW (0xcafe4242,0x0001,0x0000,0x00000064,(nil),0x0001,0x00000000,0x70240,(nil)): stub
err:eventlog:ReportEventW L"mDNSCoreReceiveResponse: Received from 192.168.1.8:5353 16 zelman.local. AAAA FE80:0000:0000:0000:889C:3EA7:6CEA:BDC9"
fixme:advapi:ReportEventA (0xcafe4242,0x0001,0x0000,0x00000064,(nil),0x0001,0x00000000,0x54d4d0,(nil)): stub
fixme:advapi:ReportEventW (0xcafe4242,0x0001,0x0000,0x00000064,(nil),0x0001,0x00000000,0x70240,(nil)): stub
err:eventlog:ReportEventW L"mDNSCoreReceiveResponse: ProbeCount 2; will deregister 4 zelman.local. Addr 192.168.1.8"
fixme:advapi:ReportEventA (0xcafe4242,0x0001,0x0000,0x00000064,(nil),0x0001,0x00000000,0x54d3e0,(nil)): stub
fixme:advapi:ReportEventW (0xcafe4242,0x0001,0x0000,0x00000064,(nil),0x0001,0x00000000,0x70240,(nil)): stub
err:eventlog:ReportEventW L"Local Hostname zelman.local already in use; will try zelman-2.local instead"
fixme:advapi:ReportEventA (0xcafe4242,0x0001,0x0000,0x00000064,(nil),0x0001,0x00000000,0x54d4d0,(nil)): stub
fixme:advapi:ReportEventW (0xcafe4242,0x0001,0x0000,0x00000064,(nil),0x0001,0x00000000,0x70240,(nil)): stub
err:eventlog:ReportEventW L"mDNSCoreReceiveResponse: Received from 192.168.1.8:5353 14 8.1.168.192.in-addr.arpa. PTR zelman.local."
fixme:advapi:ReportEventA (0xcafe4242,0x0001,0x0000,0x00000064,(nil),0x0001,0x00000000,0x54d4d0,(nil)): stub
fixme:advapi:ReportEventW (0xcafe4242,0x0001,0x0000,0x00000064,(nil),0x0001,0x00000000,0x70240,(nil)): stub
err:eventlog:ReportEventW L"mDNSCoreReceiveResponse: Unexpected conflict discarding 16 8.1.168.192.in-addr.arpa. PTR zelman-2.local."

Title: Re: compiling Kalles Fraktaler with mingw
Post by: claude on May 08, 2017, 06:29:02 PM

Quote from: Adam Majewski on May 08, 2017, 06:06:13 PM

wine kf.exe
...snip...

does wine work with other programs?

which wine version do you have?

looks like network autodiscovery stuff, but kf.exe doesn't use any networking, so I guess this is a wine issue...

Title: Re: compiling Kalles Fraktaler with mingw
Post by: Adam Majewski on May 08, 2017, 07:01:06 PM

Quote from: claude on May 08, 2017, 06:29:02 PM

does wine work with other programs?

which wine version do you have?

looks like network autodiscovery stuff, but kf.exe doesn't use any networking, so I guess this is a wine issue...

KF program works for me ( maybe it was not seen from output )
wine --version
wine-1.6.2

Title: Re: compiling Kalles Fraktaler with mingw
Post by: claude on May 08, 2017, 07:21:00 PM

Quote from: Adam Majewski on May 08, 2017, 07:01:06 PM

KF program works for me ( maybe it was not seen from output )
wine --version
wine-1.6.2

Oh, if it works then no worries :)

For reference, I'm using
$ wine --version # most of the time
wine-1.8.7 (Debian 1.8.7-2)
$ wine-development --version # rare tests
wine-2.0 (Debian 2.0-3)

Title: Re: compiling Kalles Fraktaler with mingw
Post by: Dinkydau on May 24, 2017, 03:32:25 PM

The scientific notation bug appears to be back since 20170330.1
Edit: I downloaded 20170330, the version where the bug would have been fixed, but it has scientific notation too.

Title: Re: compiling Kalles Fraktaler with mingw
Post by: claude on May 24, 2017, 06:18:20 PM

Quote from: Dinkydau on May 24, 2017, 03:32:25 PM

The scientific notation bug appears to be back since 20170330.1
Edit: I downloaded 20170330, the version where the bug would have been fixed, but it has scientific notation too.

Ok, I think it's because I switched from scientific to default, which is a mix of non-scientific and scientific depending on size - I'll switch it to explicitly fixed next time I touch the code. Thanks for testing.

Title: Re: compiling Kalles Fraktaler with mingw
Post by: claude on July 03, 2017, 09:20:42 AM

new build at https://mathr.co.uk/kf/kf.html

Quote

kf-2.11.1+gmp.20170703 XML formulas

- formulas now generated at compile time from
formula definition XML using XSL stylesheet

- used fixed format floats instead of scientific

- try to hide command prompt window on Windows

The XML formula definition file is here: https://code.mathr.co.uk/kalles-fraktaler-2/blob/refs/heads/formulas:/formula/formula.xml
As you can see it strips out all the repetitive code.

It should be possible to generate OpenCL code from these formula definitions, at least for double precision (no long double in CL, and not sure if there is operator overloading for floatexp).

Title: Re: compiling Kalles Fraktaler with mingw
Post by: claude on July 06, 2017, 04:02:48 PM

some very preliminary (mostly broken) OpenCL fiddling here:

https://code.mathr.co.uk/kalles-fraktaler-2/log/refs/heads/formulas

to get it to build needs a Haskell development setup (ghc and cabal), as well as xsltproc - this is for a custom preprocesser to work around OpenCL 1.2's lack of operator overloading.

you need to git clone https://github.com/martijnberger/clew next to the kalles-fraktaler-2 directory also, as I couldn't figure out how to link OpenCL otherwise

OpenCL seems to work for very shallow zooms, even with force floatexp enabled, but as soon as going past 1e3 it flakes out - disabling series approximation and glitch correction helps slightly, but it's mostly made of fail

won't have time to hack on this code for a few weeks, so leaving it here in case someone manages to get it working in the meantime...

EDIT here's a binary: https://mathr.co.uk/kf/kf-with-opencl.zip

Title: Re: compiling Kalles Fraktaler with mingw
Post by: Dinkydau on July 08, 2017, 04:38:47 PM

The latest version crashes upon loading KFR files with a great depth such as E8383.

Also something else:
I'm interested in running kalles fraktaler in a virtual machine. I want to do that because it would allow me to save the state of the operating system while a heavy render is going on. If there's something that causes the computer to stop working such as power loss I can resume the render from the last saved state.

I compared some render times. There are 4 relevant types of calculations:
1. full precision reference pixels
2. series approximation
3. other pixels
4. Newton-raphson zooming, which could be split up into 4.1: finding period, 4.2: Newton-Raphson steps, 4.3: determining size of the minibrot.

First I tried windows 10 because it's easy to get a legal (trial) ISO of it.
Total render time is a little slower. Reference computation seems to be significantly slower.
Newton-Raphson zooming is about 5 times slower. (100 seconds versus 20 in a test). Especially finding the period is a lot slower. The other parts are slower as well.
This holds for several versions.
Mandel Machine and Fractal eXtreme perform pretty much exactly like how they do in my not-virtual windows 7, so the windows 10 virtual machine will be useful to render with Mandel Machine but not with Kalles fraktaler.

Then I installed Debian stretch with wine because it's what Claude uses, so I assumed it must be the most suitable to run his Kalles fraktaler fork.
Newton-Raphson zooming is still slower but only 2.5 times as slow. Also here, especially finding the period is a lot slower, but not as slow as in windows 10.
Comparing virtual Debian and not virtual Windows 7, the total render time is equal when using the latest version of KF+gmp to compare and a KFR file with depth E1886. Compared to this test:
Version 20170406 is about 8% faster in windows 7 (not virtual) but A LOT slower in Debian.
Version 20170508 is about 8% faster in windows 7 (not virtual) and 7% slower in Debian.

20170406 is the best version on windows 7, seemlingly equal to 20170508. 20170508 is the best version in Debian because it's the fastest one that doesn't hang upon loading great depths.
In the end 20170508 in Debian seems to be about 12% slower than 20170406 in not virtual Windows 7. I would accept that percentage if it means I won't have to be afraid to lose renders anymore but more tests with greater depths are required to be sure if it's worth doing. If the latest version didn't hang, it would be better.

Newton-Raphson zooming is so much faster on windows 7 (not virtual) that it's worth taking the risk of losing the progress right now.
I wondered how this could be and it came to my mind that Fractal eXtreme and Mandel Machine have all the important parts (that take a lot of time to run) written in assembly language. Could that have something to do with the fact that those programs don't seem to have any performance hits?

I will see if I can find my windows 7 installation DVD and make a virtual machine with that too to compare.

Title: Re: compiling Kalles Fraktaler with mingw
Post by: claude on July 09, 2017, 08:29:55 PM

Quote from: Dinkydau on July 08, 2017, 04:38:47 PM

The latest version crashes upon loading KFR files with a great depth such as E8383.

At least here (Debian 9 Stretch WINE) it looks like it hangs, but watching the system process monitor one can see that it calculates the reference (with threads) and then proceeeds to calculate the pixels (with lots of threads). But the main thread seems to be blocked, so no GUI updates occur. Testing with the e10000.kfr location. Not sure what will happen when the pixels finish calculating...

Quote

Also something else:
I'm interested in running kalles fraktaler in a virtual machine. I want to do that because it would allow me to save the state of the operating system while a heavy render is going on. If there's something that causes the computer to stop working such as power loss I can resume the render from the last saved state.

Yes that's a good way to do it without having to add such support to the program (which would be a big task afaict).

I suspect the slower parts have to do with syscalls (context switches to the kernel of the virtual machine), that might come from things that update the GUI. Perhaps some throttling/speed limiting could benefit here, with the Newton-Raphson zooming period finding especially. I'll put it on the todo list...

Quote

If the latest version didn't hang, it would be better.

Of course. Thanks for the bug report, indeed I hadn't tested the deep zoom levels.

Title: Re: compiling Kalles Fraktaler with mingw
Post by: Dinkydau on July 10, 2017, 09:59:41 AM

Doing the tests again I got the results the other way around some of the time. Render time is probably perfectly fine. To run kalles fraktaler in a virtual machine for rendering, Debian is the way to go.
Edit: Except it doesn't work with any kind of serious render resolution (say, 10000×5625 or more). I forgot about that bitmap problem (http://www.fractalforums.com/windows-fractal-software/windows-bitmap-size-test/)...

Title: Re: compiling Kalles Fraktaler with mingw
Post by: claude on July 10, 2017, 09:17:27 PM

https://mathr.co.uk/kf/kf.html
new build, many optimisations, experimental (mostly broken) opencl, fixes some bugs, leaner source archive

Title: Re: compiling Kalles Fraktaler with mingw
Post by: Dinkydau on July 11, 2017, 02:03:40 AM

All the performance problems are gone with this version. Thanks a lot.

Title: Re: compiling Kalles Fraktaler with mingw
Post by: claude on July 11, 2017, 08:20:42 PM

https://mathr.co.uk/kf/kf.html
another new build with workaround for bitmap size problem on WINE. not tested on real Windows, reports welcome (whether success or otherwise).

Title: Re: compiling Kalles Fraktaler with mingw
Post by: claude on July 13, 2017, 03:44:20 PM

https://mathr.co.uk/kf/kf.html yet another new build, this time with many optimisations to Newton-Raphson zooming (3x faster than the previous version in one of my tests)

Title: Re: compiling Kalles Fraktaler with mingw
Post by: Gerson on July 13, 2017, 08:10:48 PM

version kf-2.11.1+gmp.20170508 runs ok in my computer but kf-2.11.1+gmp.20170710 and newest doesnt. Why?

About the image size, Fractal Forge has a Poster Compositor that let to do big images with tiles of a parameter one. It will be nice if Kalles Fraktaler could do the same.

Title: Re: compiling Kalles Fraktaler with mingw
Post by: claude on July 13, 2017, 08:43:31 PM

Quote from: Gerson on July 13, 2017, 08:10:48 PM

version kf-2.11.1+gmp.20170508 runs ok in my computer but kf-2.11.1+gmp.20170710 and newest doesnt. Why?

thanks for testing!

that is hard to answer without more information. what are the symptoms? "doesn't run ok" covers a lot of different things. which version of Windows (or WINE) are you using?

does 20170703 run? that has a change in linking, namely "try to hide command prompt window on Windows"

or it could be related to loading OpenCL, which was first introduced in 20170710.

is easy to roll back the linking change (one line in the build system)

the opencl code is mostly broken at the moment so I should make it optional (and disabled by default).

Title: Re: compiling Kalles Fraktaler with mingw
Post by: Dinkydau on July 14, 2017, 01:01:23 AM

Newton-Raphson zooming is also 3 times faster on windows 7. Period finding and Newton-Raphson steps appear to be using 4 threads now (1 and 2 previously). The program seems to work well with various parameters. I didn't have a problem with openCL.

Title: Re: compiling Kalles Fraktaler with mingw
Post by: Gerson on July 14, 2017, 07:20:15 PM

I am using win7 pro sp1 64bits.
kf-2.11.1+gmp.20170703 run ok.
I am not a programer but I think that could be something with opencl because I cant run BuddhabrotMag too.
I dont know what I need to do to implement opencl in my computer. Accept any help to do it.

Title: Re: compiling Kalles Fraktaler with mingw
Post by: claude on July 14, 2017, 08:21:28 PM

Quote from: Gerson on July 14, 2017, 07:20:15 PM

I think that could be something with opencl

Ok I compiled a version without OpenCL:
https://mathr.co.uk/kf/kf-2.11.1+gmp.20170714.zip
also linked from the home page.

Hopefully this will fix it!

But it's strange, CLEW should have loaded OpenCL dynamically and be ok with not finding it - I guess there could be a bug in a present OpenCL.dll (eg: it crashes on load) that messes things up...

Title: Re: compiling Kalles Fraktaler with mingw
Post by: Gerson on July 17, 2017, 06:34:04 PM

Thanks. Now it works ok too.
I need just a opencl.dll to run those programs or is necessary to install something else?
I tried to test BuddhabrotMag but it doesnt run in my computer (???).

Title: Re: compiling Kalles Fraktaler with mingw
Post by: Kalles Fraktaler on August 20, 2017, 03:02:19 PM

Hello claude

I just downloaded and tried kf-2.11.1+gmp.20170714
Unfortunately it seems that all fractal types have been mixed up, so when opening a burning ship location, it uses the standard Mandelbrot formula.
Beside that, both render and Newton is faster, newton very very much faster :)

Title: Re: compiling Kalles Fraktaler with mingw
Post by: claude on August 20, 2017, 04:47:38 PM

Quote from: Kalles Fraktaler on August 20, 2017, 03:02:19 PM

Unfortunately it seems that all fractal types have been mixed up

Oh dear :( I'll see if it's an easy fix, otherwise it may have to wait until mid-September when I have more free time...

Title: Re: compiling Kalles Fraktaler with mingw
Post by: claude on August 20, 2017, 06:32:19 PM

fixed 20170820 build at https://mathr.co.uk/kf/kf.html ! (the preprocessor was bugged, so all diffabs() formulas were broken in previous versions - the change was 2 characters... https://code.mathr.co.uk/kalles-fraktaler-2/commitdiff/0befd420a1c4b3a676d6f259391313d13858e66b?hp=287683927a2fc1e57df0306eac094380ca1150a5

Title: Re: compiling Kalles Fraktaler with mingw
Post by: Kalles Fraktaler on August 21, 2017, 09:29:50 AM

Quote from: claude on August 20, 2017, 06:32:19 PM

I am sorry but there are still many not working.
Burning Ship power larger than 2.
Perpendicular Mandelbrot
Perpendicular Burning Ship.
...
And more

Title: Re: compiling Kalles Fraktaler with mingw
Post by: claude on August 21, 2017, 12:50:16 PM

Oh :( No time to look into it today, sorry..

Title: Re: compiling Kalles Fraktaler with mingw
Post by: Kalles Fraktaler on August 22, 2017, 09:04:09 AM

Quote from: claude on August 21, 2017, 12:50:16 PM

Oh :( No time to look into it today, sorry..

No problem, no hurry.

When you have time to look at this again, may I ask you for a small change?
In the file fraktal_sft.cpp can you replace the two occurencies of

Code:

iter=sqrt(iter)

with

Code:

iter=log(iter+1)

This is for the distance estimation coloring method, and makes the contributions from different layers (close passages of minibrots) be almost linear.

Title: Re: compiling Kalles Fraktaler with mingw
Post by: claude on August 23, 2017, 12:06:06 AM

Quote from: Kalles Fraktaler on August 22, 2017, 09:04:09 AM

No problem, no hurry.

I think I fixed it, was the exact same issue as the diffabs() preprocessing, but with the abs() function - a single character fix :embarrass:

Quote

When you have time to look at this again, may I ask you for a small change?
In the file fraktal_sft.cpp can you replace the two occurencies of

Code:

iter=sqrt(iter)

with

Code:

iter=log(iter+1)

This is for the distance estimation coloring method, and makes the contributions from different layers (close passages of minibrots) be almost linear.

I found two occurences taking into account whitespace differences, but I only changed the second one (colouring method 6/7 or so), leaving the first as-is (colouring method 1). I hope this is what you intended? Otherwise I can change the first one too. The colouring code one of the parts of the code I haven't looked at in much detail so far.

New build 20170822 at https://mathr.co.uk/kf/kf.html upgrading is recommended as versions 20170703 through 20170820 have broken formula implementations, and earlier versions are less optimized (especially for quadratic Mandelbrot).

Ideas for future development include:
* extending the formula preprocessor to reference calculations, potentially allowing lower-level GMP functions to be used in the inner loops so temporary variables aren't reallocated and freed every single iteration. this should provide a healthy speedup to every formula
* fixing the OpenCL stuff so that it actually works
* adding Pauldelbrot's multiwave colouring algorithm (will need a lot of GUI work I suspect, something I don't find fun, as well as delving into the .kfr (de)serialisation code that I haven't touched so far)

Title: Re: compiling Kalles Fraktaler with mingw
Post by: Kalles Fraktaler on August 23, 2017, 11:18:07 AM

Excellent, it works now! :)

Title: Re: compiling Kalles Fraktaler with mingw
Post by: Kalles Fraktaler on August 24, 2017, 09:50:53 AM

Hi Claude

I am very impressed that KF is now able to find a minibrot at around <-2,0i> on arbitrary depths - the previous versions would either crash or give some unreasonable result!

However here is another thing to look at whenever you have time.
The Newton Raphson function fail in the center of this view.
It works on my old version (and takes minutes while your version would take seconds... ;) )

Title: Re: compiling Kalles Fraktaler with mingw
Post by: claude on August 24, 2017, 03:58:30 PM

Worse, loading that "no newton.kfr" gives me a blank turquoise image :(
Zooming from it in either direction gives something more sensible.

Newton-Raphson zooming at that location in KF seems to give a bad period of 499 when it should be 18166 (checked with my standalone m-box-period code). Don't know why yet...

Title: Re: compiling Kalles Fraktaler with mingw
Post by: claude on September 13, 2017, 06:47:49 AM

New build! 20170913 at the usual https://mathr.co.uk/kf/kf.html Not many changes, just documentation updates, limit number of approximation terms to 60 at most, and the color method 7 = distance (logarithm) detailed below:

Quote from: Kalles Fraktaler on August 22, 2017, 09:04:09 AM

In the file fraktal_sft.cpp can you replace the two occurencies of

Code:

iter=sqrt(iter)

with

Code:

iter=log(iter+1)

This is for the distance estimation coloring method, and makes the contributions from different layers (close passages of minibrots) be almost linear.

I reverted this change. Instead I added a new colouring method ID 7 with this logarithmic scaling. This is to preserve compatibility with square root scaling expected by earlier parameter files.

Kalles, you'll need to update the movie makers to match the implementation of the latest version (I consider the behaviour of the 20170822 build to be buggy in this respect).

Title: Re: compiling Kalles Fraktaler with mingw
Post by: claude on September 19, 2017, 09:44:53 PM

New build at the usual place, version number 2.12.1 since Karl confirmed he won't be making new versions of his own. Main features are PDF manual and both 32bit and 64bit builds (all in one zip with the source too). Bugfixes to Examine Zoom Sequence and Distance colouring backward compatibility.

Title: Re: compiling Kalles Fraktaler with mingw
Post by: claude on September 20, 2017, 01:08:21 PM

new version 2.12.2 at the usual place, lots of new features, please test to check I didn't break any of the more unusual formulas in the process of massaging formula XML so the preprocessor could work its magic. Changes:

- PNG image saving support using libpng and zlib;
- JPEG default quality to 100 (was 99);
- colouring uses floating point internally to reduce quantisation steps;
- dithering at end of colouring to improve perceptual quality;
- formula.cpp included in source zip so GHC is not needed unless changing formula code;
- optimized diffabs() code: one test Burning Ship location is 7.5% faster;
- preprocessor optimizes reference calculations by floating temporary variable (re)allocations out of the inner loops: one test Burning Ship location is 30% faster;

Title: Re: compiling Kalles Fraktaler with mingw
Post by: gerrit on September 20, 2017, 07:25:05 PM

Thanks so much for doing this!

Could perhaps the need to oversample (typically factor 6-8 I find) to get the DE to look good be mitigated by using a higher order finite difference approximation for the derivatives?

Looking at the code it seems you use a first order FD.

Title: Re: compiling Kalles Fraktaler with mingw
Post by: claude on September 20, 2017, 08:45:14 PM

I don't think it would help. The places where the DE colouring looks bad are close to the boundary, which is a discontinuity/singularity in the derivative. But if you provide some example code or formulas I can try it out soon and report back.

Title: Re: compiling Kalles Fraktaler with mingw
Post by: gerrit on September 20, 2017, 09:54:39 PM

Quote from: claude on September 20, 2017, 08:45:14 PM

Probably the first thing to try is the central difference, which is second order. See e.g. https://en.wikipedia.org/wiki/Finite_difference.

Title: Re: compiling Kalles Fraktaler with mingw
Post by: gerrit on September 21, 2017, 02:39:11 AM

Here's a quick hack in MATLAB trying central difference and 1st order method.
Plot is $1/sqrt{||grad(map)||^2+1}$ .
Central difference seems a bit better.

Title: Re: compiling Kalles Fraktaler with mingw
Post by: gerrit on September 21, 2017, 05:31:10 AM

Interestingly going to a 4th order stencil for the gradient does not improve further.

Title: Re: compiling Kalles Fraktaler with mingw
Post by: gerrit on September 21, 2017, 11:31:31 PM

One more result: using the average of normal and diagonal central differences does improve a bit over just central. See example.
So the squared length of the gradient of map m at point x,y is taken to be the mean:
$||g||^2 = (g_x^2+g_y^2 + g_1^2 + g_2^2)/2$
with
$g_x = (m(x+1,y)-m(x-1,y))/2$
$g_y = (m(x,y+1)-m(x,y-1))/2$
$g_1 = (m(x+1,y+1)-m(x-1,y-1))/(2sqrt{2})$
$g_2 = (m(x+1,y-1)-m(x-1,y+1))/(2sqrt{2})$

(http://www.fractalforums.com/index.php?action-gallery;sa=view;id=20577)

Title: Re: compiling Kalles Fraktaler with mingw
Post by: gerrit on September 21, 2017, 11:33:00 PM

Try again posting example image...
http://www.fractalforums.com/index.php?action=gallery;sa=view;id=20577 (http://www.fractalforums.com/index.php?action=gallery;sa=view;id=20577)

Title: Re: compiling Kalles Fraktaler with mingw
Post by: claude on September 21, 2017, 11:45:38 PM

Quote from: gerrit on September 21, 2017, 11:31:31 PM

(de-quoting so the formulas appear)
$||g||^2 = (g_x^2+g_y^2 + g_1^2 + g_2^2)/2$
with
$g_x = (m(x+1,y)-m(x-1,y))/2$
$g_y = (m(x,y+1)-m(x,y-1))/2$
$g_1 = (m(x+1,y+1)-m(x-1,y-1))/(2sqrt{2})$
$g_2 = (m(x+1,y-1)-m(x-1,y+1))/(2sqrt{2})$
(end of quote)

Thanks for the formulas, its very clear.

I (hopefully) fixed your image link, you need the bbcode variant under the image on the gallery page:
(http://nocache-nocookies.digitalgott.com/gallery/20/15320_21_09_17_11_22_46.jpeg)

Top left sub-image does look a lot better, but it changes the overall tint of the image a lot too with that palette, so maybe I make the central differences a checkbox in the colouring dialog, the default would have to be disabled for backward compatibility.

Title: Re: compiling Kalles Fraktaler with mingw
Post by: gerrit on September 22, 2017, 01:02:16 AM

Quote from: claude on September 21, 2017, 11:45:38 PM

Top left sub-image does look a lot better, but it changes the overall tint of the image a lot too with that palette, so maybe I make the central differences a checkbox in the colouring dialog, the default would have to be disabled for backward compatibility.

I wouldn't take these images too seriously except to demonstrate gradient computation. MATLAB does some scaling, so if one image has a different maximum even on one pixel it will scale the color map giving a different overall tint.

FYI I loaded the .kfb file, extracted the "counts". Then pass counts through a transfer function $f_1(x)=x^p$ with p for example 0.5 or 2 (whatever looks cool). Then compute $z = 1/sqrt{1+||g||^2}}$ , then pass z through another transfer function $f_2(x)=log(x)$ (or a power, whatever looks nice). This is probably not exactly what KF does, I stole the ideas from your pseudo-de.c code (thanks!).

Title: Re: compiling Kalles Fraktaler with mingw
Post by: claude on September 22, 2017, 03:00:27 AM

Ok. I implemented it (with no transfer function before differencing, and using log(1+||g||) instead of the log(1/sqrt(1+||g||^2)) stuff, which I think mostly just adds a scaling factor).
For the averaging of the directions I tried l2 norm (like your equations) and l1 norm (sum of abs, as used by KF for the original forward difference method), they seem visually very similar https://en.wikipedia.org/wiki/Norm_(mathematics)#p-norm

Personally I don't like the results though. Ignoring the overall colour shift in the attached (seems tweaking the IterDiv setting to match one part doesn't fix all parts...), there are several points of note:

1. the 2x2 forward difference has a smoother transition from flat to boundary
2. thin axis-aligned features have a "flat" interior with linear halo on either side (see lower right hand side)
3. isolated high points have a square halo around them (visible in the yellow on orange in the middle of the lower half)
4. the 3x3 central difference higher iteration parts looks fatter and blockier (the other has finer details)

Point 2 above is the real deal-breaker for me. But having already written the code, I may as well keep it in case someone else prefers it, so it'll probably be in the next release anyway. Meanwhile I'm rendering a higher resolution version of the attached, to see how it looks with AA, maybe I'll be won over.

EDIT here's a version with 4x4 supersampling for antialiasing - I think both methods look about equal, though I slightly prefer the bottom (central derivative) version: https://mathr.co.uk/mandelbrot/2017-09-22_forward-vs-central-differences-4x4aa.png 3.7MB

Title: Re: compiling Kalles Fraktaler with mingw
Post by: gerrit on September 22, 2017, 04:09:01 AM

I agree this simple solution does not seem to deliver, it looks better at a few spots, but much worse in others. Fractal functions perhaps do not obey the usual rules of numerical methods.

I'm guessing the unwanted "holes" arise when we have, say, m(x-1)=10, m(x)=1000, m(x+1) = 10. In that case the central difference will give zero, but the 1st order forward difference will be more "correct". Perhaps some method could be devised to switch when required.

It reminds me of the switching method used in regularization, which also boils down to somehow defining the norm of the gradient of a function which is non-smooth at certain places.

For example slide 41 in
http://www.unige.ch/math/hairer60/pres/ASCHER%20bbtime.pdf (http://www.unige.ch/math/hairer60/pres/ASCHER%20bbtime.pdf)

Great that you actually implemented this, maybe it can be made to work somehow. It is a bit of a problem that you have to oversample by such large amounts to get it to look nice, esp. when making movies.

Title: Re: compiling Kalles Fraktaler with mingw
Post by: gerrit on September 22, 2017, 05:25:10 AM

Quote from: claude on September 22, 2017, 03:00:27 AM

EDIT here's a version with 4x4 supersampling for antialiasing - I think both methods look about equal, though I slightly prefer the bottom (central derivative) version: https://mathr.co.uk/mandelbrot/2017-09-22_forward-vs-central-differences-4x4aa.png 3.7MB

Thanks for the amendmend. I guess it shows not to draw conclusions from a single data point. I've mainly tried 2X2 oversampling, as that is required for any coloring method. It would be great if it could work for DE too.

Did you include the diagonal central differences? That seems right as it uses all 8 neighbours of the pixel under consideration but, perhaps problematically, not the actual pixel.

Looking forward to the new build. (And perhaps windows compile manual? Cygwin based perhaps? (If you give a finger he takes the whole hand, as the Dutch say.))

Title: Re: compiling Kalles Fraktaler with mingw
Post by: claude on September 22, 2017, 08:38:02 AM

Compiling on Windows is not my expertise, sorry - I have no Windows machines to try with - I cross compile from Debian. Maybe I should try a Windows virtual machine, I heard Microsoft makes available free (as in beer) versions for testing purposes? Or maybe you could try a Debian virtual machine, the build instructions for that OS are up to date.

I included the diagonals in the central differencing. This is the current code, where double p[3][3] contains the neighbourhood of the pixel:

Code:

switch (m_nDifferences)
{
case Differences_Central3x3:
	{
		// gerrit's central difference formula
		double gx = (p[2][1] - p[0][1]) * 0.5;
		double gy = (p[1][2] - p[1][0]) * 0.5;
		double g1 = (p[2][2] - p[0][0]) * 0.35355339059327373; // 1/(2 sqrt(2))
		double g2 = (p[2][0] - p[2][0]) * 0.35355339059327373;
		double g = sqrt(0.5 * (gx*gx + gy*gy + g1*g1 + g2*g2));
		iter = g * 2.8284271247461903;
	}
	break;
case Differences_Forward3x3:
	{
		// forward differencing in 8 directions from the target point
		double gx0 = (p[0][1] - p[1][1]);
		double gx2 = (p[2][1] - p[1][1]);
		double gy0 = (p[1][0] - p[1][1]);
		double gy2 = (p[1][2] - p[1][1]);
		double gu0 = (p[0][0] - p[1][1]) * 0.7071067811865475; // 1/sqrt(2)
		double gu2 = (p[2][2] - p[1][1]) * 0.7071067811865475;
		double gv0 = (p[2][0] - p[1][1]) * 0.7071067811865475;
		double gv2 = (p[0][2] - p[1][1]) * 0.7071067811865475;
		double g = sqrt(0.25 * (gx0*gx0 + gx2*gx2 + gy0*gy0 + gy2*gy2 + gu0*gu0 + gu2*gu2 + gv0*gv0 + gv2*gv2));
		iter = g * 2.8284271247461903;
	}
	break;
case Differences_Diagonal2x2:
	{
		// forward differencing in 2 diagonals of a 2x2 substencil
		double gu = (p[0][0] - p[1][1]) * 0.7071067811865475; // 1/sqrt(2)
		double gv = (p[0][1] - p[1][0]) * 0.7071067811865475;
		double g = sqrt(gu * gu + gv * gv);
		iter = g * 2.8284271247461903;
	}
	break;
case Differences_Traditional:
	{
		// traditional method reverse engineered from original code
		double gx = (p[0][1] - p[1][1]) * 1.414;
		double gy = (p[1][0] - p[1][1]) * 1.414;
		double gu = (p[0][0] - p[1][1]);
		double gv = (p[0][2] - p[1][1]);
		double g = fabs(gx) + fabs(gy) + fabs(gu) + fabs(gv);
		iter = g;
	}
	break;
}

A comparison is attached, without any supersampling/AA. Clockwise from top left: Traditional, Forward 3x3, Central 3x3, Diagonal 2x2

Title: Re: compiling Kalles Fraktaler with mingw
Post by: gerrit on September 22, 2017, 10:34:52 PM

I tried in MATLAB and seems the choice is between Forward3X3 and Central3X3.
Below two image examples. To me Central3X3 looks better in the first, but Forward3X3 looks better in the second.

(http://persianney.com/fractal/resa2.png)
(http://persianney.com/fractal/resb2.png)

Title: Re: compiling Kalles Fraktaler with mingw
Post by: gerrit on September 24, 2017, 09:35:43 AM

I ran some more tests comparing Central 3X3 with Forward 3X3. I rendered DE

at 1920X1080 with AA up to 9X9 (KF 2.12.2 crashed when trying to render at

19200X10800). Results are here:

http://persianney.com/fractal/de/ (http://persianney.com/fractal/de/)

Title: Re: compiling Kalles Fraktaler with mingw
Post by: claude on September 24, 2017, 02:32:25 PM

Quote from: gerrit on September 24, 2017, 09:35:43 AM

(KF 2.12.2 crashed when trying to render at 19200X10800).

The theoretical maximum image size for the 64bit version at 16x9 aspect ratio is 35664x20061, this hard limit is 2 GiB of bitmap data. The 32bit version will be limited further to 4GiB memory per process, by the size of the iteration array (8 bytes per pixel, bitmap is 3 bytes per pixel, plus at least 16 bytes per reference iteration). On my desktop (with 8GiB ram and 8GiB swap (page file)) I had no problems with a 19200x10800 test render, other than some slowness due to swapping / paging.

But there is no error checking, so if bitmap creation fails (for example due to out of memory) KF crashes :(
I added this to the bugs list so I remember to fix it.

Title: Re: compiling Kalles Fraktaler with mingw
Post by: gerrit on September 24, 2017, 05:17:59 PM

Quote from: claude on September 24, 2017, 02:32:25 PM

FYI it crashes after finishing the first reference orbit (even at zoom=1). 64 bit, 32G of RAM, MSWin7/10. Kalle's binary does not crash.

BTW it (all versions) hangs if you accidentally zoom in on the period 1 bulb.

Title: Re: compiling Kalles Fraktaler with mingw
Post by: gerrit on September 24, 2017, 07:39:48 PM

Quote from: gerrit on September 24, 2017, 05:17:59 PM

FYI it crashes after finishing the first reference orbit (even at zoom=1). 64 bit, 32G of RAM, MSWin7/10. Kalle's binary does not crash.

Correction: Kalle's binary goes into infinite loop at Ref:2 hogging 1 cpu,which is not an improvement. I tried on 2 different Windows machines.

Title: Re: compiling Kalles Fraktaler with mingw
Post by: claude on September 25, 2017, 10:16:20 PM

Quote from: gerrit on September 24, 2017, 05:17:59 PM

FYI it crashes after finishing the first reference orbit (even at zoom=1). 64 bit, 32G of RAM, MSWin7/10.

That sounds like it crashes on the first attempt to access image data, whether iteration arrays or bmp colours is hard to say without more information. This is consistent with memory allocation failures not being handled properly, the crash is probably dereferencing a null pointer.

Quote

BTW it (all versions) hangs if you accidentally zoom in on the period 1 bulb.

I can't reproduce this.

Title: Re: compiling Kalles Fraktaler with mingw
Post by: claude on September 25, 2017, 10:58:38 PM

New version 2.12.3 available at the usual https://mathr.co.uk/kf/kf.html :

- multiple differencing methods for distance colouring (thanks to gerrit)
- bugfixes to examine zoom sequence (thanks to Dinkydau and Fractal universe for reporting)
- raised reference count limit from 199 to 10000, default remains 69
- settable additional reference count in examine zoom sequence, default remains 10

Title: Re: compiling Kalles Fraktaler with mingw
Post by: Kalles Fraktaler on September 28, 2017, 02:42:43 PM

Excellent!

Title: Re: compiling Kalles Fraktaler with mingw
Post by: Kalles Fraktaler on October 01, 2017, 12:20:35 PM

Hello claude.

I found an issue and was able to store it, so that you can have a look.
The approximation yields no skipped iterations in version 2.12.3

When I try it in the second latest version I have on my machine, build at 22nd August, 91029 iterations are skipped

Title: Re: compiling Kalles Fraktaler with mingw
Post by: claude on October 01, 2017, 03:40:22 PM

Quote from: Kalles Fraktaler on October 01, 2017, 12:20:35 PM

The approximation yields no skipped iterations in version 2.12.3 When I try it in the second latest version I have on my machine, build at 22nd August, 91029 iterations are skipped

I think I know what the issue is caused by - there are 9 probe points instead of 8, with the extra one near the center. This changed when I was experimenting with many more probe points to reduce overskipping in some locations (but that just caused underskipping instead). I can try to fix it tomorrow (not at home right now). Thanks for the bug report!

Title: Coloring-Bug in actual kf Version
Post by: CFJH on October 01, 2017, 11:21:42 PM

Hallo,
I've downloaded kf from here: https://mathr.co.uk/kf/kf.html
running version 2.12.3.

Now i am makeinmg a zoomout-sequence starting from file Z000006.kfr (see attachment). Around zoomfactor E600 I am getting a coloring error. It seems, that there is a "jump" in the colormapping (see attachment kf_error.jpg).

How can I solve this ?

ps: I am running kf on Linux with wine (exists there a native Linux-version of kf).

Jürgen

Title: Re: Coloring-Bug in actual kf Version
Post by: Kalles Fraktaler on October 02, 2017, 12:56:26 PM

Quote from: CFJH on October 01, 2017, 11:21:42 PM

Hello Jürgen

Unfortunately this is a common issue that the series approximation makes too many iterations to be skipped.
I have described this situation here (as Glitch type 1): http://www.chillheimer.de/kallesfraktaler/tutorial.htm

Title: Re: Coloring-Bug in actual kf Version
Post by: claude on October 02, 2017, 02:18:14 PM

Quote from: CFJH on October 01, 2017, 11:21:42 PM

ps: I am running kf on Linux with wine (exists there a native Linux-version of kf).

KF2 will always be Windows-only, the whole thing (GUI, threads, ...) is based around Windows APIs. But it works fine in WINE (after working around some WINE issues with multithreading and bitmap size) so that's ok I think.

Title: Re: compiling Kalles Fraktaler with mingw
Post by: claude on October 02, 2017, 02:19:59 PM

Quote from: claude on October 01, 2017, 03:40:22 PM

I think I know what the issue is caused by - there are 9 probe points instead of 8, with the extra one near the center.

This wasn't it :( Debugging continues...

Title: Re: Coloring-Bug in actual kf Version
Post by: CFJH on October 02, 2017, 02:54:14 PM

Quote from: Kalles Fraktaler on October 02, 2017, 12:56:26 PM

I've tested the "no approximation" issue, but it doesn't work. The colors are still different/false. The images are absolute identically, independent the option with/no approximation. This continues on all following images (see attachment above).

Title: Re: compiling Kalles Fraktaler with mingw
Post by: Kalles Fraktaler on October 02, 2017, 04:18:14 PM

Yes, you are right.
This seems to be an issue with the transmission from double to long double, which happens at e600.
The issue seems to have been introduced in the build from 2017-07-14 and does not occur in earlier versions.

Title: Re: Coloring-Bug in actual kf Version
Post by: claude on October 02, 2017, 08:22:56 PM

Quote from: CFJH on October 01, 2017, 11:21:42 PM

How can I solve this ?

I did some bisection of versions with your test file (thanks for attaching it):
kf-2.11.1+gmp.20170508 is the last version with good output
kf-2.11.1+gmp.20170703 crashes/hangs on loading the file (some calculations seem to happen but GUI is frozen)
kf-2.11.1+gmp.20170710 is the first version with bad output

$ git diff --stat kf-2.11.1+gmp.20170508 kf-2.11.1+gmp.20170710
119 files changed, 5198 insertions(+), 64974 deletions(-)
Very big changes there, between deleting old arbitrary precision floating point implementation and making formulas be preprocessed from XML. Will be hard to find the probably small change that caused the bug...

The current issue is that the colours for "long double" are wrong. See attached - there will probably be another glitch around e4800 (not sure of the exact threshold) where it switches between "long double" and "floatexp". Looking at the palette, with iterdiv 0.03, setting offset to 993 = 1024*(1.0-0.03) makes it look better with "long double", but that makes the other types look wrong again. Still, it's a hint as to what might be wrong internally...

So there are some possible solutions:
* use 20170508 version with good output (slower, misses some features that might not be important)
* with 2.13.3 version, if your zoom starts before e4800 (ie, it never uses floatexp), you could check "use long double always" in the "special" menu, it will be slower and have wrong colours for the whole zoom out sequence, but no visible glitch
* with 2.13.3 version, if your zoom starts deeper than e4800 (ie, it uses floatexp), you could check "use floatexp always" in the "special" menu, it will be a lot slower but have correct colours for the whole zoom out sequence, with no visible glitch
* with 2.13.3 version, adjust the palette with offset 993, render using "long double always" until past the glitch, reset the palette offset and resume without "long double always". BUT this might just be a cosmetic fix that doesn't work with the movie makers using the kfb data directly.
* wait for 2.12.4 version (hopefully this week) which fixes the bug ~~(hopefully, if I can find exactly what is causing the error)~~

There was this code in the long double perturbation post processing, deleting two lines solves the problem. I don't know why that code was there...

Code:

-               if (m_nPixels[x][y]<m_nMaxIter)
-                       m_nPixels[x][y] += 1;

Title: Re: compiling Kalles Fraktaler with mingw
Post by: CFJH on October 02, 2017, 08:50:24 PM

Thanks for the info.

I've tested some versions from https://mathr.co.uk/kf/kf.html with the following result:
version result
20170710 still buggy
20170703 crash after loading the .kfr-file
20160508 ok

Title: Re: Coloring-Bug in actual kf Version
Post by: Kalles Fraktaler on October 02, 2017, 11:19:03 PM

Quote from: claude on October 02, 2017, 08:22:56 PM

Code:

-               if (m_nPixels[x][y]<m_nMaxIter)
-                       m_nPixels[x][y] += 1;

I was just going to write that I had had an issue with one iteration in long double in that gcc dll...

Title: Re: compiling Kalles Fraktaler with mingw
Post by: claude on October 02, 2017, 11:30:36 PM

Quote from: Kalles Fraktaler on October 01, 2017, 12:20:35 PM

The approximation yields no skipped iterations in version 2.12.3 When I try it in the second latest version I have on my machine, build at 22nd August, 91029 iterations are skipped

I found the issue. 0.0 was not being handled correctly in floatexp.h. For example, setting xr = xi = 0 really gave xr = xi = 1e-308 or so, which is significantly different from 0.0 at the zoom depth of that location. I made align() set the exponent to -SOMETHINGBIG when val is 0.0, and added more align() everywhere (instead of _ALIGN_(val, exp)).

With these fixes (to be released in 2.12.4 this week) your location skips 91029 iterations with the primary reference, as before.

The extra checks may make kf slightly slower, but that's better than being fast and wrong!

Title: Re: compiling Kalles Fraktaler with mingw
Post by: claude on October 06, 2017, 03:50:50 PM

kf-2.12.4 released, download available at the homepage https://mathr.co.uk/kf/kf.html

changes since 2.12.3:
- "glitch low tolerance" checkbox that can be enabled to detect glitches more aggressively (enabling it allows "Olbaid-ST-023.kfr" to render correctly, but taking 16x longer than with it disabled) (incorrect render reported by Kalles Fraktaler)
- updated program icon with transparent background and large version, and use it for child windows too
- long double off-by-one bug fixed (incorrect render reported by CFJH)
- floatexp implementation bug fixes (0.0 was implemented incorrectly) (caused a series approximation underskipping failure that was reported by Kalles Fraktaler)
- fix distance colouring grid artifacts with small zoom size by disabling "reuse center" when zoom size is not an integer (reported by gerrit)
- fix some iteration band edge artifacts (with external postprocessing of kfb map files) by increasing the smooth bailout radius from 100 to 10000 (reported by gerrit)
- ensure added references fix their corresponding pixel (suggested by Pauldelbrot) (prevents loop in auto solve glitches whereby a reference was repeatedly being added at the same location without progress being made)
- disabled "guessing" (was causing occasional randomly bright single pixels at low zoom levels, possibly a race condition?)
- build against an installed libjpeg instead of each time after clean
- fix broken complex formula reference calculations
- fix compilation warnings (now almost clean with -Wall -Wextra)
- compile as C++17 (should also still work as C++11 and C++14)
- delete bitrotten code paths for SetEvent()-based multithreading
- delete unused thread affinity setting code
- parameter data is saved as comment in image files (both PNG and JPEG)
- can load parameters from image file comments (both PNG and JPEG)
- delete obsolete VS build system
- fix "infinite waves" colouring (reported by gerrit)

Title: Re: compiling Kalles Fraktaler with mingw
Post by: Olbaid-st on October 08, 2017, 06:37:38 AM

Hi Claude.
Thank you for a great update!
I re-rendered Olbaid-ST-023 with "Glitch low tolerance" on.
https://olbaid-st.deviantart.com/art/Deep-Mandelbrot-Set-023-10-1086-695492737

Most glitches have been removed, but fine ones are still left.
The attched image compares the rendering result of Kf 2.12.4 and MandelMachine.
I have marked conspicuous ones.

Title: Re: compiling Kalles Fraktaler with mingw
Post by: claude on October 09, 2017, 05:27:32 PM

Thanks for testing!

Quote from: Olbaid-st on October 08, 2017, 06:37:38 AM

Most glitches have been removed, but fine ones are still left.

I think this is caused by not enough references being used (the default limit is 69, your location needs more than that even at small image sizes).
You should increase the limit in the iterations dialog (but this restarts rendering, unfortunately - I will add it to the todo list to make it carry on where it left off).
The limit for the limit is currently 10000 (used to be 199), it should be possible with some code restructuring to make it truly unlimited.
My old slow computer is still rendering your location at 8192x8192, around 7000 references so far, over 5 days of calculations.
I attached a cropped downscaled portion of the image, as you can see there are no visible glitches.

To export a PNG while it is still rendering (normally it waits for the image to finish rendering completely) I employ a small workaround:
* save a map file to 00001_1.kfb, save the location kfr to the same directory - this fakes a zoom out sequence
* open another separate instance of kf.exe
* in the new kf.exe load the location kfr with examine zoom sequence
* in the new kf.exe now you can adjust colours if necessary, and Save PNG works immediately

Title: Re: compiling Kalles Fraktaler with mingw
Post by: Olbaid-st on October 10, 2017, 02:55:58 PM

7000... The reference was not enough at all. (I calculated with 100) Thank you for detailed explanation and verification. I am glad that it will be possible to challenge a complicated pattern in future!

Title: Re: compiling Kalles Fraktaler with mingw
Post by: Kalles Fraktaler on October 12, 2017, 04:14:51 PM

Thanks for the update Claude.

The option of low glitch detection is very good!

Some things I noted:
Unfortunately the disabling of pixel guessing is increasing the render time...
The Newton-Raphson fails on deep simple locations, as I try to find the minibrot in the center of the attached location.

Thanks a lot!

Title: Re: compiling Kalles Fraktaler with mingw
Post by: claude on October 12, 2017, 04:48:00 PM

Quote

Unfortunately the disabling of pixel guessing is increasing the render time...

True, especially for sparse locations - but it was causing incorrect output (bright speckles visible at low zoom levels, that change on each render, probably a race condition...) that I didn't find a way to fix while keeping guessing enabled.

Maybe I make guessing a user-settable option in the next release, if I haven't fixed it properly (not until next month at the earliest, busy with other things in the meantime...).

EDIT possibly I will rework the incremental calculations and guessing entirely, perhaps using something like Diamond-Square algorithm, example:

Code:

numbers are "pass number", a pixel at pass (n+1) can be "guessed" if all 4 of its "parents" (either + or x shape, depending on parity of n) at pass n or lower have identical integer iteration count ? not sure exactly what the conditions are for guessing to be safe, I anticipate problems around the antenna and symmetrical structures (eg 4x symmetry on the way to a minibrot might incorrectly "guess" the center - perhaps make the center of the veiw always be in pass 0)...
the crucial part (and perhaps a reason for the speckles, if this is not satisfied by kf?) is that pass n must be 100% finished by all threads, before any thread can start pass (n+1)
(end EDIT)

Quote

The Newton-Raphson fails on deep simple locations, as I try to find the minibrot in the center of the attached location.

Much worse than that, loading this location gives a very bad render (see attached). Zooming in or out gives something sensible. No clue what is wrong at this stage. Thanks for the report, it is similar to the "no-newton.kfr" you posted before that is already in the known-bugs list. EDIT enabling "no approximation" (ie, disabling series approximation) makes both halves of the image wrong. again zooming in or out makes it sensible again. stranger and stranger... (end EDIT)

Title: Re: compiling Kalles Fraktaler with mingw
Post by: claude on October 12, 2017, 11:21:26 PM

Not directly related to KF, but:

I have been doing some tests with my mandelbrot-perturbator and Olbaid-ST's "Deep Zoom 023" location (see previous page in this thread). It seems the perturbator is ok with (squared magnitude) glitch threshold 1e-5, increasing it gives an identical image at 1024x1024, as can be seen here. (The last digit is the 1e-# for the glitch detection threshold, the 1e-6 has glitches at the center of the 4 big features).

Code:

$ md5sum -b *1024*.ppm # number of references needed, real/user/sys time taken (on 4-core machine underclocked to 2.3GHz to avoid thermal shutdown, approx 2mins single-core overhead before all cores are used)
5d15ffb080f48caa4e68f086db5352c9 *023-1024-3.ppm # 15346, 48m33, 164m53, 19s
5d15ffb080f48caa4e68f086db5352c9 *023-1024-4.ppm # 2928,  43m35, 148m38, 22s
5d15ffb080f48caa4e68f086db5352c9 *023-1024-5.ppm # 896,   42m44, 146m05, 19s
ba0f1f7bbc2e975963329eddafb9e26e *023-1024-6.ppm # 212,   42m07, 145m03, 29s

Note: perturbator uses the "rebasing to periodic reference near detected glitch" technique to avoid restarting iterations from scratch when adding a new reference in a glitch, this is why adding so many references is so cheap. And the technique adds the reference in the semantic center of the glitch, ie, the minibrot that caused it. Maybe it could be rendered correctly with much fewer well-chosen references, but I don't have that technology yet so this will do for now.

Title: Re: compiling Kalles Fraktaler with mingw
Post by: Kalles Fraktaler on October 15, 2017, 03:35:54 PM

Quote from: claude on October 12, 2017, 11:21:26 PM

Code:

$ md5sum -b *1024*.ppm # number of references needed, real/user/sys time taken (on 4-core machine underclocked to 2.3GHz to avoid thermal shutdown, approx 2mins single-core overhead before all cores are used)
5d15ffb080f48caa4e68f086db5352c9 *023-1024-3.ppm # 15346, 48m33, 164m53, 19s
5d15ffb080f48caa4e68f086db5352c9 *023-1024-4.ppm # 2928,  43m35, 148m38, 22s
5d15ffb080f48caa4e68f086db5352c9 *023-1024-5.ppm # 896,   42m44, 146m05, 19s
ba0f1f7bbc2e975963329eddafb9e26e *023-1024-6.ppm # 212,   42m07, 145m03, 29s

So you mean that 15346 reference took just some 15% longer than 212 references?
That is really cool, I hope you can add it in KF as well :)
That would be cool if you could do that in KF as well, reusing the start for the addition of references!

Title: Re: compiling Kalles Fraktaler with mingw
Post by: claude on October 15, 2017, 05:23:22 PM

Quote from: Kalles Fraktaler on October 15, 2017, 03:35:54 PM

So you mean that 15346 reference took just some 15% longer than 212 references?

Yes. An example might help: say you are using reference c0 and there is a glitch at iteration 12345, then the new reference c1 at the semantic center of the glitch (where z = 0, a minibrot nucleus) has period 12345 and has z = 0 at iteration 0, 12345, 24690, ... As we are at iteration 12345, we can just adjust the delta c values by (c1 - c0), and leave the delta z values the same- they are near 0 (we found a glitch, remember) and surrounding the new reference c1 which has its z 12345 at 0. By periodicity, we don't need to restart the iterations of the reference, its z is 0 after 12345 iterations anyway. So split the glitched pixels out into a separate batch with the new reference, the old reference is still used for the non-glitched pixels. So the glitch correction happens at the same time as rendering, no separate passes afterwards.

To do this effectively you get a tree structure, where references spawn child references at glitches, etc. Only the initial primary reference has series approximation applied. mandelbrot-perturbator keeps a queue of references, with 1 worker thread per cpu core. each worker grabs the next group of glitched pixels from the queue, and pushes any new glitches back into the queue. And it uses the derivative to help refine the new references, as well as for de colouring. Another thing is not computing the whole reference up front, I alternate in chunks, say 1000 reference iterations then 1000 delta iterations and so on, this avoids computing references for more iterations than necessary (and would also help with possible GPU porting - though the tree structure makes that harder). The chunk size is user adjustable, maybe I can think about trying to add something to tune it automatically (if series approximation skips relatively few iterations compared to the first glitch iteration, you want the chunk size to be bigger, if there are glitches at many closely spaced iterations you want the chunk size to be smaller)

Quote

That is really cool, I hope you can add it in KF as well :)

Well, it's a completely different approach to rendering, and that makes it very tricky to port into KF. Something for 2.13 perhaps, plenty of things to add to 2.12.x in the meantime. Otherwise

Also it uses a lot of memory - 112 bytes per pixel for double, 208 bytes per pixel for long double and floatexp, though long double could be reduced to 136 bytes if the data is packed more densely, and floatexp to 160 bytes with packing (assuming 32bits is enough for the exponent, which it almost certainly is...). this is not including the iteration output data, which is at least 11 bytes per pixel as it is in kf now, 15 bytes if you want de colouring too

Title: Re: compiling Kalles Fraktaler with mingw
Post by: Kalles Fraktaler on October 20, 2017, 09:40:33 AM

Hi Claude

Seems that perturbation does not work in "Mandelbar Celtic" formula since a couple of versions, see attachment.
Last version it worked was 4th of May...

Title: Re: compiling Kalles Fraktaler with mingw
Post by: claude on October 20, 2017, 10:42:27 AM

Quote from: Kalles Fraktaler on October 20, 2017, 09:40:33 AM

Seems that perturbation does not work in "Mandelbar Celtic" formula since a couple of versions, see attachment.

Fixed, will be in next release (probably start of November). Was a pair of typos introduced when rewriting formulas into XML definition file. Other formulas may be affected in similar ways, please audit if you have time...
Changeset for the fix: https://code.mathr.co.uk/kalles-fraktaler-2/commitdiff/652f88d8f379615b9466de157422b45a4c02454d

Title: Re: compiling Kalles Fraktaler with mingw
Post by: claude on November 02, 2017, 05:31:29 PM

https://mathr.co.uk/kf/kf.html 2.12.5 released

highlights include command line rendering and settings save/load, along with many bugfixes - full changelog on the website. see the last page of the manual for details on the command line rendering

thanks to Fractal universe, Kalles Fraktaler, Foxxie, quaz0r and gerrit for bug reports and suggestions that helped with this release.

Title: Re: compiling Kalles Fraktaler with mingw
Post by: CFJH on November 12, 2017, 09:58:26 PM

Hallo,

first thanks to claude and kalle for the great work.

But currently I've some minor problems with kf2.

First prob is the digit resolution of the variable 'zoom' in the .kfr and .jpg-files. Currently it is stored with only three digits in the mantissa, older versions use much more digits.

version 2.11.1

Code:

Re: -0.65157218235452725030768117482098390670760715019132826658222
Im: -0.47694074025720722086380813129121112613534292138926326653662
Zoom: 4.95176015714E27
Iterations: 4122

version 2.12.5

Code:

Re: -0.2281554936539618192145720140991.....
Im: 1.1151425080399373597457646363150140.....
Zoom: 1.70e3016
Iterations: 1000000

My problem is, that I've not enough disk space to render the zoom at once. first I rendered 1e2000 to 0, then 1e3000 to 1e2000 (pressing key esc at 1e2000 to stop). The images at 1e2000 are slightly different by zoom factor 0.02. Not much, but enough to see it. I think, it comes from the lower resolution of the zoom variable.

Suggestion1: when rendering the zoom out images, to enter a zoom-factor, where the rendering should stop (instead rendering to zoom-factor 0).
Suggestion1b: for my special case, I don't need the .kfb-files, but these are causing my disk space probs. A question to store them would be great (like the png and jpg-files) (making one dialog with thee checkboxes to select, what should be saved).

Prob2: On special locations kf renders endless references and comes to no end (attachment kf_references01.png).
Prob3: Lines in the rendering (kf_lines.png, tested with kf 2.12.4)

Suggestion2: The crosshair cursor is on some colors badly to see, maybe to use one with more contrast.

Title: Re: compiling Kalles Fraktaler with mingw
Post by: claude on November 13, 2017, 06:13:20 PM

Thanks for your bug reports and feature requests!

Quote from: CFJH on November 12, 2017, 09:58:26 PM

First prob is the digit resolution of the variable 'zoom' in the .kfr and .jpg-files. Currently it is stored with only three digits in the mantissa, older versions use much more digits.

Good point, I will try to fix this for the next release. Added to BUGS list. EDIT fixed, will be in next release

Quote

Suggestion1: when rendering the zoom out images, to enter a zoom-factor, where the rendering should stop (instead rendering to zoom-factor 0).
Suggestion1b: for my special case, I don't need the .kfb-files, but these are causing my disk space probs. A question to store them would be great (like the png and jpg-files) (making one dialog with thee checkboxes to select, what should be saved).

Added to TODO list. EDIT I made another dialog pop up asking whether to save KFB maps. Unfortunately this (not saving KFB) currently breaks "resume zoom sequence", trying to fix it now... EDIT2 resume sequence now works if you go through some hoops: 1. examine zoom sequence without saving KFB, but saving PNG or JPEG or both; 2. press ESC to abort when you want to stop; 3. "file->save map" to "recovery.kfb" in the output directory; 4. if the last images rendered are the same as your just saved recovery.kfb, delete them; 5. make a backup of recovery.kfb, it will be deleted by the next step; 6. resume zoom sequence should now continue from the recovery.kfb

Quote

Prob2: On special locations kf renders endless references and comes to no end (attachment kf_references01.png).
Prob3: Lines in the rendering (kf_lines.png, tested with kf 2.12.4)

Can you provide the location information (.kfr) so I can debug these? Added both to BUGS list but without the ability to reproduce chance of a fix is small. EDIT 2.12.5 should have fixed most problems with endless references EDIT2 I see simular lines when rendering a zoom out sequence, but they are corrected by the time the image is saved to disk

Quote

Suggestion2: The crosshair cursor is on some colors badly to see, maybe to use one with more contrast.

Added to TODO list. EDIT the crosshair is a built in cursor it seems, there is a custom cursor for rotation that seems to be higher contrast, so maybe I can adapt that code. But on my system (WINE on Debian) it is black with a white border, can't get much more high contrast than that! see attached

Title: Re: compiling Kalles Fraktaler with mingw
Post by: CFJH on November 18, 2017, 02:28:37 PM

Quote from: claude on November 13, 2017, 06:13:20 PM

Thanks for your bug reports and feature requests!

Good point, I will try to fix this for the next release. Added to BUGS list. EDIT fixed, will be in next release

Thx!

Quote

The Option, don't save the .kfb-files is not prio 1 for me. When it makes problems, don't change anything there.
More important to me is the option to enter a stop-zoomfactor where the zoom out sequence stops. (My computer is nearly 10 years old and I've render the zoom in parts...)

Quote

Currently I can't give a location. The problem is, that I could reproduce the problem many times, but when I save to location to an .kfr-file and reloads it, the render finishes after a few references. Maybe the problem occurs in conjunction with the images rendered before (?)

Quote

Jürgen

Title: Re: compiling Kalles Fraktaler with mingw
Post by: claude on November 22, 2017, 11:56:27 PM

Quote from: CFJH on November 18, 2017, 02:28:37 PM

Thx!The Option, don't save the .kfb-files is not prio 1 for me. When it makes problems, don't change anything there.

I think it will be useful to other people too, so I keep it. I just need to fix "resume zoom sequence" so that it will still work without the KFB maps, maybe I save a special last.kfb for the sequence just so that it is possible to resume...

Quote

More important to me is the option to enter a stop-zoomfactor where the zoom out sequence stops.

I added a feature to control how many images are saved, or whether to use the previous behavior (stop at zoom 0). This is different to setting a zoom factor, but may have the same end result. You might need a calculator to convert between number of frames and zoom factor, taking into account the per-frame zoom size. I think the formula should be:

INPUT
start at zoom (A)e(a)
end at zoom (B)e(b)
zoom size (Z)

ALGORITHM
let x = a + log10 A
let y= b + log10 B
let z = log10 Z
let n = (x - y) / z

OUTPUT
integer part of n

EXAMPLE
start 3.2e2000
end 1.4e1000
zoom size 2.0
x = 2000 + log10 3.2 = 2000.5051499783199
y = 1000 + log10 1.4 = 1000.1461280356782
z = log10 2 = 0.30102999566398114
n = (x - y) / z = 3323.1207399653053
So in this example you would set the stop frame count to 3323

I made a new "store zoom sequence" dialog, see attached - thanks for the suggestion!

Title: Re: compiling Kalles Fraktaler with mingw
Post by: claude on November 23, 2017, 08:07:57 AM

Quote from: claude on October 12, 2017, 04:48:00 PM

Quote

The Newton-Raphson fails on deep simple locations, as I try to find the minibrot in the center of the attached location.

Much worse than that, loading this location gives a very bad render (see attached). Zooming in or out gives something sensible.

I fixed both these bugs by switching from GMP mpf_t to MPFR. It may be slightly slower, but it works correctly so I guess that's the price to pay. ~~I suspect a bug in GMP's mpf_sub~~ Something was messing up the GMP data structures, maybe bug in GMP or Boost or KF, in some circumstances it seems values were not properly normalized, causing catastrophic precision loss in later operations...

Title: Re: compiling Kalles Fraktaler with mingw
Post by: CFJH on November 23, 2017, 10:30:39 PM

Hello

Thx for the stuff. The 'Stop after n images' is ok to me. :)
Is there a plan, when it will be released ?

But now I've discovered another ugly bug.
I'm running kf 2.12.5 on Suse Linux leap 42.2 with wine. When I'm creating a zoom out sequence and minimize the kf-window during the process, only black images are saved (as jpeg). On kf 2.12.4 the same image is repeated. When I show the kf-window, the images are saved ok.
See attachment.

Jürgen
www.wetterstation-porta.info

Title: Re: compiling Kalles Fraktaler with mingw
Post by: claude on November 24, 2017, 02:41:42 PM

Quote from: CFJH on November 23, 2017, 10:30:39 PM

minimize the kf-window

Yes minimizing is known to cause issues like blank frames when rendering unfortunately :( Workaround for now is "don't do that", which isn't very satisfying.

Next release will probably be some time next week.

Title: Re: compiling Kalles Fraktaler with mingw
Post by: claude on November 24, 2017, 04:31:53 PM

Actually I had some spare minutes so I uploaded the release: https://mathr.co.uk/kf/kf-2.12.6.zip https://mathr.co.uk/kf/kf-2.12.6.zip.sig no time to announce formally until next week, check the txt or pdf for changes...

Title: Re: compiling Kalles Fraktaler with mingw
Post by: CFJH on November 25, 2017, 01:50:18 PM

Hallo,

Thx for the upload.
Currently I'm testing with the version and found two bugs ...

1, I've rendered a zoom out from my test projekt. Here I found some images, that are shifted and and does'nt match to the rest. (see attachment). This is reproducable but only in the kontext when rendering the zoom out images. My setup for the test rendering was the following
- load the file "00001_1.07e2640.jpg"
- set special -> reuse reference
- set actions -> zoom size -> 32
- file -> store zoom out images
- Ignore warning about zoom factor
- in the (new) save dialog check only to store the jpg-images

ps: the problem only occurs, when 'reuse reference' is activated!

2. In the new store...-dialog the auto stop function does'nt work. Checking the checkbox and entering 5 images (for example) it does'nt stop.

Title: Re: compiling Kalles Fraktaler with mingw
Post by: claude on November 25, 2017, 07:45:58 PM

Quote from: CFJH on November 25, 2017, 01:50:18 PM

ps: the problem only occurs, when 'reuse reference' is activated!

I guess this is the same bug reported by Dinkydau that translating location doesn't work properly when reuse reference is active. I don't know what to suggest apart from "disable reuse reference", which isn't satisfying. I'll add this variation to the BUGS list soon.

Quote

2. In the new store...-dialog the auto stop function does'nt work. Checking the checkbox and entering 5 images (for example) it does'nt stop.

Oh! Bad user interface design on my part - checking the checkbox disables the number box (manual count) and uses automatic (when zoomed out) stop. I should make checking the checkbox grey out the number box or something. To use a manual count in the number box the checkbox should be unchecked.

Title: Re: compiling Kalles Fraktaler with mingw
Post by: CFJH on November 26, 2017, 12:10:00 AM

Quote from: claude on November 25, 2017, 07:45:58 PM

I've tested with some oder versions and found out, that V2.12.5 and 2.12.6 are producing the error in exact the same way. V 2.12.14 does'nt produced the error (not with the test sequence posted above - maybe at other images)

Title: Re: compiling Kalles Fraktaler with mingw
Post by: claude on November 27, 2017, 08:06:18 PM

Quote from: CFJH on November 26, 2017, 12:10:00 AM

Ok I found out a workaround:

1. launch kf
2. deselect "special -> auto solve glitches"
3. load your parameter file
4. select "special -> reuse reference"
5. select "zoom size -> 32"
6. select "store zoom out sequence"

Step 2 ensures that the primary reference at the center of the image is used, rather than the last reference calculated during glitch correction, which was way off center in this location, causing the reuse-reference view-translation bug to have visible effects.

Title: Re: compiling Kalles Fraktaler with mingw
Post by: Kalles Fraktaler on November 30, 2017, 03:29:40 PM

Sorry for not being active for a while
I downloaded the latest version and I think it is excellent that you have solved the N-R issue on very deep locations near <-2,0i>
If I may have a wish, I would like to have back the guessing function, which speeds up some locations a lot, especially when minibrots are visible.

Otherwise excellent work! :)

Title: Re: compiling Kalles Fraktaler with mingw
Post by: Fractal universe on December 01, 2017, 06:11:43 PM

I suggest a checkbox with the guessing option.

Title: Re: compiling Kalles Fraktaler with mingw
Post by: Dinkydau on December 05, 2017, 12:07:38 AM

Why was guessing removed? I think it can be done regardless of how the not guessed pixels are computed.

Title: Re: compiling Kalles Fraktaler with mingw
Post by: claude on December 05, 2017, 12:19:54 AM

There is a race condition somewhere that results in random speckles at low zoom levels (and probably others, but most visible there). Disabling guessing seemed to fix it. I'll re-enable guessing with a checkbox in the next release. EDIT implemented it. I do indeed see the big speedup with guessing enabled when large interior regions are visible.

Title: Re: compiling Kalles Fraktaler with mingw
Post by: Kalles Fraktaler on December 06, 2017, 09:21:10 PM

Quote from: claude on December 05, 2017, 12:19:54 AM

That is excellent.
Please make it available :)

Title: Re: compiling Kalles Fraktaler with mingw
Post by: claude on December 08, 2017, 01:03:34 AM

I couldn't resist to release kf-2.12.7 on 2017-12-07. Well, I almost made it on time... Changes:

* renabled guessing conditional on menu option (was disabled in 2.12.4 as enabling it made some random speckles, possibly due to a race condition) (requested by Kalles Fraktaler and Fractal universe)
* added "threads per cpu core" setting
* compiles clean with -Wwrite-strings
* even lower resolution preview for more intensive locations (suggested by Foxxie) (implemented with Adam7-style interlacing with circular sorting)
* copy (Ctrl-X) and paste (Ctrl-V) parameters from the system clipboard
* fixed hang crash bug when normalizing smooth iteration values
* use interval arithmetic ball-period method instead of box-period (speeds up Newton-Raphson zooming a bit) (idea from knighty and gerrit)

available as usual from https://mathr.co.uk/kf/kf.html

Title: Re: compiling Kalles Fraktaler with mingw
Post by: Kalles Fraktaler on December 08, 2017, 12:31:04 PM

Excellent, thanks a lot :)