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

cheers

Just checked the github issue list. I can't find any issue ever logged for anti-aliased display. I could understand it if users had requested it and the dev team said "nah, not interested" (I'd disagree but I could understand it).

What I find surprising is that the entire user base seems not to care that Pd looks hideous onscreen (except in Mac, where I guess the graphics toolkit might provide anti-aliasing for free maybe?).

hjh

@porres it has to do with the underlying drawing primitives that tk uses.
for instance for drawing antialiased lines:
on windows it uses gdi instead of gdi+, which is not able to draw using anti-aliasing
Linux uses X11/xlib directly, so there is also no anti-aliasing there

@ddw_music I could open the issue, but.I needed to know more about it as I'm clueless

thanks @seb-harmonik.ar and now for the 1 million dollar question: how and why can we make it look better then? Is it possible?

@porres I think there are 2 options:

1. Implement anti-aliasing by modifying the tk source either by implementing a "hand-rolled" antialiasing algorithm or by using more modern system drawing primitives (gdi+ or Xrender, maybe even cairo)
2. by packaging/installing a tcl extension and then modifying the pd source to call that. This is what pdl2ork does with tkpath. (and getting tkpath to work on all platforms might be the easiest route to go down for option #2 as it was already cross-platform)

personally I would say the best option would be to maintain a patch/mod for tk with hand-written antialiasing. This would ensure that it would work on all platforms, but people on low-resource platforms could still use/install the lower-resource tk.

Seems tkpath is not well supported for windows and that was why pdl2ork was only for linux!

personally I would say the best option would be to maintain
a patch/mod for tk with hand-written antialiasing.

do you mean "1."?

@porres yes. & I'm saying that tkpath was not too well-supported for a while but it could be brought back up to speed for/ported to windows & macOS
for instance, someone was still working on osx support in 2015 http://chiselapp.com/user/rene/repository/tkpath/home

Anti-aliasing on pd causes me to clean my glasses and squint a lot, just does not look right.

@oid said:

Anti-aliasing on pd causes me to clean my glasses and squint a lot, just does not look right.

There's another thread here with screenshots:

With aliasing (I guess Linux? Looks like what I see in my Ubuntu Studio system):

Anti-aliased (must be Mac):

While these aren't the same patch (the Mac one in particular is missing the closely-angled lines, see the lower-right [t f] in the Linux screenshot), it seems fairly evident to me that the cleaner lines in Mac are easier to read. I don't see any way in which the Linux screenshot is preferable.

But anti-aliasing on/off could be a startup flag.

hjh

@ddw_music said:

it seems fairly evident to me that the cleaner lines in Mac are easier to read. I don't see any way in which the Linux screenshot is preferable

You are comparing a patch with many crossing wires with one with no crossing wires, straight forward logic and zoomed in, you literally picked the hardest to read patch and the easiest to read in that thread. Also, the linux one looks resized which does not help. Here is Il pleut's patch as I redrew it and zoomed in for a fair comparison. This is on slackware, might not look as smooth, but in no way harder to read.

@oid said:

@ddw_music said:
You are comparing a patch with many crossing wires with one with no crossing wires, straight forward logic and zoomed in, you literally picked the hardest to read patch and the easiest to read in that thread.

I get what you're saying but those points are not a factor in my comparison. I'm not considering patch complexity, only the additional visual noise of the poorly drawn diagonals.

With apologies in advance: The jagged lines in Linux look like 1995. It's 2020 already. The appearance is far, far out of date.

Here is Il pleut's patch as I redrew it and zoomed in for a fair comparison. This is on slackware, might not look as smooth, but in no way harder to read.

IMO a fair comparison is: normal screen size in Linux vs normal screen size in Mac. Zooming way way in, as your snap from slackware does, also renders the comparison unfair, in the other direction.

I do realize that zooming out in Linux makes that screenshot look worse than normal scaling, but that doesn't mean normal scaling looks good. (If it looked acceptable, I wouldn't waste time posting about this.)

Tell ya what... I'll get a couple of screenshots tomorrow, when I'm in the Mac lab and post those -- default view settings from Linux vs Mac.

hjh

I also despise how linux/windows has 'bold' for default

@ddw_music said:

IMO a fair comparison is: normal screen size in Linux vs normal screen size in Mac. Zooming way way in, as your snap from slackware does, also renders the comparison unfair, in the other direction.

I am not trying to make a fair comparison, just make yours more fair, you happened to select images from my thread and tagged me, so I had all those patches at hand. I personally hate anti-aliased single pixel lines in most situations, I will take a nice high contrast single pixels line almost every time. Readability is more a function of patch layout. Here is Ingox's patch reorganized from when I was trying to make sense of it, 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,

I love that pd still looks the same as it did when I first used it something like two decades ago.

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