anti-aliasing options should be made more user friendly

Here's the UX problem:

Which option is best? The names should be ordered and named such the distinction is clear. Is Ultra Quality better than 4X? Why is Ultra under High but above 2X?

The most user friendly naming scheme should be:

• None
• Low
• Medium
• High
• Ultra

Subpixel vs supersamplign means nothing to an end-user. Let me also state I have no clue which one is best even as a code monkey currently :D

And why is no anti-aliasing default? Is the average user expected to run KiCad on a potato? The default experience of KiCad should be visually appealing, not ugh everything is jagged If performance is a concern, I would say at least Low level anti-aliasing should still be enabled and only then a user turns it off if they are using a potato PC that can somehow run OpenGL but not a shader.

added priorityundecided statusnew labels

changed the description

We should probably check which works best on different platforms (it is likely different) so we can set a platform-specific default

added prioritywishlist rendering labels and removed priorityundecided label

As a user running KiCad on what might well constitute a potato (laptop) I'm observing the greatest improvement using low (HQ AA), with diminishing returns upwards. The supersampling options lead to an unpleasant drop in frame rate when panning.

In my opinion,

1. the user should be informed that these settings exist when first starting and enabling acceleration (no need to auto-detect and prescribe an auto-detected level, the user will know soon enough and adjust the level given they know where to do that)
2. defaulting to "low" instead of "none" seems justified by the added value and initial impression,
3. if temporarily switching to "None" improves battery life of mobile devices (e.g. during travel or during debugging an installation in the field), a toolbar item could allow easier access (with a click&drag- or right-click context menu), e.g. next to "redraw screen"

We'd need to address a couple issues to default something

1. In eeschema, subpixel modes look terrible on a standard monitor. It's better on HiDPI but not great. So, right now, AA in eeschema is best with Supersampling (in OpenGL).

2. In pcbnew, subpixel modes look good and supersampling is decent but blurry.

Many cards struggle with supersampling because it requires a lot of memory.

Some cards seem unable to handle the extra SHADERS required by Subpixel modes.

So, the current setup is chosen to be most compatible (but not most beautiful).

What if we just changed it to an Off/Low/High setting?

In eeschema that could just control SSAA (i.e. don't even make subpixel an option if it doesn't work well)

In pcbnew that could try SSAA and downgrade to subpixel if the shader doesn't work (can we test for that?)

Separating which AA is available by the application is a good idea. We might even try defaulting to the built-in OpenGL Hints instead of using Supersampling at all

For pcbnew: glHint(GL_POLYGON_SMOOTH_HINT, GL_NICEST)

For eeschema/pleditor: glHint(GL_LINE_SMOOTH_HINT, GL_NICEST)

Or just use GL_LINE_HINT for everything b/c it appears to be better supported.

Some cards seem unable to handle the extra SHADERS required by Subpixel modes.

Well, if I go and finish my reporting of hardware the current "version info" print for bug reports. That could also be used to do some primitive default detection. i.e. if a video card has > 2GB of RAM, turn it on

Mainly the dialog miss more explicit sentences.

We already have so many bug reports around anti-aliasing and some other openGL stuff.

So I am not thrilled by any change in default anti-aliasing settings.

added ui label

Did !827 (merged) fix this, or is there still something to be done to make them more user-friendly?

I'm still not happy with the wording. What does supersampling even mean to the layperson? How does it compare to the new smoothing option?

I totally agree to Mark. I personally don't understand and don't care about these options.

I would like only two options: AA On/Off, there is no difference for 2x or 4x AA settings on my PC. Should I concern performance loss for higher x setting?? - this is a question I ask myself, I am a simple user.

The essential part - separate antialiasing modes for eeschema and pcbnew. ee and pcb needs to use different modes, because ee contains mostly lines, and pcbnew uses graphic objects (Seth explained something in this way in some thread, afaik). But this should be a separate issue.

The essential part - separate antialiasing modes for eeschema and pcbnew

I'm not convinced this is true anymore after the recent bugfixes to SSAA. It now looks good in both applications for me.

there is no difference for 2x or 4x AA settings on my PC

4x makes KiCad slower on my PC with only a minor change in quality, but for those with better graphics cards it might be fine. I don't think removing all the settings is the right move.

Best Performance (No AA)
Balanced (1x SMAA)
High Quality (2x SSAA)
Ultra Quality (4x SSAA)

I'd put the the details in parentheses like that for the power users. And just use Conservative SMAA, I figure most people who'd care about the difference between Aggressive/Conservative have a GPU that can run 2x SSAA anyway. There is also no performance difference between the two SMAA modes, so this way there is a simple performance/quality tradeoff.

assigned to @sethhillbrand

changed milestone to %6.0.0-rc1

I have this mostly finished from last week. Will have it pushed later

/label: statusin-progress

added statusin-progress label and removed statusnew label

closed with commit 4c293e09

@sethhillbrand should have done a video game thing and just labeled x4 as ultra quality

There is no performance benefit from "Conservative" over "Aggressive" SMAA, so it's not really "Balanced" compared to "Fast". Aggressive just rounds things out more, but I would actually call it "worse" quality, just smoother. And unfortunately people are drawn to "Balanced".

added statusfix-committed label and removed statusin-progress label

mentioned in commit 0a31e2d4