being reminded by a chat we just had on IRC about improving our API,
I like to pass this onto the forum for all to read.
Whenever we see something odd in our API,
especially when approaching it the 1st time,
please report it in the forum and/or IRC
and finally via an 'enhancement' bug report.
Otherwise we will not be able to see it and hence won't fix it.
Long term users usually don't see other people's use-cases
or - even worse - live with it by using a workaround.
Further more I like to encourage all of you to
openly criticize things in a constructive manner.
Whether it be my or other people's 'behavior',
JogAmp's usability in general (documentation, web pages, ...),
or it's implementation.
Please keep in mind that our resources are limited
and hence we cannot change the world in a finger snap.
Hence the 'constructive' part of your criticism could be performed
in providing a proposal (git patch/pull-request, wiki edit, etc)
which we are able to discuss and hopefully can merge later on.
Thx to the free software notion of JogAmp, this is not only possible,
but very much encouraged!
When using AWTTextureIO in the alpha version of TUER, I had to call a method with different arguments to get my textures flipped correctly. I still find that weird.
The interface com.jogamp.opengl.util.texture.TextureData.Flusher has an incorrect name and its method "flush()" too. It's not just a stream, it should be called destroy() or dispose() as it releases the native resources. Its current name seems to be inconsistent with the rest of the API.
LEDataInputStream should allow to read strings too, like in Ardor3D. Maybe I can make a pull request about that.
TextureIO fails in loading TGA files, it claims this format is unsupported, I don't remember the exact error message. Is it the expected behavior?
At least one developer had some troubles when trying to build JOGL with IDEA IntelliJ, should we support this IDE for building JOGL too?
N.B: As a French citizen and a moderator, I may have to "enforce" some laws concerning the frame in which anybody here can benefit of a certain freedom of speech. Some "unconstructive" remarks containing defamatory or insulting contents might have to be removed by myself preferably with the prior consent of some other members of the community.
Please use it as a parent,
i.e. make your new related bug entry block bug 968.
> When using AWTTextureIO in the alpha version of TUER, I had to call a method
> with different arguments to get my textures flipped correctly. I still find
> that weird.
I consider AWTTextureIO inferior to TextureIO.
The latter uses our own PNG and JPEG decoder.
Hence AWTTextureIO might not properly reflect flipped states
and it seems to have a bug in this regard.
TextureIO w/ our PNG and JPEG decoder properly reflects the flipped state
and the images are decoded into GL orientation by default.
Personally I would like to simply remove AWTTextureIO,
but this might be too harsh for some AWT users ...
> The interface com.jogamp.opengl.util.texture.TextureData.Flusher has an
> incorrect name and its method "flush()" too. It's not just a stream, it should
> be called destroy() or dispose() as it releases the native resources. Its
> current name seems to be inconsistent with the rest of the API.
> LEDataInputStream should allow to read strings too, like in Ardor3D. Maybe I
> can make a pull request about that.
Not familiar w/ this class - but sure, go ahead.
Pls provide at least one unit test (as always).
> TextureIO fails in loading TGA files, it claims this format is unsupported, I
> don't remember the exact error message. Is it the expected behavior?
Sure not. I guess our own TGA reader lacks support of 'your TGA format',
maybe some specific feature is used?.
> At least one developer had some troubles when trying to build JOGL with IDEA
> IntelliJ, should we support this IDE for building JOGL too?
I remember we have an old IDEA project file in JOGL.
IMHO it should just work when things (jar, source-attachements)
are configured correctly. I am personally not using it,
since it is not free software.
Sure, maybe an IDEA user can add a Wiki section to our general IDE Wiki page.
Some AWT users still need a "bridge" to convert AWT BufferedImage into TextureData. Personally, I wouldn't remove AWTTextureIO. My problem occurred when I was forced to port this old version of TUER from JOGL 1 to JOGL 2.
I was wrong about LittleEndianDataInput, it doesn't implement readUTF() but it allows to read some strings.
On 02/10/2014 01:38 PM, gouessej [via jogamp] wrote:
> Some AWT users still need a "bridge" to convert AWT BufferedImage into
> TextureData. Personally, I wouldn't remove AWTTextureIO. My problem occurred
> when I was forced to port this old version of TUER from JOGL 1 to JOGL 2.
IMHO this is orthogonal and solved by using
Sure .. would need a way to utilize it w/ textures.
Does AWTTextureIO provide BufferedImages ?
> I was wrong about LittleEndianDataInput, it doesn't implement readUTF() but it
> allows to read some strings.
You decide whether it is sufficient...
On 02/10/2014 03:23 PM, gouessej [via jogamp] wrote:
> AWTTextureIO is quite convenient to use whereas AWTGLPixelBuffer requires tons
> of parameters. AWTTextureIO doesn't provide BufferedImage instances but there
> is already a RFE about that.
AWTGLPixelBuffer is most versatile, requiring only necessary params
as tested in the GLJPanel use-case.
AWTTextureIO: I would like to either keep-it or remove it.
.. no 'enhancing', since it is windowing toolkit depending,
where TextureIO is not.
IMHO we could add a TextureData ctor to AWTGLPixelBuffer
to allow convenient access.
I'd like to chime in for keeping AWTTextureIO. In my uh, "use case", where I am transitioning into jogl from raw Java rendering; I can just jam a method up the rear end of the BufferedImageManager and forget about FPS. It is incredible. AWTGLPixelBuffer currently lack both documentation AND recognition (have you guys tried googling "AWTGLPIxelBuffer"? I got 10L hits.) Please at least wait till it get more traction before deprecating AWTTextureIO.
I agree with you. At first, maybe AWTTextureIO should be redesigned to use AWTGLPixelBuffer. Then, as Sven suggests, why not adding a method that returns a Texture and another one that returns TextureData into it? After that, add a constructor with less parameters into it. Finally, decide whether removing this class is still necessary. I like allowing the interoperability between UI and windowing toolkits, it's more flexible than being forced to write everything with or without NEWT.
I reproduce the bug about the TGA loader:
java.io.IOException: No suitable reader for given stream