glCheckError about coregl HOT 10 CLOSED

Yeah that code is kinda nasty and outdated. I don't think I put very much thought into it when I originally wrote it... I just needed some basic error checking mechanism for debugging. I definitely agree with the suggestion of reducing concatenation with SLF4J style argument passing (why aren't we using SLF4J btw @void256 ?).... not sure if I agree with the static class thing though. The issue is that the checkGLError method actually has some implementation dependent functionality... like its use of GLU and glCheckError(). This could possibly be addressed by supplying a GL instance, though. I'll look into it and see what I can come up with.

from coregl.

Ok, see commit c923761 for my solution to this problem. My CoreLogger class isn't static, but creating single instances shouldn't incur much of any performance cost, and this maintains API compatibility with all current uses of the CoreGL interface.

I also threw in basic support for SLF4J-like, high performance string concatenation in the logging methods. This can be replaced with the SLF4J implementation later if @void256 decides to add it as a dependency.

I will need to do some performance testing with VisualVM to verify, but this should definitely improve things significantly for frequent calls to checkGLError.

Let me know if you think this is acceptable @mkaring and we can close the issue.

from coregl.

That is already a great start. But I think we can improve the performance even more ;-)

The thing is: Building the output message still happens too often. Because nobody requires this message in case no error happened. Also if an error happened we may still don't need it because there is no exception to be thrown and the warning level in the logger is disabled. That also holds for the different logging output... preparing the message should only be done in case the logging level is enabled.

Also I am not sure when it comes to handing some custom string to the name of the logger. If the name is the class name, you can nicely switch specific loggers on and off before debugging, but when the name is custom generated at runtime this may not be possible very easily.

Maybe we should go with a constructor that takes a Class<?> as parameter, as so many other logging frameworks do?

from coregl.

For the lazy preparing the messages I added a pull request that contains the required changes. Tests are done and now there is 0 garbage generated by the logger in case all is fine and nothing needs logging.

from coregl.

@bgroenks96 slf4j: Yes, I would like to use that. However, in Nifty we had that discussion already and someone rejected it with the argument that it adds yet another dependency. And I have to agree. I don't think it really is necessary considering the relatively low amount of logging that we need in CoreGL. So the standard build-in logging should be sufficent even though it means that we have to add a little code by ourself.

from coregl.

@void256 If I remember correctly YOU rejected it. ;-)

from coregl.

@mkaring The new changes to CoreLogger look good. I think that will help.

The thing is: Building the output message still happens too often. Because nobody requires this message in case no error happened.

I'm not sure that's right, though. IIRC, didn't the code already do this before:
while(error != gl.GL_NO_ERROR())
.... building code

So really it should have already skipped creation of the error message if there was no error?

Either way, new set up looks good 👍

from coregl.

I made further improvements to possible varargs pollution in 393723e.

I also added a getCoreLogger(Class<?>) method as requested by @mkaring along with a CoreLogger cache from which existing loggers can be retrieved and enabled/disabled via CoreLogger.getCoreLogger(SomeClass.class).setLevel(Level.OFF)

from coregl.

I think the version of the CoreLogger is sufficient to consider this issue as resolved. Or do you see any more need for improvements?

from coregl.

Yep. I think we're good :D

from coregl.