Bug 1020 - First MSAA FBO frame on a mac osx nvidia card not antialiased
Summary: First MSAA FBO frame on a mac osx nvidia card not antialiased
Alias: None
Product: Jogl
Classification: JogAmp
Component: macosx (show other bugs)
Version: 2
Hardware: All macosx
: --- normal
Assignee: Sven Gothel
Depends on:
Blocks: 1206
  Show dependency treegraph
Reported: 2014-06-12 17:47 CEST by Andy Skinner
Modified: 2015-10-04 02:46 CEST (History)
0 users

See Also:
Type: ---
SCM Refs:
Workaround: ---

Java program to reproduce. (4.00 KB, application/octet-stream)
2014-06-12 17:47 CEST, Andy Skinner

Note You need to log in before you can comment on or make changes to this bug.
Description Andy Skinner 2014-06-12 17:47:12 CEST
Created attachment 616 [details]
Java program to reproduce.

We noticed that, on one person's Mac with an NVIDIA card, the first frame in a context is not correctly antialiased.  We create a GLJPanel, asking for 8 samples.

Any redrawing corrects it.

There are some similarities to Bug 841, though we don't get junk in the first frame.

What we do see is "partial antialiasing".  What I mean by that is that there are pixels drawn that would not have been touched with 0 samples, but which are fully colored.  It is possible this is from some other issue.

We reproduced it in the attached program.

The mac uses an "NVIDIA GeForce GT 330M OpenGL Engine".  Version: "2.1 NVIDIA-8.24.13 310.90.9.05f01".  OS X 10.9.3

When we use a GLCanvas instead of GLJPanel, the first frame is correct.
Comment 1 Sven Gothel 2014-08-30 19:33:51 CEST
Also related: Bug 975.
Comment 2 Sven Gothel 2014-08-30 20:03:46 CEST
Comparing results w/ already existing test cases:
Comment 3 Sven Gothel 2014-08-30 22:06:02 CEST

GNU/Linux NV: No artifacts (proper MSAA in 1st frame)

OSX (any version):
  - UserVertFlip: No MSAA in 1st frame
  - DefVertFlip: Incomplete MSAA in 1st frame
Comment 6 Sven Gothel 2014-08-31 04:35:36 CEST
Excessive review of our FBO MSAA blit -> FBO Sink
and GLJPanel resulted in finding no errors.

Due to result of Comment 5 (working IntelHD 4000)
I conclude this is a driver bug of OSX/Nvidia for GT650M and 320M.

Remedy would be to render the initial frame twice ..

We shall contemplate whether this is worth another quirk 
entry for OSX/Nvidia .. ?
Comment 7 Sven Gothel 2014-08-31 05:18:31 CEST
Further analysis of the OSX/NV bug shows
that this is related to a never-written FBO blit.

If initializing the FBO w/ glClear(GL_COLOR_BUFFER)
this issue goes away.

Currently we cannot inject this workaround into FBObject
since it is too low-level, i.e. we don't know when it's 
first bind operation happens - i.e. user is ready.

It is possible to inject this to the GLFBOffscreenDrawable though ..
Comment 8 Sven Gothel 2014-08-31 05:56:25 CEST
    OSX/Nvidia's FBO needs to be cleared before blitting,
    otherwise first MSAA frame lacks antialiasing.
    GLFBODrawableImpl.initialize(..) can clear
    FBObject cannot clear the buffer(s) due to it's low-level API,
    i.e. it cannot know when the first bind occurs _after_ user
    completed FBO setup (attaching buffers).
    Hence plain FBObject usage required manual injection
    of glClear(..) after setup as demonstrated in GLJPanel.
    We may need to elaborate in this case,
    i.e. add an FBObject API entry like 'fbo.postInitNotify()'.

See results:


1st Frame:


2nd Frame: