Recent changes to patches

#833 Full dashtype support for libgd terminals and improved antialiasing quality

2026-03-20T17:42:49.904000Z

status: open --> pending-accepted

#833 Full dashtype support for libgd terminals and improved antialiasing quality

2026-03-20T17:42:35.225000Z

Got it.
Thanks very much.

#833 Full dashtype support for libgd terminals and improved antialiasing quality

2026-03-20T14:43:59.208000Z

Hi @sfeam

I have attached a patch to gd.trm that adds a short description. It also includes my e-mail address, but feel free to remove it or list it exclusively if this otherwise collides with the aesthetics of the comment block.

As overall commit message, I would suggest the following, but feel free to adapt it to your preferred length. I have not included new lines in the paragraphs intentionally, so you can conveniently add them were you want them.

gd terminal:  antialiased thick lines, dash patterns, and transparent line support

Replace libgd's native thick-line rendering (which can suffers from staircasing and zebra-stripe artifacts) with a custom signed-distance-field rasterizer that supports four endcap modes (hard, butt, round, square).

Add general dash pattern support (TERM_CAN_DASH) with five built-in patterns matching the cairo terminal, plus custom dash patterns. A dash walker tracks position across PNG_vector calls so dashes follow polyline curves faithfully.  Join discs fill the wedge gap at angled polyline junctions.  A deferred endcap mechanism delays the final line cap until the path actually ends.

Introduce coordinate oversampling (initially set to 20×), matching pngcairo's approach so that sub-pixel precision is available for the SDF rasterizer and gnuplot's core layout calculations.  All libgd drawing calls convert inflated coordinates to pixel space at the API boundary.

Semi-transparent lines are rendered onto an offscreen alpha layer at full opacity using MAX compositing (most-opaque-wins), then blended onto the main image at the target alpha.  This eliminates the overlap darkening artifacts that occur when sub-segments are alpha-blended individually.

The "square" terminal option is added alongside "butt" and "rounded".

Regarding the datablock.c temp file changes:

The patch does not revert the Windows/MINGW temp file fallback, it just fixes some bugs in it. The code in command.c was already correct and did not need changes. The Windows fallback block in datablock.c (save_set_to_datablock) had copy-paste errors, probably from when it was copied from command.c. The broken code was:

GetTempPathA(sizeof(tempname), buf);       // 'buf' does not exist in this function
strcat(buf, "gnuplot-save.tmp");           // same — should be 'tempname'
fp = fopen(tempname, "wt+, ccs=UTF-8");   // 'tempname' was never filled; also dubious mode string
fp = fopen(buf, "w+");                     // second fopen silently overwrites the first

The local variable in datablock.c is called tempname, but the code referenced buf (which is the variable name used in the command.c version). There were also two conflicting fopen() calls.

The patch just fixes this by:

Fixing the variable name, making all references now consistently use tempname:
Adding the missing #include <windows.h> (guarded by #ifdef _WIN32), which is needed for GetTempPathA and PATH_MAX to resolve on Windows.

The corresponding code in command.c already uses buf consistently and includes the necessary headers. It compiles and works correctly as-is, so no changes were needed there.

I did a little research whether the tempfile fallback on Windows is still needed, and yes, apparently. tmpfile() on Windows has been broken since Vista/Windows 7. It attempts to create a file in the root of the system drive, which will fail without elevated privileges. Both fallback blocks (in datablock.c and command.c) are still needed.

#833 Full dashtype support for libgd terminals and improved antialiasing quality

2026-03-19T18:07:17.273000Z

I am truly impressed by the quality of the output.
Let's go with this version.

Could you provide one more patch to apply on top of this to give yourself credit at the top of gd.trm for this major revision (a line or two to summary the work very briefly)?
Also it would be nice if you provide an overall description to use as a commit message when I add it to the git repository. I could write something myself but you obviously know better than I do how to properly describe it.
What should the author credit of the commit read - "Sethur sethris@users.sf.net" or something else?

Tangential question: your patches contain a change to datablock.c that seems to revert a previous Windows/MINGW specific chunk of code to open a temp file. This chunk of code was originally copied from command.c. I'm not a Windows guy, so I have no idea whether either of these special-case code spots is still relevant or needed. Did you find this revesion necessary on your systems? Did you have to change the code in command.c also?

