I found my old benchmark code. Sadly I don't have any old data for comparison. I tested some gnuplot versions and was not able to notice time differences across the versions, which is strange! I'm no longer using gnuplot on windows thus I can't confirm it with my code where the problem originally arose. I uploaded the numbers and the code here: https://gist.github.com/MBulli/622109e22324227a1af4af7de80834c5
I found my old benchmark code. Sadly I don't have any old data. I tested some gnuplot versions and was not able to notice time differences across the versions, which is strange! I'm no longer using gnuplot on windows thus I can't confirm it with my code where the problem originally arose. I uploaded the numbers and the code here: https://gist.github.com/MBulli/622109e22324227a1af4af7de80834c5
Thanks! Yes I'll test it. But I no longer own the machine where I set up the gnuplot buildsystem and the test code, thus it might take I while until I have time to recreate it.
The current SDK version is 19. Is there a reason why NSIS is not updating to the latest SDK? I mean technical reasons or just no time for that? I'm not familiar with the NSIS code base but would like to give it a try by myself.
I downloaded the source code and built it successfully with MinGW and kinda have a workspace in VS code to debug gnuplot.exe with gdb. The crash happens in wd2d.cpp:d2dResize(LPGW lpgw, RECT rect) at this call: lpgw->pDXGISwapChain->ResizeBuffers(0, 0, 0, DXGI_FORMAT_UNKNOWN, 0); An exception is raised here becauselpgw->pDXGISwapChain is null. It is null because in wd2d.cpp:d2dCreateDeviceSwapChainBitmap(LPGW lpgw) the call to dxgiFactory->CreateSwapChainForHwnd(g_pDirect3dDevice, lpgw->hGraph, &props,...
I downloaded the source code and built it successfully with MinGW and kinda have a workspace in VS code to debug gnuplot.exe with gdb. The crash happens in wd2d.cpp:d2dResize(LPGW lpgw, RECT rect) at this call: lpgw->pDXGISwapChain->ResizeBuffers(0, 0, 0, DXGI_FORMAT_UNKNOWN, 0); An exception is raised here becauselpgw->pDXGISwapChain is null. It is null because in wd2d.cpp:d2dCreateDeviceSwapChainBitmap(LPGW lpgw) the call to dxgiFactory->CreateSwapChainForHwnd(g_pDirect3dDevice, lpgw->hGraph, &props,...
I downloaded the source code and built it successfully with MinGW and kinda have a workspace in VS code to debug gnuplot.exe with gdb. The crash happens in wd2d.cpp:d2dResize(LPGW lpgw, RECT rect) at this call: lpgw->pDXGISwapChain->ResizeBuffers(0, 0, 0, DXGI_FORMAT_UNKNOWN, 0); An exception is raised here becauselpgw->pDXGISwapChain is null. It is null because in wd2d.cpp:d2dCreateDeviceSwapChainBitmap(LPGW lpgw) the call to dxgiFactory->CreateSwapChainForHwnd(g_pDirect3dDevice, lpgw->hGraph, &props,...
Yes I used gp540-win64-mingw.exe. What I did: > set terminal windows > plot x => The plot window shows completely white and closes immediately. gnuplot.exe exits as well. wxt and qt terminals are s working. windows terminal is not. It is the same for gnuplot.exe, wgnuplot.exe and wgnuplot_pipes.exe. I did several installs and uninstalls. In gp528-win64-mingw.exe it was still working. There is no '%APPDATA%\wgnuplot.ini' file. It does not look like a DLL mismatch problem to me. Here is the trace right...
I installed 5.4-rc2 and now the Windows terminal won't open. You can see the window opening and closing immediately. No error messages or anything. Is there a debug log file or something to provide helpful information about this issue?
Ok I only tried MSVC ... Thanks for the link!
Yes, a windows binary release would be highly appreciated! It contains a crucial bug fix for my use cases. Sadly it is not straight forward to build gnuplot from source on windows. At least, I never managed to produce a fully working binary ...
(I'm the ticket creator) It is indeed faster now. I tested it with a custom build on the current master on my machine. However, if the thread of the parent process is blocked Gnuplot is also not responsive. This seems to be an artefact of my local build.