I suppose it's something to do with tcl/tk, but what?

cheers

@porres It doesn't bother me. Pd I use as a tool to get things done and how it looks is unimportant except for keeping patches clean and readable.
But that is my perspective.
Pd is not where this can be solved..... as @seb-harmonik.ar says.
Tk/Tcl has solutions in the pipeline, and maybe Tcl3D ...... https://wiki.tcl-lang.org/page/Alternative+Canvases can already invoke hardware acceleration in Linux through OpenGL?
David.

@oid Probably should have cleaned up the patch more. Anyhow, the screenshot looks exactly like the patch, so there are no external artifacts of the image. I definitely have the doubled line in Pd. Debian on Macbook Pro.

@ingox No matter how pretty you make your patches, I am still going to reorganize them.

Wonder if this is the reason OSX has the anti-aliasing, perhaps their video cards and HD screens have an aliasing issues with such things as simple 1 pixel lines. It could also just be Apple holding back a bit of the driver code from the open source community to make certain linux/BSD never gets quite as nice as OSX on their hardware, they seem to like to play such games, that one key bit of code that is not free and you must license from them if you want it and they only license it out in high volume and at high cost.

@oid This may also be the reason why i am so sad all the time. But now that i think of it, i get even sadder. The only bright side is the river of tears that i can row down to a place where hardware drivers are free and there is less pollution of air and water and no climate change and no illnesses anymore. If only such a place exists where this river of tears dries.

I have to admit that I forgot to get the Mac screenshot yesterday (smh).

@oid said:

free of the weird artifacts which I assumed were caused by a post screen grab resize, but could have been caused by the screen grabber itself. Lines should not be changing thickness like that, most noticed on the line between [moses] and the number box, they should be 1 pixel wide but it alternates between 1 and 2 pixels in width.

That issue is not caused by the screen grabber. It's the normal appearance of Pd for ages. See the 2nd "Modulation index" --> [*~]. (This is a png -- there are no jpg compression artifacts. This is how it really looks on my screen, in the Pd window.)

"Lines should not be changing thickness like that" -- agreed, but by that standard, then Pd's line rendering is sub-par. Lines in Pd have always been changing thickness, for as long as I've ever used it.

It's a (more-or-less) solved problem in the graphics world. FWIW here is angled-line drawing in SuperCollider (using Qt). Here, I've chosen an angle that will be maximally fuzzy. It's not great exactly but, in my opinion, less distracting than Pd's current display.

whale-av quotes seb-harmonik: "Tk/Tcl has solutions in the pipeline" ... erm... but... again, it's a solved problem. Tcl/Tk hasn't caught up with the rest of the world.

@whale-av said:

Pd I use as a tool to get things done and how it looks is unimportant except for keeping patches clean and readable.

I do understand, but I don't quite agree that appearance is completely unimportant.

For a software community to thrive over the long haul, it needs to attract new users. If new users get turned off by an outdated surface presentation, then it's harder to retain new users.

I've observed, at times, when someone points out a deficiency in Pd, the Pd community's response often downplays, or denies, or gets defensive about the deficiency. (Not always, but often enough for me to mention it.) I'm seeing that trend again here. Pd is all about lines, and the lines don't look good -- and some of the responses are "this is not important" or (oid) "I like the fact that it never changed." That's... thoroughly baffling to me.

I know it's not going to change anytime soon, because the current options are a/ wait for Tcl/Tk to catch up with modern rendering or b/ burn Pd developer cycles implementing something that Tcl/Tk will(?) eventually implement or c/ rip the guts out of the GUI and rewrite the whole thing using a modern graphics framework like Qt. None of those is good (well, c might be a viable investment in the future -- SuperCollider, around 2010-2011, ripped out the Cocoa GUIs and went to Qt, and the benefits have been massive -- but I know the developer resources aren't there for Pd to dump Tcl/Tk). But there's a big difference between "we know it's a problem but can't do much about it" vs "it's not a serious problem." The former may invite new developers to take some initiative. The latter discourages initiative. A healthy open source software community should really be careful about the latter.

hjh

