#2545 Not all data displayed with terminal 'windows' and 'impulses' style

[Jochen Pernsteiner]

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.

[Tatsuro MATSUOKA]

I cannot reproduce the bug.

$test_dat << EOD
0 0
1 1
2 4
3 9
4 16
EOD

set terminal windows
plot $test_dat with lines
replot $test_dat with impulses

[Jochen Pernsteiner]

You have to use a file with more data points, like a 100000.

[Tatsuro MATSUOKA]

Sorry for my mistake.

set print $data
do for [i=0:100000] { print  123}
unset print

set yrange [0:140]
set terminal windows
plot $data with lines
replot $data with impulses

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

Exception code=0xc0000005 flags=0x0 at 0x00000000005A9298. Access violation - attempting to read data at address 0x0000000000000000

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)

[Tatsuro MATSUOKA]

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.

[Shigeharu TAKENO]

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.

[Shigeharu TAKENO]

According to the site:

https://docs.microsoft.com/en-US/windows/win32/sysinfo/gdi-objects

GDI handles are limited to 65536 per session.

[Bastian Märkisch]

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).

[Tatsuro MATSUOKA]

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

[Jochen Pernsteiner]

Thanks!