Dummt GL object

Dear forum,

Is it possible, in JOGL, to obtain a "dummy" GL object, which simply returns immediately from all methods without doing anything at all? I would find such a thing quite useful in order to profile my program and see how much CPU time it spends in my own code vs. in OpenGL proper.

I've been looking through the JavaDoc and google without finding anything, though; so providing I just haven't found it, will you consider it as a feature request instead?

Hi

I don't want to be harsh but this feature would completely defeat the purposes of the changes in the public APIs of JOGL 2.0 done for several years and it isn't necessary to profile a program using JOGL 2. Moreover, you can just profile the implementation class used at runtime, for example GL4bc in my case. Let us know whether you need some advises to profile your application but personally I would reject this kind of request for enhancement.

Why would this defeat the purpose of the API changes?  He wants an implementation of the jogl wrapper that doesn't do anything but provide the API...he wants to profile _his_code, not jogl's.  What would be the harm of providing an implementation
of say GL4bc that doesn't do anything for when you want to profile your own CPU overhead?

Harvey

Maybe you can use one of the "mock" frameworks, like e.g. mockito (http://code.google.com/p/mockito/) to dynamically create a mock of the wrapper. Although I suspect that using a profiler (yourkit, jprobe or similar) would likely give you all the metrics you need to see the "hotspots" in your application.

hharrison wrote

Why would this defeat the purpose of the API changes? He wants an implementation of the jogl wrapper that doesn't do anything but provide the API...he wants to profile _his_code, not jogl's.  What would be the harm of providing an implementation
of say GL4bc that doesn't do anything for when you want to profile your own CPU overhead?

There was a single GL interface in JOGL 1. This is no more the case in JOGL 2. Some interfaces contain the methods of the fixed pipeline, some interfaces contain the methods of the programmable pipeline, some others contain a subset of both. If JOGL 2 provides a "catchall" interface, lots of "lazy" people would use it to port their applications from JOGL 1 to JOGL 2 without using the profiles which is typically the kind of thing some of us would like to prevent as it would lead to very poor code, they would have to add tons of tests a lot less smarter than myGlProfile.isES2(). As far as I know, this is not exactly what he asks for, he wants a catchall interface that does nothing but provide the API.

A better solution would consist in providing several implementation classes working like DebugGL* and TraceGL* but with no log and doing nothing. However, what would return the JOGL methods of these dumb implementation classes? For example, what should glGenBuffers and glGenTextures do? If it always returns an error value or the same one, the application might not behave as expected if it relies on the fact that different used textures should have different ids. Do you understand that it is not as trivial as it may seem?

Finally, it is possible to filter which classes have to be profiled so I don't see the point. You can even use several class loaders to ease the measure of the CPU time and memory footprint of each "component" or "module", this is typically what is done in very large applications based on rich client platforms.

Edit.: I agree with jmaasing and I know it's doable in VisualVM at least for the memory footprint.

On 07/29/2013 09:30 PM, jmaasing [via jogamp] wrote:
> Maybe you can use one of the "mock" frameworks, like e.g. mockito
> (http://code.google.com/p/mockito/) to dynamically create a mock of the
> wrapper. Although I suspect that using a profiler (yourkit, jprobe or similar)
> would likely give you all the metrics you need to see the "hotspots" in your
> application.

We could create a dummy GL impl. object to be used,
using our gluegen wrappers .. similar to TraceGL*
but w/o calling 'downstream'.

Problem is, it won't be functional, i.e.
no glGet* etc would return sensible information - of course.
Then, we would need to know whether the GL ctx should be made current
or be mocked as well ..

We could also create a ProfileGL* pipeline w/ true functionality
to
 a) count invocations
 b) time consumed

(b) might be optional and not necessary ?

In the end .. we could create whole 'intercept' functionality
w/ framebuffer snapshots, shader code, etc ..
It 'just' depends on what the user really needs to have.
The more data we intercept and generate, the bigger the footprint
and slower the tests will become ofc.

We may want some analysis toolkit as well then ..

Maybe we can discuss this in a bug report (enhancement)
to settle and test it ?

~Sven

gouessej wrote

he wants a catchall interface that does nothing but provide the API.

I certainly don't want any new interface (catchall or not); merely an implementation of the various GL interfaces whose methods do nothing.

gouessej wrote

However, what would return the JOGL methods of these dumb implementation classes? For example, what should glGenBuffers and glGenTextures do?

I'll admit I hadn't thoroughly considered that, though. Mainly, however, because it simply wouldn't matter in my case. I would still use the main, usable GL for nearly everything, and just pass in the fake GL implementation to the main draw function when actively selected, which would be after all GL objects have been created and all glGets have been fetched.

I can see that such an overly trivial solution might not be very appetizing to have in the library, however.

jmaasing wrote

Although I suspect that using a profiler (yourkit, jprobe or similar) would likely give you all the metrics you need to see the "hotspots" in your application.

That's not exactly what I'm after, however. I want to see the cumulative CPU time spent by my code altogether (and in certain subsections, not precisely delineated by class and method boundaries, but easily identified upon entry and exit of certain functions, where I can easily check System.nanoTime()). I'm less interested in individual hotspot methods at this point.

I was considering using a java.lang.reflect.Proxy to mock the interface, but I have no clue how much overhead calls to such a proxy may entail, and how that may or may not skew my results.

Dolda2000 wrote

I certainly don't want any new interface (catchall or not); merely an implementation of the various GL interfaces whose methods do nothing.

Ok so you meant a catchall implementation or several dummy implementations of known GL interfaces.

Dolda2000 wrote

I'll admit I hadn't thoroughly considered that, though. Mainly, however, because it simply wouldn't matter in my case. I would still use the main, usable GL for nearly everything, and just pass in the fake GL implementation to the main draw function when actively selected, which would be after all GL objects have been created and all glGets have been fetched.

I can see that such an overly trivial solution might not be very appetizing to have in the library, however.

It's not up to me, Sven will have to make a decision. If we succeed in finding a smart one, why not? We could generate fake GL implementations but if your main draw function makes any test on the returned values, it won't work. A good compromise would consist in allowing to generate these fake implementations optionally when building JOGL from source so that they are not really in the library but you can use them if you need. This is typically the kind of class that I don't want to see in JOGL as it would be very tricky to take a benefit of it.