[osg-users] Minor change proposal : Blacklist usage of all unsized texture internat format

Julien Valentin julienvalentin51 at gmail.com
Wed Aug 15 07:51:00 PDT 2018


Ok
I'll do the pr you want from me 
(with this ugly patch code:

Code:

ex for Texture2D:
        if( useTexStorrage)
            extensions->glTexStorage2D( GL_TEXTURE_2D, (_numMipmapLevels >0)?_numMipmapLevels:1,
                                         _sourceFormat ? assumeSizedInternalFormat(_internalFormat,_sourceFormat) :
                                                         assumeSizedInternalFormat(_internalFormat,GL_UNSIGNED_BYTE),
                      _textureWidth, _textureHeight);
) 


just to demo good will on it but I protest:
when you break feature you say it's a "niche feature" (use differents texture units of the same Texture in different StateSets)
but when I propose to break a minor niche feature (image less texture setup), 
there's no possible discussion...



mp3butcher wrote:
> Hi Robert
> 
> Seriously?!
> Do I have to teach you benefit of using  immutable memory?
> No I will not do that...
> Rather I'd prefer you finish what you're doing and come back with more attention
> 
> Take your time to gauge next week or something because I'm really tired of monologing...
> 
> Cheers
>  
> 
> robertosfield wrote:
> > Hi Julian,
> > 
> > I have been looking through the glTexStorage changes and the
> > background to this GL feature.
> > 
> > It doesn't look like to me that glTexStorage* has any functionality
> > benefit over just using the original glTexImage* code.  Yes
> > glTexStorage is the "modern" way to do things in recent GL version
> > (now part of the core in GL4.2), and yes it's cleaner if you are
> > writing clean room code, but I can't see any actual benefit to OSG
> > users who don't have to grapple with the low level set up details.
> > 
> > At this point the cleanest thing for the OSG to do is not use
> > glTexStoage at all.  We can simplify all the code paths and make the
> > behaviours more consistent.
> > 
> > For maintaining the OSG is far better to reduce the number of separate
> > code code paths that do the same thing but in different ways.  I now
> > believe the glTexStorge merges were a step back for maintainability.
> > 
> > Is there anything that reverting all the glTexStorage changes that
> > users won't be able to do?
> > 
> > --
> > 
> > For those who want to use bleeding stuff I now think you should start
> > thinking in terms of have Vulkan as your base.  Within the year I'll
> > have a Vulkan based scene graph open sourced and heading towards 1.0.
> > So there will be a good migration path in the not too distant future.
> > The pressure on using bleeding edge features in the OSG is now far
> > lower.
> > 
> > For those who have large applications to maintain that are based on
> > the OSG then their focus is maintaining that and avoiding regressions
> > when they update to new versions of the OSG.
> > 
> > Robert.
> > _______________________________________________
> > osg-users mailing list
> > 
> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> > 
> >  ------------------
> > Post generated by Mail2Forum
> 


------------------------
Twirling twirling twirling toward freedom

------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=74533#74533







More information about the osg-users mailing list