I suspect that wine adds a small amount of input lag. I can feel it and see it when I run Counter Strike Global Official under wine on a window.
System is Core i7 920 oc at 3.8Ghz
Arch linux
wine 1.7.11 git
KDE 4.12 (xrender)
Radeon OSS driver
On the menu of the game, when the wine window does not have focus, while hovering my OS mouse cursor over the window, the mouse cursor of the game follows it after it 3-4 frames later. So this proves that there is an input lag of about 20-30ms or maybe more.
How can I really measure it and how can I eliminate it?
How to measure input lag on wine
Re: How to measure input lag on wine
NeK as far as I know no one in history if wine has asked this question. I can tell you in the wine test cases there is nothing that measures this. If you do find a method it would be useful.
Measuring input for lag is hard because the process of measuring will also add lag. Yes this is almost like quantum mechanises where observing is altering the results. This is why if you do find a method we will be interested.
Measuring input for lag is hard because the process of measuring will also add lag. Yes this is almost like quantum mechanises where observing is altering the results. This is why if you do find a method we will be interested.
Re: How to measure input lag on wine
Without analyzing the code, I am in no position to find that kind of a method. I ask this to the people who are already familiar (like developers of wine) with it, where maybe they have an idea of what it is producing this lag.
I have some guesses. One reason might be that there is an offscreen slow copying back and forth of the rendered frames which adds lag. Another reason might be that there is some processing lag in a (or some) wine function(s) or processes.
There are ways to measure input lag that don't involve a low level monitoring, like the one I used to do it with the two mouse cursors. In windows fullscreen those 2 cursors are completely synced when moved, but on linux wine the game's cursor lags behind considerably and with (kde) compositing on, it lags even more.
I have some guesses. One reason might be that there is an offscreen slow copying back and forth of the rendered frames which adds lag. Another reason might be that there is some processing lag in a (or some) wine function(s) or processes.
There are ways to measure input lag that don't involve a low level monitoring, like the one I used to do it with the two mouse cursors. In windows fullscreen those 2 cursors are completely synced when moved, but on linux wine the game's cursor lags behind considerably and with (kde) compositing on, it lags even more.
Re: How to measure input lag on wine
Update:
Yesterday I installed AMD Catalyst 14.1 beta driver instead of the open source radeon and I run counter strike go (wine) without compositing on KDE (opengl 3.1) and the mouse test was perfect, there was no input lag!
So it is a problem with the open source drivers or with the fullscreen or with the xrender option or a combination of them. I think it is important that we should find and fix that problem. Anyone wants to bug test it and report?
Yesterday I installed AMD Catalyst 14.1 beta driver instead of the open source radeon and I run counter strike go (wine) without compositing on KDE (opengl 3.1) and the mouse test was perfect, there was no input lag!
So it is a problem with the open source drivers or with the fullscreen or with the xrender option or a combination of them. I think it is important that we should find and fix that problem. Anyone wants to bug test it and report?
Re: How to measure input lag on wine
NeK current problem is no automated way to measure the lag on input and get somewhere near valid results. Yes the two curses one shows it to end users but its not that much help for developers to know if they are solving it or making it worse. Existing benchmarks don't target input.
We do have a list of issues.
X11 compositing performance hits are mostly how X11 is design. Dri3 and Wayland are ways out of this. Not all the performance issue might be wine.
There are sections of wine not currently designed to take advantage of multi threading. http://www.winehq.org/pipermail/wine-de ... 02446.html this for example is part of fixing up the legacy issues. Old DRI 1 and before X11 drivers did not support multi threading on opengl heck they did not support more than 1 application at a time. Yes wine is old some of its code base shows it age and causes performance hits.
We do have a list of issues.
X11 compositing performance hits are mostly how X11 is design. Dri3 and Wayland are ways out of this. Not all the performance issue might be wine.
There are sections of wine not currently designed to take advantage of multi threading. http://www.winehq.org/pipermail/wine-de ... 02446.html this for example is part of fixing up the legacy issues. Old DRI 1 and before X11 drivers did not support multi threading on opengl heck they did not support more than 1 application at a time. Yes wine is old some of its code base shows it age and causes performance hits.