I still think the gdlib library itself would benefit from this work. I encourage you to think about contributing there eventually.

#833 Full dashtype support for libgd terminals and improved antialiasing quality

2026-03-18T21:20:03.664000Z

Update and patch:

Looking at the graphs above it was clear that something was wrong with the disk/clipped-disk (depending on the endcaps) join rendering at positions with high curvature in the sinc curves (mainly at the bottom part of the valleys). This had nothing to do with the empty-canvas rendering patch I was testing but came down to a bug in the original patch where I used integer pixel coordinate instead of pixel centers in PNG_draw_join_disc. Also, there was another bug in PNG_draw_join_disc where the alpha value was passed with libgd range convention (0-127) to PNG_SetAAPixelColor, which was expecting 0-255. This compressed the AA gradient to half the width, making the problem worse.

Both issues are fixed now. I have run the demo scripts again and found no further immediately obvious issues. I have included a new benchmark of the demo scripts (only for Linux this time, but I can do Windows as well if necessary).

In the demo scripts whose output is shown below for pngcairo and png with the new patch, I deliberately used a low sample rate to create a situation where the issue was clearly visible before.

#833 Full dashtype support for libgd terminals and improved antialiasing quality

2026-03-17T13:46:56.783000Z

Hi @sfeam

just wanted to tell you that I have a working solution for the transparency issue that uses the approach of rendering each line to a blank canvas that you have proposed. I will benchmark this again and check all the demo scripts for any regressions. If all goes well, I should be able to post a patch here soon.

Attached is a test script for transparent lines and it's output.

#833 Full dashtype support for libgd terminals and improved antialiasing quality

2026-03-15T22:00:04.563000Z

Yes there have been problems with thick lines all along. Left to itself, libgd does a really poor job with them. So gnuplot draws a thick line by filling a circular area around each point along the line. This is done by drawing the line with gdImageSetBrush() and a brush constructed to be the width requested for the line. And, as you say, this causes transparent thick lines to be way less transparent than requested because every single point leads to overlaps. So yes there is extra darkening at points where the curve crosses over itself. But unlike your dashed line algorithm, the darkening due to overlap is uniform everywhere else along the line since the overlap arises at each point along the line, not just near the segment endpoints.

And hmm, this leads me to realize that the current code could be improved by modifying the alpha component of thick lines by making transparency proportional to the line thickness. I will try that!

#833 Full dashtype support for libgd terminals and improved antialiasing quality

2026-03-15T20:10:05.317000Z

My bad, I wasn't aware that one could even choose the alpha value for line colors in Gnuplot, but apparently, this was implemented quite some time ago.

I will see if I can come up with a solution for that. Your suggestion of redering everything on a blank canvas sounds reasonable.

As a side note: Didn't the old libgd terminal also have this issue, at least with thick lines where overlaps should have happened before when rendering the segments?

#833 Full dashtype support for libgd terminals and improved antialiasing quality

2026-03-15T03:41:41.526000Z

No need to attach output. It's actually easier for me to test with kittycairo vs kittygd. That way I can run a test in side-by-side windows to compare the png and gd output rather than collecting and pairing up separate output files for display.

I'll probably apply this version after going over the code to see if there's anything that can be tightened up or abstracted.

The quality of the output is very good, with one exception that is not a deal-breaker. The algorithm used here has the imperfection that when drawing with a partially transparent line color (non-zero alpha channel), the alpha-blending is done separately for each segment of the curve rather than once for the whole curve. That means it is applied multiple times to some pixels wherever the curve crosses itself or where it is composed of overlapping shorter segments. This results in a blotchy line rather than smooth transparency. This fault exists in other terminals also (although not in cairo).
FWIW this could be avoided by first rendering with a solid-color line onto a blank canvas and then composing that entire canvas back onto the target image with the specified alpha blend parameter.

Thanks

#833 Full dashtype support for libgd terminals and improved antialiasing quality

2026-03-14T18:54:08.048000Z

If you are interested, I can upload the output of the demo scripts for the terminals: png (with patch), png (original) and pngcairo, but it would be quite large.