Porting apitrace

@Capehill

Thanks, iconification is ok
Have another cosmetic suggest about the title area, actually we have "glSnoop" text only, and mantain it simple is good, however perhaps you may add the version number and the release date aswell, it will be easier for understand instantanely what version of glSnoop we are using

The title area could pick the same text of the version text, like:

glSnoop 0.2 (xx.xxx.2019)

@samo79

Added for 0.3 version.

@Capehill

Yep thank you, just i see you are used the two number scheme for the year, perhaps it will better to use the extended scheme, four numbers

@samo79
Yeah, and need to add lots of (c)(r)(tm), to make whole titlebar's info to take whole screen :)

@kas1e

Lol, it end with just 2 more digits, doesn't exceed to much in term of space, and better readable

@samo79

Before adding the version string I checked some example that happened to have only 2 digits for year. Since it's possible to use 4 digits, they can be added.

However, if there are more useful things to show on title bar some day, then the version info will be moved to some other place (about window).

@Capehill
I also made some post on facebook about glSnoop, a little bit more promotion never hurt: https://www.facebook.com/groups/amigaos4

@kas1e

Thanks again for the promo.

glSnoop can now trace and profile all 106 Warp3D Nova functions. OGLES2 function support is being gradually added.

@Capehill
Yeah, i follow your commits, and build from time to time new version :)

Had to say, that i found it very good use when i need to catch shaders from gl4es : i just create a filter with just shader function(s), and use it : everything fast and fancy even to debug buffer, and i just grab the log and can see all the shaders created which actually sended to ogles2.

@Capehill
Checked latest version, all works fine seems so, as well as new RMB menu for gui version is good looking too:

@kas1e

Yep, help with requester example was appreciated.

BTW maybe adding to INFORMATION buttons gui.c:

BUTTON_Transparent, TRUE,

would be nice.

@Capehill
I have a feature request (and hope I didn't overlook it and it's inside already ):

1. delay tracing / profiling for X seconds after process start.
This could help to avoid the recording of eventually unintersting init stuff or lib internal "warm-up" phases.

2. limit tracing / profiling to Y seconds.
This could help to produce better comparable logs.

The reason for both feature-requests is that I suspect that kas1e's latest logs in the GL4ES thread are somewhat "flawed" because they weren't run long enough to "dilute" the warm-up phase of some of the lib's internals, e.g. initital internal VBO setups and such.
Thanks in advance!

@Daytona675x

It sounds doable, so I will try it when I find more free time.

@jabirulo

Thanks for the tip, added those.

@Capehill
Quote:

We probabaly have kind of the same in gui for "stop/pause", but that not very accurate will be of course, and for very exact tests not enough. But have something like STARTTIME=X and STOPTIME=x arguments will pretty help to get absolutly exact results all the time when do tests.

@kas1e

Which one is better, "stop time" or "duration" parameter? I suppose millisecond resolution would be sufficient.

@Capehill
For human "stop time" is sure easer to understand, but "duration" or anything else which will work are fine too :)

@Capehill

"It sounds doable, so I will try it when I find more free time."

Great, thanks!

"Which one is better, "stop time" or "duration" parameter?"

IMHO "duration" is better.
- more human as in "I record for X seconds"
- independent of eventual start delay

"I suppose millisecond resolution would be sufficient."

I think even seconds are sufficient for this purpose, but yes, a higher res. than msec is definitely total overkill.

@Capehill
Thanks for adding it ! I tried today's glsnoop, and while starttime/duration thing works, i found a new crash which wasn't there before. Maybe it because of newer functions added, dunno.

So, to reproduce:
1. run glsnoop with "profile" only
2. run any ogles2 app
3. press "Ctrl+c" in the shell where glsnoop running
4. You will see that glsnoop says "Terminated, patches removed" and then BAH , crash in ogles2.library with 0x00000000

I find it when test starttime/duration, where it automatically exit after duration time, so it crashes. I then start reduce test cases to see if crash related to new functionality, and as result find that it crashes just as it.

Probabaly some new function forgotten to restore, or resotred wrong, or something ?

I tried that on 3 ogles2 apps : irrlichts's 02.quake3map , foobillard++ and prototype. All of them reacts like that (but i remember there wasn't that bug, so its something about last added things)

@kas1e

It is an old issue, I think. Sometimes after patch removal, application is still making a call to wrapper. OGLES2 wrappers had a NULL pointer check because patching process (SetMethod) might fail. Nova wrappers didn't, because patching (operator=) cannot fail. Now also Nova wrappers have the check and there is some extra logging so "late callers" are seen. Hopefully it fixes the issue. I didn't see the problem with Boing demo which I usually test but FrikinShark was quite easy to crash with CTRL-C.