Hi Aaron, On Monday, December 29, 2014 08:01:53 Aaron Plattner wrote: > Really? Do you have a link to a report of this, or some description of > how this happened? I could see it happen if you're running a composite > manager, but that's only because the application can render to its > redirected window as fast as it wants, but it's up to the compositor to > sample those frames at its own pace. If that's the scenario you're > thinking of, then it's just a side effect of the non-Present compositor > design.
Hmm, the initial observation was probably even older than compositing at least on our workgroups machines which had switched off compositing for a long time. Sure the observation was with a case where you render as fast as possible and where one frames amount of draw is small compared to the speed of the gpu. You can probably tell me for sure what can possibly happen. I am sitting in front of a black box that I can observe and interpret. A proof of such an interpretation is often hard to impossible. I hoped to have this already put somehow into the previous mail. No, there is nothing to track. And no I even don't think there is. If we are in render as fast as possible mode and if a new frames image supersedes the previous one and if it can be proven that this old image is not reaching the user anymore, generally, I do not see why it should be generally illegal to optimize away superfluous work. That does *not* mean that there are no valid use cases where you want to prove that every rendered frame needs to reach the end users eye, like it is the case for Marios application. Thanks Mathias
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