@ddw_music i suppose all aesthetics are inherently based on subjective preference.
I think most pd users don't mind the aesthetic of old-guis, to the extent that it's not high priority.
Of course it would be most preferable for the user to be able to choose the aesthetic/tradeoff between looking nice and speed for low-resource platforms imo. (and "looking nice" on qt might be faster than "not looking nice" with tk, though for it to be scriptable there'd have to be a replacement for tcl as well)

@ingox Apple has gotten fairly aggravating regarding all this in recent years, part of why I gave them up about a decade ago. I still have to deal with them fairly often since my parents use Apple and I am the one that they call everytime something goes wrong. One of the really irritating things is OSX can not mount a hard drive with even a minor issue and a key piece of their HFS+ spec is proprietary, the open source HFS+ spec lacks that so the open source tools can not generally fix even minor filesystem or journal problems on an HFS+ partition. Thankfully linux can almost always mount the drive and copy most, if not all of the data off, reformat and all is well, but it is a headache. Still less of a headache than getting my parents to use linux.

@ddw_music said:

That issue is not caused by the screen grabber. It's the normal appearance of Pd for ages. See the 2nd "Modulation index" --> [*~]. (This is a png -- there are no jpg compression artifacts. This is how it really looks on my screen, in the Pd window.)

Ingox and I already confirmed that, this is a driver issue or possibly your distro's TK, if you are running linux on an apple machine, I would bet it is driver, I have never come across this issue in any linux, all my wires come out as shown in the screen grab of my redraw of Ingox's patch, nice crisp single pixel lines. This is most certainly not an issue with PureData.

@oid In the end it will also depend on screen resolution.
Text can be and usually is designed for anti-aliasing.
Diagonally drawn lines cannot always fall on a pixel that is in the correct alignment.
If I can be bothered I will post a screenshot of Pd presented in VGA, but anyone my age will remember what the old games looked like even on a mac.
David.

P.S.

@whale-av It's not 1999 and we don't party like that anymore. The line not falling on a pixel should not matter, it should adjust the staggering and grouping of the pixels to compensate, I have not seen aliasing effects like that since the early 90s. If it were a resolution issue one would see aliasing effects elsewhere, not just in pd, which the affected users may be seeing, no one has mentioned/asked that yet. I ran this computer through its supported resolutions to see if I could get aliasing, no luck, everything drew proper.

P.S. I have no idea what that image is supposed to reference, but it gave me a good chuckle.

@ddw_music @ingox what do you get if you run lsof -p $(pidof Xorg) | grep /dev/dri in a terminal?

@oid i get:

lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
      Output information may be incomplete.
Xorg    757 root  mem       CHR              226,0               12360 /dev/dri/card0
Xorg    757 root   14u      CHR              226,0      0t0      12360 /dev/dri/card0
Xorg    757 root   15u      CHR              226,0      0t0      12360 /dev/dri/card0

I have no idea what this is.

@oid:

all my wires come out as shown in the screen grab of my redraw of Ingox's patch, nice crisp single pixel lines.

and

I have not seen aliasing effects like that since the early 90s

We might be having a terminology problem here.

Graphics aliasing is: A line should ideally look like a diagonal, but instead it looks like stairsteps.

The "changing thickness" that you mentioned could be seen as one case of aliasing... but... your "nice crisp single pixel lines" are in fact aliased. You are seeing aliasing -- every day when you use Pd. (Edit: deleted a bit here, not helpful comment from me)

So, for fun:

(
u = UserView(nil, Rect(800, 200, 450, 300)).front;
u.background = Color.white;

u.drawFunc = { |view|
    var drawPort = { |x, y|
        3.do { |i|
            Pen.moveTo(Point(x, y + i))
            .lineTo(Point(x + 8, y + i))
        };
        Pen.stroke;
    };
    Pen
    .color_(Color.black)
    // integer pixels are "between" canvas pixels
    // and subject to anti-aliasing
    // by shifting the coordinates by a half pixel,
    // lines are drawn exactly on display pixels
    .translate(0.5, 0.5)
    .moveTo(106@29)
    .lineTo(130@29)
    .lineTo(135@34)
    .lineTo(135@49)
    .lineTo(106@49)
    .lineTo(106@29)
    .stroke;
    drawPort.(106, 29);
    drawPort.(106, 47);
    Pen.moveTo(117@142)
    .lineTo(157@142)
    .lineTo(157@162)
    .lineTo(117@162)
    .lineTo(117@142)
    .stroke;
    drawPort.(117, 142);
    drawPort.(117, 160);
    Pen.moveTo(109@49).lineTo(120@142).stroke;
};
u.refresh;
)

If you prefer the version on the left, that's fine. We can agree to disagree about the aesthetics. But I don't think there's any room to disagree with my assertion that the version on the left does not reflect the state-of-the-art in graphics rendering. It simply is out of date.

Would Pd benefit from a more modern graphical presentation? Yes. (Would it be a large investment of developer resources -- yeah, probably too large. So it won't happen. Doesn't mean that the current state of things is good exactly.)

@ddw_music @ingox what do you get if you run lsof -p $(pidof Xorg) | grep /dev/dri in a terminal?

I get nothing.

this is a driver issue or possibly your distro's TK

If it's a driver issue, that would be assuming that the processing chain goes something like "software requests a line to be drawn --> the request is passed along to the video driver --> video driver does (or doesn't do) anti-aliasing." I'm pretty sure that's not how it works -- especially considering that the above screenshot shows different rendering, but under the same video driver.

