From 4fcb5ddb5affc56f43ce055071cee3f826e50904 Mon Sep 17 00:00:00 2001 From: =?utf8?q?Jos=C3=A9=20Fonseca?= Date: Tue, 11 Jun 2013 16:11:40 +0100 Subject: [PATCH] Document what to expect in terms of trace size and CPU overhead. See also issue #146. --- BUGS.markdown | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/BUGS.markdown b/BUGS.markdown index 0981133..0c963f1 100644 --- a/BUGS.markdown +++ b/BUGS.markdown @@ -50,12 +50,29 @@ Tracing There is no way to distinguish the fake calls from those actually made by the application yet. +* Huge traces will be generated for applications that make extensive use of + immediate mode drawing (ie., glBegin/glEnd), use vertex/element arrays in + user memory, or generate a lot of dynamic vertex data per frame. + + However, this should not be a problem for modern OpenGL applications that + make an efficient use of VBOs and vertex shaders. + * On MacOSX, the internal OpenGL calls done by GLU are not traced yet. Retracing --------- +* Replaying can take substantially more CPU due to the overhead of reading the + trace file from disk. + + However, the overhead should not be significant for modern 3D applications + that do efficient use of VBOs and vertex shaders. The communication between + CPU to GPU can easily be a bottleneck on the powerful discrete GPUs of + nowadays, and trace overhead tend to be propotional so it is not a + coincidence that applications that are optimized for modern GPUs will also be + traced and replayed efficiently. + * glretrace needs to infer window sizes from glViewport calls, because calls that create/resize windows happen outside of OpenGL and are not traced. Therefore window will be missing if the application relies on the default -- 2.43.0