Dear Xorg developers,
I am trying to build an application that can measure the
latency/processing time of graphics frameworks on Linux.
My idea is, for a first simple use case, to implement test programs
gradually changing the screen's color while logging timestamps using
different graphics and UI frameworks (e.g. SDL, OpenGL, Qt, ...). More
complex test programs rendering user interfaces or 3D scenes will then
be implemented in the future.
A separate measuring program should detect a pixel being updated in some
kind of framebuffer (as close to the application as possible) and log
another timestamp. This way, the actual rendering time of the test
application should be measured.
The measuring program should be independent of vblank events, as I'm
interested in the time the rendering is done, not the time users might
be able to see something.
My problem is getting the framebuffer content with the second program.
As those measurements are part of a research project, I want to make
sure to measure as exactly as possible.
Things I already tried:
1. Getting framebuffer content with fbdev or libdrm.
The problem here is that both require the programs to be run in a
terminal without an active XServer (which I would prefer due to external
validity). Additionally, fbdev is deprecated and accessing a libdrm
framebuffer with mmap seems to be supported by embedded graphics chips only.
2. Using MIT-XShm (reading a pixel with XShmGetImage)
XShm looks promising but I have not found any information regarding its
performance. It also looks like XShm gets blocked for a while when
another application (in my case the test application) is drawing
something. I assume this is due to a "LockDisplay()" call in XShmGetImage.
Additionally, XShm behaves very strangely (reading out old color values)
when the test application is rendering as fast as it can. Adding a delay
of at least 10 milliseconds between every update of the test application
seems to fix this issue. This behavior also occurs, when a compositor
(in my case compton) is running.
3. Using the Xdamage extension
Xdamage also looks very promising as its notifications arrive quite soon
(about one millisecond) after the test application finishes rendering.
However, this way it is obviously not possible to read a pixel's color,
so I can't tell if the rendering is already finished when the
XDamageNotify event arrives.
For better understanding, a visualization of my current measuring setup
can be found here: https://hci.ur.de/framework_latency_problem
My questions are:
a) What is, in your opinion, the best time to stop the measurement timer?
b) Are there other ways besides XShm and Xdamage to detect a pixel
changing its color?
c) Where does the strange delay of XShm come from?
d) Is the XDamageNotify event triggered before or after pixels are updated?
Kind regards,
Andreas