The distro's TK version:

$ tclsh
% info patchlevel
8.6.8

The absolute most recent seems to be 8.6.10. So I would doubt that there is a different Linux distribution where Tk's drawing is significantly improved.

So let's compare Tk's native drawing outside of Pd to Qt, borrowing a script from http://zetcode.com/gui/tcltktutorial/drawing/ :

That confirms one thing at least -- it's Tk's fault. The Tk one on the left is... like... it's 2020, why is a graphics toolkit drawing like this in 2020? Are they for real? (So, the Pd problem is that it's hitched itself to a badly out of date wagon. That might have been a good decision at the time, but Tk hasn't kept up with the modern world, and it's holding Pd back in that regard.)

hjh

@ddw_music Undoubtedly Tk is not calling os antialiasing for the os window drawing for line objects.
I still think some are comparing apples and oranges though.
Different screen resolutions, near vision ability, preference for clear jagged or smudged jagged, modern?.... all come into play.
Lines close to horizontal and vertical are the only ones that bother me personally. I spend a lot of time cleaning them up, and can be very annoyed when they go out of kilter opening a patch in another version of Pd.
I stick with my screen resolution point though.
My laptop (1440x900) obviously produces this...... aliasing.pd

and there are no intermediate pixels available.

Super Colider looks like it is using half-tone BLit stretching and although I don't think I would really like the smudging any better for such lines in Pd there is no other solution for antialiasing.
Render resolution cannot usefully surpass the pixel density unless for export.
I would expect that for some monitors there will be "gamer" card drivers that would do the same.

Except....
I would like a tool similar to the "Tidy up" edit tool....... a "Snap Cords" to align cords (not objects) horizontally and vertically when the cords are very nearly aligned already.
David.

@ingox it means you video card is actually being used by the system, /dev/drive/card0 is your video card. The standard test using lsmod or dmesg actually only checks to see if the kernel loaded the driver, does not actually tell you that it is being utilized. I have no idea where I was going with that, I think it was just 4AM logic, but I may have actually had a plan and just forgot it during sleep.

@ddw_music said:

We might be having a terminology problem here.

No, I was referring to the aliasing error shown in Ingox's screen grabs, the line changes thickness, it is not aliased properly. In my experience most people realize this given the context. With anti-aliasing you never have nice crisp single pixel lines, you have 3 or 4 pixel lines of two shades of grey depending on the angle, they are not crisp, just smooth.

If it's a driver issue

The aliasing error being a driver issue. Aliasing vs anti-aliasing is obviously a software issue.

The distro's TK version:

I meant implementation not version, the hour was late. A quick glance at the pd source, its config and the Makefile suggests there is nothing there that enables anti-aliasing for OSX, which strongly suggests that you just need to compile TK with anti-aliasing and you will have it (possibly after recompiling TK apps, did not bother to look into it to see how it works). Most likely every linux distro assumes that anyone choosing TK is doing so for speed over aesthetics, a fair assumption, so they package TK without aliasing. I did not give a thorough search of the source, just a few greps, read the readme and checked the configs help, but considering that there is not one mention of TK in the Makefile, I think it is a safe assumption. This is part of linux, distros have to consider being able to run on less than state of the art hardware.

