Experiments Are Underway With Vulkan Powering The KDE Plasma Shell

[oiaohm]

Your movie example is pointless, as it's not suited content to spot stutter reliably. No the movie example is the human weakness. The vsynctester.com vsync indicator is a completely different story. What's the use of theoretical improvements that nobody will ever notice, is the Linux desktop already that complete to allow such luxuries?

Problem here aufkrawall with these kind faults you have to use tools like profiling not the human eye. Because otherwise you have one person saying the fault is fixed and another saying it still broken. The reality if you want to say something fixed a stutter or tear you need proper test result from profiling tool saying it gone so proving it not that the change has just moved the fault past your perception limit.

vsynctester.com part of that test include stuff to make vsync faults more in face to human its one of the test that commonly fail on systems that people claim perfect vsync on.

Yes one of the common excuses not to use profile tools with this problems is that those will only give a theoretical improvement. The only way you can be sure that it fixed so no human will ever see it again its go to the level tools will not detect tear or stutter. Of course remember you are not every human do you have higher than average perception for these faults by how much? See problem here. Human can say they see a tear or stutter fault and be right but a human cannot they see something is tear or stutter free only that its tear or stutter detectable at their perception level.

If you had proper profile results kwin-lowlatency showing no fault I would believe you that in your bug report you used human perception no way in hell is that believable because you perception level is not the perception level for the human population. The old movie example shows that human perception faulty is problem is human perception is not uniformly faulty human to human. You want a uniform it is tools to be sure you have fixed a fault to the point no human will see it the answer is again profiling tools looking for tears and stutter.

Human looking of tears and stutter has another horrible placebo effect if a person believes something with tears and stutter that are on the edge of their perception has no tears and stutter they will stop seeing tears and stutter. Human results with these kinds of problem are of limited usefulness.

Human results with tears and stutter saying there is a tear/stutter you cannot placebo a person into seeing tears and stutter that is not there. Human results saying there is no tear/stutter needs to treated as bull crap unless they can prove tool results they have either placebo tricked themselves or the tear/stutter has moved outside their perception limit over 90 percent of the time so not fix over 90 percent of the time. Yes since not fixed someone else end up down the road opening a bug claiming the same fault back again when it was really never gone.

[aufkrawall]

Your movie example is pointless, as it's not suited content to spot stutter reliably. The vsynctester.com vsync indicator is a completely different story. What's the use of theoretical improvements that nobody will ever notice, is the Linux desktop already that complete to allow such luxuries? I doubt it. And I actually also doubt your claim that there was no perfect vsync possible with GL. Show me some proof recorded with high frame rate camera or so.
Additional tools to detect and solve potential problems are fine, but you're once again making a story of life and death about a trifle. I'm btw. out, this is tiresome.

[oiaohm]

Never seen this and I'm autoscrolling all the time.

There is a reason why i say I use tools to detect this and not depend on human sensors.

Subliminal advertising experiments in movies found at 30 frames per second you could fully replace a full frame every 3 seconds and go not noticed. So 89 frames the movie 1 frame something completely not. So there is a threshold rate that you will be detect tearing.

Without using tools you cannot say that kwin-lowlatency has really fixed the issue it most likely just moved it past you perception level. This is why you need to use tools to confirm tear faults and the like because the change may have just alter prevalence of fault so reducing the number of people who can perceive the fault instead of properly fixing the tear class fault so it never happens.

Reality if I knew your perception level I could set you in from of stack of different monitors with some showing showing teared frames intentionally at a fixed interval you would not be able to pick out what monitor are showing teared frames. This perception problem is what makes hunting tearing like issues so hard because a lot of people will say their computer perfect showing no teared frames yet next person sits at it and curses because it is really showing teared frames because the next person perception level is less tolerant.

Tools for detecting tearing is the the mega intolerant person with absolutely perfect perception where any level of tearing defect will be detected no physical human is this good.

[aufkrawall]

Really you need to look closer. With kwin lowlatency you can have firefox tearing it buffers and making a fixed buffer in time.

Never seen this and I'm autoscrolling all the time.

[carewolf]

Somewhat unnecessary, but cool.

[oiaohm]

No tearing nor stuttering in FF Webrender with most aggressive lag reduction in kwin-lowlatency.
I'm aware that FF X11 implementation has design flaws and needs work, but generally experience is as smooth as described above here.

Really you need to look closer. With kwin lowlatency you can have firefox tearing it buffers and making a fixed buffer in time. If application is generating a teared buffer the right load pattern even with kwin-lowlatency will make it displayed.

Ideal world never make a teared buffer be it the vsync or in the application generated buffer passed to composting. Issue here is a performance optimisation where application decide it has to update the next displayed frame that its generating so it breaks the one its generating to make a new one; Of course a high latency compositor can miss that application has attempted to generate a replacement frame.

[smartalgorithm]

Presumably, more power efficient and faster rendering.

would be very nice... as i also thought this way, but then i thought it's desktop and it maybe doesn't utilize that much of stuff and there wont be any noticeable difference...
let's see... personally i am fine with X and openGL as long it performs well and does what it intended to do.

[aufkrawall]

No tearing nor stuttering in FF Webrender with most aggressive lag reduction in kwin-lowlatency.
I'm aware that FF X11 implementation has design flaws and needs work, but generally experience is as smooth as described above here.

[oiaohm]

Then you probably had a different issue, as it's completely smooth for me with kwin-lowlatency and Picom xrender present vsync (and afair also Gnome).

I run a lot of stuff that pick out single frames of tear. There is a bug in some versions of firefox when it using forced GL rendering where it shoves out a teared frame(yes it teared in the buffer firefox has passed and does this as part of general scrolling up and down). Of course if kwin is resulting in a slower frame speed could be just making that hidden bug visible. Basically its possible you have been seeing the same bug in firefox.

Not all tearing comes from vsync. Some tearing comes from opengl applications stuffing up there internal buffer management so generating a teared buffer. Solution to a teared buffer from opengl application is normally detect it and skip that buffer as the next one will be right. Of course some applications detect that they have made a teared buffer and attempt to generate a corrected one before the next sync(firefox) if that happens no tear will be visable if it does not tear will happen. Yes high latency compositor can remove the means for application send corrected buffer to hide application goof so incorrect buffer will be displayed more often not that the problem is new or unique to that compositor.

Yes there is vsync tearing of buffers and application tearing its own buffers generating buffer. Applications tearing their own buffers you really do need the compositor counter that.

[aufkrawall]

That stutter on scrolling issue in firefox. I have had that when I have turned on gl.require-hardware in firefox that is independent of windows manager/DE.

Then you probably had a different issue, as it's completely smooth for me with kwin-lowlatency and Picom xrender present vsync (and afair also Gnome).