OS: Windows 10 (64 bit)
Gnuplot version: 5.4.4
With data of a certain size, using terminal 'windows' (both backend 'GDI+' and 'Direct2D') and using style 'impulses', not all data is displayed.
Example:
I created a file 'data.txt' with 100000 (10^5) lines with the same value 123 on every line.
I then plotted it with wgnuplot like this:
set terminal windows
plot "data.txt" with lines
replot "data.txt" with impulses
The result is the appended image.
With the 'lines' style the data is plotted completely.
With the 'impulses' style data points are missing.
Depending on the data, this bug shows up or not. Displaying data with the same value for all data points is definitively buggy.
Another thing:
If I plot the file with 'impulses' style first, and then replot it with 'lines' style, the 'lines' plot does not show up at all! Not even the label! But when I zoom in, then at a certain zoom level the 'lines' plot shows up too.
I cannot reproduce the bug.
You have to use a file with more data points, like a 100000.
Sorry for my mistake.
The above script reproduces a bug.
I have tested another situation.
I tried to test on 5.5 (development version) and 5.2.8.
On 5.5, the results are the same.
On 5.2.8, gnuplot hangs with the error below
On 5.4.4, I have tried on other terminals.
wxt: works as expected.
qt : 'plot "data.txt" with lines' works but hang with the following message.
QWindowsPipeWriter: asynchronous write failed. (pCv?I?????B)
Last edit: Tatsuro MATSUOKA 2022-08-28
I have tested also on gnuplot-5.4.4 (built by myself) on Ubuntu 22.04 on WSL2.
For x11, wxt, and qt terminal, the sciprt works as expected.
The above phenomena seem to be Windows specific.
Please add the following line:
set arrow from 65535,0 to 65535,140 lt 0 lw 3
I think the plot may stop at x=65535. If we change 100000 to 200000, the position does not change. On the other hand,
print $data[99999]
returns 123 correctly. So, $data has 100000 data correcty, but the win term may stop the drawing at 65535, which is unsigned short (2byte) int limit.
According to the site:
https://docs.microsoft.com/en-US/windows/win32/sysinfo/gdi-objects
GDI handles are limited to 65536 per session.
Please note that the "windows" terminal internally has three variants "GDI", "GDI+", and "Direct2D". In version 5.4 releases, only the GDI+ and D2D variants are included, with the modern D2D being the default. But the problem is not within the plotting code itself. Also, we do not exceed the GDI handle limit (we only use very few).
The culprit seems to be that the memory management of the internal list of drawing commands uses Local* heap family of functions which stem from the Windows 16 bit era and are deprecated unless required for some APIs like DDE/OLE/clipboard. I had written a patch to replace those with normal C memory functions, but did not apply anything until now. Please test the "win-localalloc" branch in my SF gnuplot fork:
git clone git://git.code.sf.net/u/markisch/gnuplot gnuplot-bm
(Only the first two of the three patches may be related).Jochen
I have uoloaded a new binary package for development version.
That includes the commits [fb6c86] and [aa2b9d] .
http://tmacchant33.starfree.jp/gnuplot_bin.html
Related
Commit: [aa2b9d]
Commit: [fb6c86]
Thanks!