Khronos Public Bugzilla
Bug 576 - Small fixes and enhancements
Small fixes and enhancements
Status: RESOLVED FIXED
Product: KTX
Classification: Unclassified
Component: library
unspecified
All All
: P3 minor
: ---
Assigned To: Mark Callow
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-01-18 11:54 PST by Krystian Bigaj
Modified: 2012-01-19 01:27 PST (History)
0 users

See Also:


Attachments
Patch for fixes/enhancements in this bugreport (3.23 KB, patch)
2012-01-18 11:54 PST, Krystian Bigaj
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Krystian Bigaj 2012-01-18 11:54:51 PST
Created attachment 93 [details]
Patch for fixes/enhancements in this bugreport

Patch in attachment contains some small fixes and enhancements:
- ifndef for SUPPORT_SOFTWARE_ETC_UNPACK, gives control over this flag also in compiler preprocessor (so no need to change sources to control it)
- KTX_GL_UNPACK_ALIGNMENT - to not make 'magic' value in code, and also check to not call glPixelStorei if not needed
- clean-up around ppKvd, previously if you passed '*ppKvd != 0' then you might not know if you must to free that pointer/memory or not (especially when ktxLoadTexture fails). Now *ppKvd is NULL'ed at beginning, and it will return allocated memory only if function ktxLoadTexture will succeed and there will be some key-value data (*pKvdLen > 0). At ktxLoadTexture failure you don't need to release *ppKvd as it will always points to NULL.
- if texture name was generated (by glGenTextures), but function failed, then there was a 'texture name leak' (how 'big' it could be, is dependant on implementation of OpenGL/ES API)
- conditional code for glTexParameteri with GL_GENERATE_MIPMAP, as OpenGL ES 2.0 doesn't support it (http://www.khronos.org/opengles/sdk/docs/man/xhtml/glTexParameter.xml)
Comment 1 Mark Callow 2012-01-19 01:12:28 PST
Incorporated in SVN r16638.

The only change I had any objection to is the one to only set the unpack alignment if it is not already 4. Nevertheless I have taken it.

My objection is that the thousands of users of an API should not have to do things like this. If setting a value in an API is an expensive operation the few API implementations should protect themselves to ensure they do nothing if the new value is the same as the current value. Furthermore I can't imagine that setting the unpack alignment is an expensive operation. It should merely store the value for future use.