| Summary: | Better error reporting for DebugGL | ||
|---|---|---|---|
| Product: | [JogAmp] Jogl | Reporter: | mmce |
| Component: | opengl | Assignee: | mmce |
| Status: | RESOLVED WONTFIX | ||
| Severity: | enhancement | CC: | bienator, sgothel |
| Priority: | P5 | ||
| Version: | 2 | ||
| Hardware: | All | ||
| OS: | all | ||
| Type: | FEATURE | SCM Refs: | |
| Workaround: | --- | ||
1) all commands are in one line, no extra new line shall be issued (no sense) 2) to expensive 3) maybe .. (please make a git pull offer) (In reply to comment #1) > 1) all commands are in one line, no extra new line shall be issued (no sense) In my opinion it is not user (programmer) friendly to scroll sideways to see the actual method, which caused the exception. For Example: javax.media.opengl.GLException: Thread[AWT-EventQueue-0,6,main] glGetError() returned the following error codes after a call to glDrawElements(<int> 0xE, <int> 0x1740, <int> 0x1405, <long>): GL_INVALID_ENUM ( 1280 0x500) This message is displayed in one line in Eclipse. I have to scroll every time. It would be easier to read like this: javax.media.opengl.GLException: Thread[AWT-EventQueue-0,6,main] glGetError() returned the following error codes after a call to glDrawElements(<int> 0xE, <int> 0x1740, <int> 0x1405, <long>): GL_INVALID_ENUM ( 1280 0x500) > 2) to expensive To expensive for the exception message. Yes But shouldn't be expensive to create an extra method for returning every parameter value and than querying the all possible corresponding GLEnums. The method the corresponding GLEnums does not need to be in a party of GLException. Maybe an extra utility class. > 3) maybe .. (please make a git pull offer) You mean I should get a git clone, make all changes and refer my changes to you ? >> 1) all commands are in one line, no extra new line shall be issued (no sense) > >In my opinion it is not user (programmer) friendly to scroll sideways to see >the actual method, which caused the exception. > ( you describe that the Exception message is in one line) Ok, that makes sense, sure. >> 2) to expensive ( you describe having a method GL enum -> String ) Well, we could create such enum -> String mapping method via GlueGen, point taken. >> 3) maybe .. (please make a git pull offer) >You mean I should get a git clone, make all changes and refer my changes to you ? Yes, we live via participation. We all have our priorities in this project, so in case yours ain't mine, even though we both agree with those enhancements, it may just go under. So I am happy to help and surely will review your changes, which shall always be accompanied with unit tests. If you are willing to contribute you are very welcome and me grateful. If you have no time etc, than I understand as well. And of course, even without 'code participation' all input is very welcome, so are your reports here - thank you. I guess I will refine the 'participation' section in our Wiki after the release :) Cheers, Sven 2. is very difficult to generate. The enum values are not unique. You can't map it directly back to the enum name without telling the generator something about the semantics of the method. (and there are lots of GL functions, we don't want to do this by hand...) a possible long term goal *could* be to use java5 enums for the GL flags but this is also not trivial to do right. bit oring and api evolution are more difficult as soon java5 enums would be there. 3. can you give an example? something like position, buffer capacity or something else..? lack of resources / too little impact or benefit |
1. The error string could be broken into pieces. For example a new line just before the method call. 2. For every enum parameter a list of possible values which could have used for the method call. For example when ActiveTexture(enum target) produces an error, it could give a hint which enum has been used like "{GL_TEXTURE0, GL_TEXTURE0_ARB}". 3. When a buffer is used, it could be helpful to include state information about the buffer.