José Fonseca

> There's some further room for improvement on this path though, where a Call object can cache it's swizzled parameters and similar such that subsequent retrace_\* calls with that object...

BTW, I forgot to mention this, but replay speed alone might not be (or not even the most important!) -- it's important to get lean traces to start with. Especially...

Oops. Didn't meant to close.

I thought about this again, and I believe the ultimate solution is to use LLVM to JIT compile each call into x86 code, and then call them all in succession....

This feature doesn't exists, but I agree it would be useful. It wouldn't be too complicated: one would need to modify https://github.com/apitrace/apitrace/blob/a22dda1ac2f27cd014ac7a16e7b7b6ebc9f14ae1/retrace/glretrace.py#L178-L187 to generate the code to still execute `glGetQueryObject*`...

> I'll take a look into it. We were already discussing that it would be nice if queries would be executed, because we want to debug reading back values in...

As long as the warning is done using `retrace::warning` call, the error message includes the call number, and the UI will log it as any other warning when replaying. There...

Ah, yes, agreed. Reopening.

Hmm.. can this really be right? This means applications need to know in advance how many OpenGL contexts (and all their properties) they'll ever need in advance. How do things...

I don't have an explanation for this. Does this happen just when tracing this game, or any other game?