FAQ
Cover
\
Build
\
Source
\
Bugs
\
Reference
\
Libraries
\
Tools
The bugs database has moved
here
.
Bug 1413 : inconsistent anti-aliasing with OpenGL
Last modified: 2009-12-16 09:38
P
roject:
processing
trash
Version:
unspecified
Co
m
ponent:
android
book
core
libraries
pde
reference
tools
web
Status:
ASSIGNED
Resolution:
-
Pr
i
ority:
P2
Severity:
normal
Platform
All
O
S:
All
Windows
Mac OS
Linux
Other
Reporter:
jeffg
Assigned To:
fry
Attachment
Type
Created
Size
Actions
Description
: Opened: 2009-12-15 19:14
I'm not sure if a bug report was ever filed on this.. but it is based on
this thread.
http://processing.org/discourse/yabb2/YaBB.pl?num=1250870750
Antialias does not work properly in recent processing versions unless you
first do a " hint(DISABLE_OPENGL_2X_SMOOTH);" Then you can reenable it or
smooth() or whatever. If you don't disable it first, you don't get the
best AntiAlias quality.
void setup() {
size(320,240,OPENGL);
hint(DISABLE_OPENGL_2X_SMOOTH);
//hint(ENABLE_OPENGL_4X_SMOOTH); //after disabling the 2x this works fine
smooth(); // this works even better than the 4x! super-smooth! ;)
}
Additional Comment
#1 From fry 2009-12-16 06:57
Thanks for the report, nobody had bothered to post this yet, so I wasn't
aware that it was this prevalent. What hardware are you running? I also
suspect this depends heavily on the graphics hardware (thought I saw a
handful of MacBook Pros on that thread) as to the exact behavior.
The hint() vs. smooth() discrepancy is that smooth() makes the OpenGL
smoothing calls (or at least did previously), while the hint() just handles
FSAA. FSAA should almost always give better results in terms of overall
consistency (the GL smoothing calls tend to overdo it).
Additional Comment
#2 From jeffg 2009-12-16 07:51
(In reply to
comment #1
)
>
>
>
> Additional
Comment #1
From
> fry
> 2009-12-16 06:57
>
> <!--
> addReplyLink(1); //-->[reply]
>
>
>
>
> Thanks for the report, nobody had bothered to post this yet, so I
wasn't
> aware that it was this prevalent. What hardware are you running? I also
> suspect this depends heavily on the graphics hardware (thought I saw a
> handful of MacBook Pros on that thread) as to the exact behavior.
>
> The hint() vs. smooth() discrepancy is that smooth() makes the OpenGL
> smoothing calls (or at least did previously), while the hint() just handles
> FSAA. FSAA should almost always give better results in terms of overall
> consistency (the GL smoothing calls tend to overdo it).
>
>
I'm running a MacBook Pro with 10.6.2.
From what I understand and testing the bug, it's wasn't a hint() vs.
smooth() issue. Neither worked. Using "hint(DISABLE_OPENGL_4X_SMOOTH);
and "GL_LINE_SMOOTH" was just as ineffective as using smooth(). The
problem was that nothing worked correct until you first did a disable hint
for 2X_SMOOTH, then everything works fine (both hint() and smooth()).
Additional Comment
#3 From taifunbrowser 2009-12-16 09:32
So, it appears that there are in fact 4 states to opengl smoothing, where
processing assumes there are only 3:
States:
1) No antialiasing
2) Antialias, 2x
3) Antialias, 4x
4) Antialias, UNLIMITED
Where choice 2 is apparantly default, 4 is achieved by disabling #2 and
calling smooth() anyway.
Additional Comment
#4 From fry 2009-12-16 09:38
No, there are four that are covered by Processing:
1. no smoothing, via noSmooth()
2. the default, which is 2x fsaa
3. 4x fsaa, by calling hint(4X)
4. smooth() which calls gl.glEnable(GL.GL_XXXXX_SMOOTH); methods, but is
ignored when FSAA is enabled (actually now i look and see that it's only
ignored on 2x, but should also be on 4x).
This bug is now being tracked
here
.