Commit graph

6 commits

Author SHA1 Message Date
Ioannis Tsakpinis a8bcb7fd25 Ported codebase to Java 1.5.
Misc OpenCL fixes and API improvements.
Changed fractal demo to use events/sync objects instead of cl/glFinish for synchronization. (untested)
2010-09-28 21:11:35 +00:00
Ioannis Tsakpinis d7ee23f9b2 Added support for OpenGL 3.0 functionality
Added support for OpenGL 3.0 context creation (MAJOR/MINOR versions, DEBUG mode, FORWARD_COMBATIBLE mode)
Added support for OpenGL 3.0 context sharing
Added support for OpenGL 3.0 extension detection
Improved support for floating point PixelFormats (ARB_color_buffer_float)
Added support for packed floating point PixelFormats (EXT_packed_float)
Added support for sRGB PixelFormats (ARB_framebuffer_sRGB)
Added support for pseudo-FORWARD_COMBATIBLE mode (deprecated functions not loaded)
Added support for EXT_direct_state_access
2008-08-19 16:46:03 +00:00
Brian Matzon bb16ec7492 updated and added license where needed 2008-04-07 18:36:09 +00:00
Elias Naur b386d2185b Added support for non-direct in glGet* style functions 2007-04-23 20:17:42 +00:00
Elias Naur d9373a798a Move null parameter checks from check classes to the generated classes, since calculateImageSize assumes the buffer being non-null 2007-04-15 19:43:35 +00:00
Elias Naur 7c6511cf66 Added support for non-direct buffers for all functions that doesn't cache the buffer address at the native side (e.g. glVertexPointer). Reasons:
1. We can now support calls like "glLight(..., ..., FloatBuffer.wrap(new float[] {...}));" without worrying about running out of direct memory heap, 
since both the FloatBuffer and the array are allocated on the java heap. Future JVMs with stack allocation support could improve this even further.
2. We avoid getting in the way of users that doesn't (yet) know why direct buffers are important.

Obviously, we'd like direct support for arrays, but non-direct buffers are a nice compromise that avoids the API bloat that results when almost all 
functions gain an overloaded versions that take arrays instead of buffers.

Notes:

1. Non-direct buffer support should not affect the performance in the direct buffer case, since the non-direct buffer code path is only activated 
when the isDirect() check fails, and we were already checking isDirect() for sanity checking.
2. When using non-direct buffers, the buffer contents (remaining() bytes) are copied to a resizable ThreadLocal cached direct buffer (which is 
resized as needed) and used instead of the non-direct buffer. Thus, performance of non-direct buffers is lower than direct buffers.
2007-04-11 17:30:13 +00:00