This approach unifies much of the code handling the clean up of OpenGL graphics data, avoids lots of local mutexes and static variables that were previously required,
and enables the clean up scheme to be easily extended by users providing their own GraphicsObjectManager subclasses.
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@15130 16af8721-9629-0410-8352-f15c8da7e697
I have left the Texture::generateTextureObject functions intact as I'm not sure if/how it's used outside the core OSG. If you feel that compatibility isn't important in that area feel free to drop it.
While testing the build with OSG_USE_REF_PTR_IMPLICIT_OUTPUT_CONVERSION=OFF I found a compile error in GlyphGeometry.cpp that was entirely unrelated to the changes I've made. The fix is included in the patch.
There is one thing left to fix and that is Texture2D::SubloadCallback:
class OSG_EXPORT SubloadCallback : public Referenced
{
public:
....
virtual TextureObject* generateTextureObject(const Texture2D& texture, State& state) const
{
return osg::Texture::generateTextureObject(&texture, state.getContextID(), GL_TEXTURE_2D);
}
...
}"
git-svn-id: http://svn.openscenegraph.org/osg/OpenSceneGraph/trunk@14879 16af8721-9629-0410-8352-f15c8da7e697
"The attached file contains:
- a per-context read counter in GLBufferObject::BufferEntry
- a global client counter in BufferData
- the glue between Texture* and Image client counter
"
parameter in osg::Image. To support this Image::setData(..) now has a new optional rowLength parameter which
defaults to 0, which provides the original behaviour, Image::setRowLength(int) and int Image::getRowLength() are also provided.
With the introduction of RowLength support in osg::Image it is now possible to create a sub image where
the t size of the image are smaller than the row length, useful for when you have a large image on the CPU
and which to use a small portion of it on the GPU. However, when these sub images are created the data
within the image is no longer contiguous so data access can no longer assume that all the data is in
one block. The new method Image::isDataContiguous() enables the user to check whether the data is contiguous,
and if not one can either access the data row by row using Image::data(column,row,image) accessor, or use the
new Image::DataIterator for stepping through each block on memory assocatied with the image.
To support the possibility of non contiguous osg::Image usage of image objects has had to be updated to
check DataContiguous and handle the case or use access via the DataIerator or by row by row. To achieve
this a relatively large number of files has had to be modified, in particular the texture classes and
image plugins that doing writing.
Texture.cpp:applyTexImage2D_subload:
<code>
unsigned char* data = = (unsigned char*)image->data();
if (needImageRescale) {
// allocates rescale buffer
data = new unsigned char[newTotalSize];
// calls gluScaleImage into the data buffer
}
const unsigned char* dataPtr = image->data();
// subloads 'dataPtr'
// deletes 'data'
</code>
In effect, the scaled data would never be used.
I've also replaced bits of duplicate code in Texture1D/2D/2DArray/3D/Cubemap/Rectangle
that checks if the texture image can/should be unref'd with common functionality in
Texture.cpp.
"
no PixelBufferObject 00000000, 00000000 pbo=00000000
It's kind of annoying since there is nothing actually wrong. The message is generated from TextureRectangle::applyTexImage_subload when it fails to create a pbo, even if the Image object is not even requesting to use a pbo. This message is not generated by all the other code in TextureRectangle.cpp & Texture.cpp that also attempts to create pbo's. I've modified TextureRectangle.cpp to remove this message, so it is at least consistent with the other code."
To enable the automatic attachment of the required update callback to call osg::Image::update(..) subclasses from osg::Image will
need to implement the osg::Image::requestUpdateCall() and return true, and implement the osg::Image::update(NodeVisitor*) method to recieve the update call during the update traversal.
Removed EXT postfix of FrameBufferObject functions, and added support for checking non EXT versions frame buffer object GL functions.
Introduced usage of OSG_GL*_FEATURES to avoid some #if #else #endif code blocks.
Using a submissions from Paul Martz as a guide added perliminary GL3 support to a range of OSG classes
- Implementation of integer textures as in EXT_texture_integer
- setBorderColor(Vec4) changed to setBorderColor(Vec4d) to pass double values
as border color. (Probably we have to provide an overloading function to
still support Vec4f ?)
- new method Texture::getInternalFormatType() added. Gives information if the
internal format normalized, float, signed integer or unsigned integer. Can
help people to write better code ;-)
"
Futher changes to this submission by Robert Osfield, changed the dirty mipmap
flag into a buffer_value<> vector to ensure safe handling of multiple contexts.
"I was experiencing hard crashes of my application when using PBO's on
machines that don't support PBO's. I think osg incorrectly checks if
PBO's are supported.
I added a new method to the BufferObject::Extensions class which
returns if the "GL_ARB_pixel_buffer_object" string is supported. This
fixes the problem on my end. Machines without PBO support will
continue to work and machines with PBO support will still be able to
use it."
in incorrect texture assignment. Solution was to a compareTextureObjects() test to the Texture*::compare(..) method that
the osgUtil::Optimizer::StateSetVisitor uses to determine uniqueness.
along with support for this Texture1D, 2D, 3D, TextureCubeMap and TextureRectangle. The
new SourceFormat and SourceType parameters are only used when no osg::Image is assigned to
an osg::Texture, and main use is for render to texture effects.
Added support for --hdr option in osgprerender, which utilises the new Texture::setSourceFormat/Type() methods.
Note, this required adding a unsigned int context ID to the osg::isGLUExtensionSupported(,)
and osg::isGLExtensionSupported(,) functions. This may require reimplementation
of end user code to accomodate the new calling convention.
