2D Performance Also Impacted By Unity On XMir

[kokoko3k]

Which is odd since they accelerated gradients since the 295 series of drivers - except for a few corner cases iirc. Their driver developers are very active, have you spoken to them about this? Perhaps provide them with a cairo-trace so they can analyse the failure path?

Yes i did, and i've spoken them about a cairo performance regression.

https://devtalk.nvidia.com/default/topic/523281/cairo-performance-regression-/

They may hae been busy, i can't say

Still, a poor ATI 7500 (about 10 years old?) does a better job though OSS drivers, and the same card with nuoveau just flies in that regard.

Wayland will be supported natively by Qt 5.2 and later; not by Qt 4.

How can kwin in 4.11 work with wayland then?

[spacetoilet]

now lets put it into an LTS

[spacetoilet]

Yes i did, and i've spoken them about a cairo performance regression.

https://devtalk.nvidia.com/default/topic/523281/cairo-performance-regression-/

They may hae been busy, i can't say

Still, a poor ATI 7500 (about 10 years old?) does a better job though OSS drivers, and the same card with nuoveau just flies in that regard.


How can kwin in 4.11 work with wayland then?

Wayland work started befor QT 5.2

[d2kx]

On the other side, Compiz 0.9.10 in Ubuntu 13.10 will probably introduce buffer_age support, which will speed some things up.

[kokoko3k]

Wayland work started befor QT 5.2

Speaking of kde4.11, the question was if kwin was ported to qt5 to work with wayland

[dee.]

How can kwin in 4.11 work with wayland then?

It doesn't really. It's just an experimental hack, where KDE still uses X to render onto a Wayland backend - kind of similar to how Unity on XMir works, actually. The difference is, it's not enabled by default, it's just there as an experimental feature so that anyone who wants to play with it - not meant for production use, like in Ubuntu 13.10.

The purpose of the KDE hack is, according to Martin, more as practice - to get familiar with Wayland. After the actual transition to Wayland, KDE will use it's own Wayland compositor to render to a Wayland backend, and XWayland will be used for legacy apps.

[kokoko3k]

It doesn't really. It's just an experimental hack, where KDE still uses X to render onto a Wayland backend - kind of similar to how Unity on XMir works, actually. The difference is, it's not enabled by default, it's just there as an experimental feature so that anyone who wants to play with it - not meant for production use, like in Ubuntu 13.10.

The purpose of the KDE hack is, according to Martin, more as practice - to get familiar with Wayland. After the actual transition to Wayland, KDE will use it's own Wayland compositor to render to a Wayland backend, and XWayland will be used for legacy apps.

Thank you.

[mannerov]

It doesn't really. It's just an experimental hack, where KDE still uses X to render onto a Wayland backend - kind of similar to how Unity on XMir works, actually. The difference is, it's not enabled by default, it's just there as an experimental feature so that anyone who wants to play with it - not meant for production use, like in Ubuntu 13.10.

The purpose of the KDE hack is, according to Martin, more as practice - to get familiar with Wayland. After the actual transition to Wayland, KDE will use it's own Wayland compositor to render to a Wayland backend, and XWayland will be used for legacy apps.

There is also a new native software implementation to replace Xrender:

http://blog.martin-graesslin.com/blog/2013/06/more-software-compositing/

This one is only compatible with wayland for the moment.

[TheOne]

OK so probably in 13.10 we'll take a performance hit. Hopefully the impact will be smaller, much smaller than it is today.... Get to work Canonical, only a few months left. Get it right a lot of people will think better of you. Get it wrong and haters will complain about this performance loss for another decade, even if it will have been fixed in 14.04.

http://www.olli-ries.com/first-mir-benchmarks/

One of the reasons for this result set is missing composite bypassing support, which we are aware of since January. Composite bypass helps when apps/benchmarks run fullscreen because? well, because they don?t need to be composited. Gamers out there? there is hope and a plan in place to get you your precious FPS back. This feature/bug is currently scheduled once other key functionality landed. Also, in order to make FPS based benchmarks really count, we need eglSwapInterval(0) implemented, which is currently in progress

[dee.]

http://www.olli-ries.com/first-mir-benchmarks/
One of the reasons for this result set is missing composite bypassing support, which we are aware of since January. Composite bypass helps when apps/benchmarks run fullscreen because? well, because they don?t need to be composited. Gamers out there? there is hope and a plan in place to get you your precious FPS back. This feature/bug is currently scheduled once other key functionality landed. Also, in order to make FPS based benchmarks really count, we need eglSwapInterval(0) implemented, which is currently in progress

All of this would have been a non-issue if they'd have stuck with Wayland.