search

tildearrow / kwin-lowlatency

archived - X11 full-screen unredirection and lots'a settings for KWin
373 stars 10 forks source link

Black Frame Insertion support to reduce motion blur ? #86

Closed fuzun closed 3 years ago

fuzun commented 4 years ago

Hello, I have just come across to this project. I believe that it has a lot of potential.

Would you be interested in supporting black frame insertion to reduce motion blur? It is very beneficial for high frequency displays.

The most used and basic black frame insertion is inserting one black frame for each rendered frame. However, there are a lot of other configuration that many people are unaware of. There are also burn-in problems which is caused by specific configurations.

A while ago I tried to create a basic API for easily integrating black frame insertion into software. You can take a look to it: https://github.com/fuzun/strobe-api. If you use Windows, you can try this software: https://github.com/fuzun/desktopbfi.

tildearrow commented 4 years ago

Hmmm... The problem is that to implement this I may have to halve the applications' frame rate as well, and I am not sure if that is possible... at all...

fuzun commented 4 years ago

I don't think you have to. You just don't care about the the other half. The easiest way of showing black frames is by putting a black overlay with size of screen resolution. I don't know how it can be achieved though as Im not familiar with Linux internals. But Im sure that it must be very easy, especially for you. One thing we must avoid is breaking synchronization. The project I linked works frame basis and is very sensitive to frame delays etc. It assumes there is a perfect vsync going on. (This project handles that very properly, so any black frame insertion would work good) So to not break synchronization difference between code execution time of showing rendered and black frame should ideally be minimum if not the same. BFI implementation must have minimum overhead. I know that admin of blurbusters forum tried/tries to find a way to create a BFI implementation that works not by frame based but by gpu's vsync timing based (nanosecond level?). He was trying to look undocumented gpu driver apis to check if there is such api that could provide this information. I'm not sure if he found one but Im currently unaware of such implementation existing.

tildearrow commented 4 years ago

One thing we must avoid is breaking synchronization. The project I linked works frame basis and is very sensitive to frame delays etc. It assumes there is a perfect vsync going on. (This project handles that very properly, so any black frame insertion would work good)

Yep. The problem is that specific actions (such as minimizing/maximizing windows or raising focus) cause the compositor to take too long, therefore introducing stutter and breaking the black frame insertion workflow.

This can be sort of implemented using a KWin effect.

fuzun commented 4 years ago

Since it's like introducing discrete PWM signal, stuttering would cause problem only when it's happening. It's not like when there is stuttering the whole experience is ruined. Users know about this and they will accept this situation if they want to enable bfi. And if these specific actions don't take longer than 1/hz seconds they may be benign for BFI.