| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
to avoid requiring native libraries at class initialization time.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Scenario
- NV / Win7 driver version 266.58's
- Caps: on-scr, rgba 8/8/8/0, accum-rgba 0/0/0/0, dp/st/ms: 16/8/0, dbl, mono
The above 'wglChoosePixelFormatARB' impl returns an array of pixelformats,
where the 1st entry is not hardware accelerated!
This should be considered a bug in NV's driver, since the array should return
a list ordered from 'best' to 'worst'.
Workaround trying explicit hw acceleration 1st, then generic, then software.
|
|
|
|
|
|
| |
Allows TestBug461OffscreenSupersamplingSwingAWT to pass on NV/Win7.
Root cause was using the requested unfixed caps (onscreen, !pbuffer)
instead of the fixed ones.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
WindowsWGLGraphicsConfiguration.create(..) ->
WindowsWGLGraphicsConfiguration.createFromCurrent(..) emphasizing that
all resources are 'current' ie locked and available.
This method is used for the external context/drawable creation only, called
while they are current.
Hence this method no more makeCurrent/release, which interfered with the
current external context state.
WindowsWGLGraphicsConfigurationFactory: Move surface locking to the right
(common) place.
|
| |
|
| |
|
| |
|
|\ |
|
| |
| |
| |
| |
| |
| |
| | |
This is a unit test for a bug that occurs on Windows
when the stencil buffer is turned on for an offscreen
buffer. This bug doesn't appear on CentOS 5.4, or in
JOGL 1.1.1.a.
|
|\ \ |
|
| |/
| |
| |
| |
| |
| |
| |
| | |
Changes the Type_Widget.java constructor to allocate a normal
buffer instead of a direct buffer. Apparently JVMs can't
allocate small direct buffers efficiently, and since Type_Widget
is called inside tight loops millions of times, we can't afford
to do it this way. This commit restores it to how it was in JOGL 1.
|
|\ \ |
|
| |/
| |
| |
| |
| |
| |
| | |
This commit adds a test case for bug 459, where
compilation of a vertex buffer fails on Windows
when the stencil cap is requested. This bug is
Windows-only; it works on Mac OS X and CentOS.
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | |
| | | |
Fixed the texture load to come from a resource stream so it'll
work when run from inside a JAR by the junit.run.* Ant tasks.
Also modified the test JAR build step to include any resource
files in the test source code directory.
|
| |/
| |
| |
| |
| |
| | |
I added a unit test for bug 417 (error loading grayscale texture
with TextureIO). The test works fine, so the bug must have been
fixed unknowingly after submission.
|
| |
| |
| |
| |
| |
| |
| |
| | |
This bug caused the right sides of GLJPanels not to render if the
panel is wider than its height (all pixels with x > height would
be black). Wrote a unit test to sense the problem by reading
an unrendered pixel back out of the frame, then fixed the typo
in GLDrawableFactoryImpl.java that caused the error.
|
| | |
|
| | |
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Added a test that draws one triangle, using both the SWT
canvas and the AWT canvas with the SWT_AWT bridge. Also
added the SWT JARs for each platform to make/lib (since
that's where antlr.jar and junit.jar were stored). Modified
the make files to build and run the new tests.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | | |
w/o whitespace)
|
| | |
| | |
| | |
| | | |
GL2ES2, GLES2, GL2ES1, GLES1
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
WGL and EGL)
- GLDrawableFactory exposes:
public final List/*GLCapabilitiesImmutable*/ getAvailableCapabilities(AbstractGraphicsDevice device)
- GLCapabilities platform specialization containing native ids (XVisual/FBConfig, PFD, EGLConfig, ..)
- GLCapabilities setPbuffer(true) disables onscreen
- Capabilities setOnscreen(true) disables pbuffer
- Capabilities implements Comparable
- *Capabilities: enhanced 'toString(..)'
- CapabilitiesChooser.chooseCapabilities:
'CapabilitiesImmutable[] available' -> 'List /*<CapabilitiesImmutable>*/ available'
- VersionApplet, GLCanvas.main, GLWindow.main, GLProfile/debug: dumps all available GLCaps
- WGLGLCapabilities: proper non-displayeble (pbuffer) pfdid handling
TODO: ES/EGL test with emulation
|
| |/
|/| |
|
| |
| |
| |
| |
| | |
On AMD/X11 the create/destroy sequence must be the same
even though this is agains the chicken/egg logic here ..
|
| | |
|
| | |
|
| |
| |
| |
| | |
drawable, awtConfig) ; Try create/destroy AbstractGraphicsDevice on EDT
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Add WindowListener.windowDestroyed()
To expose a proper window lifecycle, ie destroy-notify and destroyed,
this notification is added.
This will be used at least in unit tests, where we verify destruction.
Remove WindowImpl.windowDestroyed():
This native hook (planned to be called by native destroy notification)
is unreliable or not supported for all platforms.
NEWT relies on the pre destroy native hooks and handles the final
destroy notification itself.
|
| | |
|
| |
| |
| |
| | |
(96a0e0706258824c1dd524d4cbd7682a904b84f4)
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Similar to JFrame's closing behavior,
the following components window closing follow the new WindowClosingProtocol:
- GLCanvas
- GLJPanel
- NEWT Window, GLWindow
- NEWT NewtCanvasAWT
The implementation obeys either
1) the user value set by this interface,
2) an underlying toolkit set user value (JFrame, ..)
3) or it's default, eg. {@link #DO_NOTHING_ON_CLOSE DO_NOTHING_ON_CLOSE} within an AWT environment.
If none of the above determines the operation,
this protocol default behavior {@link #DISPOSE_ON_CLOSE DISPOSE_ON_CLOSE} shall be used.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Windows for javaws/applets.
It has been observed that for some combinations, eg:
- Windows 7 64bit (other variants may apply too)
- NVIDIA 8600M GT
- 260.99
the NVIDIA setting of 'Threaded optimization' := 'auto' (default) causes the JVM to simply crash
in case of javaws and [jnlp] applets.
'Threaded Optimization' := 'off' works reliable
'Threaded Optimization' := 'on' never works with javaws and applets on the above configuration
A user could workaround this by setting 'Threaded Optimization' := 'off',
however, this would disable many users on the spot,
since you cannot ask the average user for such a task, if she only wants to see a web page.
This patch 'fixes' the 'auto' mode by running the eager GL profile initialization
within a block of single CPU affinity:
SetProcessAffinityMask(pid, 1);
try {
initProfilesForDeviceImpl(device);
} finally {
SetProcessAffinityMask(pid, sysValue);
}
Hopefully we can remove this hack with a driver fix.
However this workaround is as little invasive as possible.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
GLProfile.initProfilesForDevice: use either desktop or egl factory on one device
GLProfile.DEBUG: Print proper factory instance, full device
JoglVersion.getGLInfo: Print only availability of used device, otherwise we could kick off initialization
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
for all launch flavors (applet/javaws/..)
|
| | |
|