@oid as I stated in my first comment in the thread, the reason for the disparity is the different system rendering libraries tk uses.
on osx it uses core graphics, which supports antialiasing (though I believe you can modify it at runtime with some tcl variable)
on windows it uses gdi, which does not support antialiasing and on linux it uses xlib, which also does not support antialiasing

there are no options in either pd or tk currently for enabling/disabling antialiasing. Tk renders how it will render no matter the compilation flags afaik. Antialiasing is always available on osx and always not available on the other platforms due to the nature of the system rendering primitives that tk calls

It is exactly the single pixel lines that I find objectionable.

The changing thickness seems to be an approach to the problem where the stairsteps would be of a different length, e.g.

*
 *
  *
   *
    **
      *
       *
        *
         **
           *

Frankly they both look gross to me. I think you're trying to say that the rendering in my screenshots is wrong and the above demonstration of a 1.2:1 pixel slant would be right -- but I dislike both of them.

I'm willing to consider that if I saw smoothed lines throughout Pd, I might feel like it's too much fuzz -- but I doubt it. When I tried Purr Data, my first thought was "ah, finally, lines that don't make my eyes hurt." (But then I had to abandon Purr Data because I need Gem for a class, and Gem isn't supported in Purr Data for Mac, so I couldn't use it in the school's Mac-based media classroom... so, back to vanilla.)

In a perfect world, I could choose smoothed lines and oid could choose single pixel lines, but...

seb-harmonik said:

on windows it uses gdi, which does not support antialiasing and on linux it uses xlib, which also does not support antialiasing

That's unfortunate. Kind of underscores the point about being out of date -- that will continue as long as the buck gets passed (Pd: "Line drawing is Tk's problem"; Tk: "Line drawing is xlib's problem" and xlib will have some reason not to catch up with modern line drawing). It's a shame that an important part of the computer music ecosystem get held back by dependencies that aren't catching up.

hjh

@seb-harmonik.ar I believe TK can also use XCB? No idea if that would make any difference or if it supports anti-aliasing. Thanks for pointing out your post which I seemed to have missed or forgotten.

@ddw_music Wayland and Mir will be out shortly and everything on it will likely be anti-aliased. Your distro may have them in the repositories, no idea if TK yet supports them or if it still just builds against Xlib/XCB.

Ultimately I do not care if the lines are anti-aliased or not, if I had the choice I would just accept the default.

@porres Ok I give up. Here are your smudgy lines.
It works in win7 and I don't (so far) like them.

Unfortunately it opens Pd patches and the console in a window that seems to be a fixed size on my system.
Working on it again when I have the time so please post if you solve that fixed size window problem, but it looks very much like an emulation window......
Don't blame me for any problems please.
There shouldn't be any lasting problems as it doesn't write to the registry.

Download the binary for your system here......... http://www.androwish.org/download/index.html
It contains TkPath which gives you what you want (amongst other things)..... GDI+ for windows, whatever it is for Linux.
I used "undroidwish builds from almost the same source tree" for my win64 system.... and that might not have been the best choice......?

Rename it wish86.exe (or whatever it should be for Linux) and dump it in the Pd/bin folder (AFTER MOVING THE ORIGINAL SOMEWHERE ELSE).
Open Pd.exe and Voila.

Shame about the window, but proof that it can be done in Tk and maybe for Linux TkPath could be compiled as an add-in?
David.

@ddw_music said:

That's unfortunate. Kind of underscores the point about being out of date -- that will continue as long as the buck gets passed (Pd: "Line drawing is Tk's problem"; Tk: "Line drawing is xlib's problem" and xlib will have some reason not to catch up with modern line drawing). It's a shame that an important part of the computer music ecosystem get held back by dependencies that aren't catching up.

personally I think it's tk's responsibility to update with an option for modern system libraries or implement something (or provide an option for compiling with a library like cairo or something.)
of course, as I stated above, there are already tk extensions like tkpath and the developers might just point to those as the preferred way to get modern looks.

@whale-av The window is resizable....... https://www.androwish.org/index.html/wiki?name=Beyond+AndroWish
I will update the above post above when I work out how to get the command line switch -sdlresizable into the open call from Pd..
David.