Mir 0.11 Working On Better Performance, Android External Display Support

[gens]

never did understand why people use triple buffering

[TheBlackCat]

The same effort to develop Mir would have been spent on developing a Unity Compositor for Wayland instead. The only difference is that they would have a strict protocol to adhere to.

Which means they wouldn't have had to develop their own protocol, their own library, their own X11 interface, their own driver support, their own toolkit support, their own security testing, etc. That all takes time. Maybe each thing individually isn't a huge amount of work, but it all adds up.

So it would have been a year faster to rewrite everything from scratch?

They are already rewriting everything from scratch. They would have had to rewrite a lot less than they are now.

Wayland isn't shiped as stable in any distro yet, hell even Gnome doesn't have stable support for Wayland for at least to April, and then it still haven been shiped as stable in any distro. Canonical plans to deploy Mir in less than a year and if that fails, in April next year.

Okay, so worst-case scenario, Gnome is about half a year ahead of Mir, and more likely at least a year ahead.

[quintesse]

never did understand why people use triple buffering

Well if you can be completely sure that on all frames you'll be finished drawing to the back buffer before you need to flip on the vertical sync then you don't need it. But for example games try to push this boundary, they'll try to draw and calculate as much as possible in the time that is available. But you still have to stop and wait for vertical sync (to avoid tearing), it's just that there is a small margin between the moment you're done drawing and the moment you flip the buffers. So the possibility exists, especially on PCs that will have other things running, that some other task has claimed the CPU for some work and suddenly your game's drawing loop takes longer and gets pushed past the vertical sync and you see a hickup. Triple buffering give you the possibility to start drawing the 3rd frame while the 2nd frame is waiting for vertical sync, giving you this small margin of extra time to do your work. HTH

[tuke81]

never did understand why people use triple buffering

Don't know about compositors, but in games if you are using vsync, triple buffer is a must.

[gens]

Well if you can be completely sure that on all frames you'll be finished drawing to the back buffer before you need to flip on the vertical sync then you don't need it. But for example games try to push this boundary, they'll try to draw and calculate as much as possible in the time that is available. But you still have to stop and wait for vertical sync (to avoid tearing), it's just that there is a small margin between the moment you're done drawing and the moment you flip the buffers. So the possibility exists, especially on PCs that will have other things running, that some other task has claimed the CPU for some work and suddenly your game's drawing loop takes longer and gets pushed past the vertical sync and you see a hickup. Triple buffering give you the possibility to start drawing the 3rd frame while the 2nd frame is waiting for vertical sync, giving you this small margin of extra time to do your work. HTH

i'v looked at the ars technica link tuke81 provided and did some research

they did some wrong, as input and game logic can be ran at a different rate then the screen (and are, in games i know)
and with double buffering and vsync the engine can say "it took me only 1/4 of the deadline to render it, so i might as well render again", or even "next frame i'l wait a bit before rendering"

http://entropyinteractive.com/2011/02/game-engine-design-the-game-loop/

ofc, missing the deadline would result in a dropped frame

triple buffering, granted, does make some sense with gpu heavy scenes, but then it would be a bit jittery (not as smooth as ars techinca says)
'cuz if the render takes like 14ms with a 16ms deadline, that means that the render->flip_to_screen latency would have a stride (in this case every 8th frame would jump)


other program occupying the cpu is a moot point as there would always be consequences from that
power saving, on the other hand, isn't, but that's another topic

John Carmack commented on it https://twitter.com/ID_AA_Carmack/st...11153509249025
granted he doesn't like double buffering either

[justmy2cents]

Wayland isn't shiped as stable in any distro yet, hell even Gnome doesn't have stable support for Wayland for at least to April, and then it still haven been shiped as stable in any distro. Canonical plans to deploy Mir in less than a year and if that fails, in April next year.

Wayland shipped as stable? you probably mean default, coz Wayland is stable for long time now. the only unstable things are compositors that are starting to emerge and based on my test of Gnome on Wayland in F21 they are having pretty fucking awesome track record. in all my years I cannot remember one new tech being presented in Linux and have so little problems.

and if you hope Mir will just ship as full replacement when it ships first time. either you or Canonical would be blind to reality. something like this would require at least one or two Ubuntu releases providing Mir as secondary option for the brave in order to get user feedback and get error reports. something in a way like F21 did it.

there is also a matter of proprietary drivers, where Wayland holds ground again. Wayland is already extensively used in automotive, phones... that alone is incentive enough for NVidia&Co to write drivers