I let run the gvncviewer (from library gtk-vnc) in fullscreen mode. Under heavy load e.g. changing the complete screen content on vnc server side every 0.01 secs gvncviewer starts queueing up memory in SHM. (See bottom of the mail) Queueing up means more and more shared memory segments are allocated by cairo The problem lies in function _cairo_xlib_shm_info_create It tries to find a empty space in current shm pool. If this not happens it simply create a new shm segment. This happens all the time so on my slow computer it accumulates approx 1 GB in 10 minutes I assume if the X Server is too slow to get managed with a work load it blocks the shared memory segments until it is done. But the xserver is much slower than the cairo backend produces the load the shared memory is growing until out of mem. For verification i just added a sync(display) call before searching in shm pool and the problem is gone. Here a shortened example of pmap output of the process after running a while 08048000 20K r-xp /usr/bin/gvncviewer 0804d000 4K rw-p /usr/bin/gvncviewer 0804e000 656K rw-p [heap] 7c8e6000 196K rw-p [ anon ] 7c917000 32768K rw-s /SYSV00000000 7e917000 196K rw-p [ anon ] 7e948000 32768K rw-s /SYSV00000000 80948000 196K rw-p [ anon ] 80979000 32768K rw-s /SYSV00000000 82979000 196K rw-p [ anon ] 829aa000 32768K rw-s /SYSV00000000 849aa000 196K rw-p [ anon ] 849db000 32768K rw-s /SYSV00000000 869db000 196K rw-p [ anon ] 86a0c000 32768K rw-s /SYSV00000000 88a0c000 196K rw-p [ anon ] 88a3d000 32768K rw-s /SYSV00000000 8aa3d000 196K rw-p [ anon ] 8aa6e000 32768K rw-s /SYSV00000000 8ca6e000 196K rw-p [ anon ] 8ca9f000 32768K rw-s /SYSV00000000 8ea9f000 196K rw-p [ anon ] 8ead0000 32768K rw-s /SYSV00000000 90ad0000 196K rw-p [ anon ] 90b01000 32768K rw-s /SYSV00000000 92b01000 196K rw-p [ anon ] 92b32000 32768K rw-s /SYSV00000000 94b32000 196K rw-p [ anon ] 94b63000 32768K rw-s /SYSV00000000 96b63000 196K rw-p [ anon ] 96b94000 32768K rw-s /SYSV00000000 98b94000 196K rw-p [ anon ] 98bc5000 32768K rw-s /SYSV00000000 9abc5000 196K rw-p [ anon ] 9abf6000 32768K rw-s /SYSV00000000 9cbf6000 196K rw-p [ anon ] 9cc27000 32768K rw-s /SYSV00000000 9ec27000 196K rw-p [ anon ] 9ec58000 32768K rw-s /SYSV00000000 a0c58000 196K rw-p [ anon ] a0c89000 32768K rw-s /SYSV00000000 a2c89000 196K rw-p [ anon ] a2cba000 32768K rw-s /SYSV00000000 a4cba000 196K rw-p [ anon ] a4ceb000 32768K rw-s /SYSV00000000 a6ceb000 196K rw-p [ anon ] a6d1c000 32768K rw-s /SYSV00000000 a8d1c000 196K rw-p [ anon ] a8d4d000 32768K rw-s /SYSV00000000 aad4d000 196K rw-p [ anon ] aad7e000 32768K rw-s /SYSV00000000 acd7e000 196K rw-p [ anon ] acdaf000 32768K rw-s /SYSV00000000 aedaf000 196K rw-p [ anon ] aede0000 32768K rw-s /SYSV00000000 b0de0000 196K rw-p [ anon ] b0e11000 32768K rw-s /SYSV00000000 b2e11000 5128K rw-p [ anon ] ...... ..... .. .
Why is the client running unthrottled?
I don't know how I can throttle the vnc client. It is getting a new screen from vnc server for displaying it and it is doing it. Sorry maybe I have missed the point of your question at all.
Oh forget it using cairo_scale what causes the heavy computations on an old Intel Atom with EMGD (PowerVR) and poorly supported driver from Intel
Ok I think if nobody feels responsible for this problem it is better to close this bug. I have no possibility to see from application that cairo xlib backend is flooding th xserver. a) Cairo claims it is not responsibility of cairo if XServer is too slow b) and Xserver cannot change anything if data are coming faster as Xserver can work on it I have just added a patch in my xlib backend that will always sync with Xserver if the 32 MB shared memory page is full but this is not a good solution just a workaround
My point is that the client is pushing data faster than the Xserver can render it, so the client is building up a massive output latency. It tends to cause very annoying lag. However, how to close that feedback loop is not obvious and may require an extra interface in cairo (something like cairo_device_throttle).
(In reply to comment #5) > My point is that the client is pushing data faster than the Xserver can > render it, so the client is building up a massive output latency. It tends > to cause very annoying lag. However, how to close that feedback loop is not > obvious and may require an extra interface in cairo (something like > cairo_device_throttle). Yes, I agree. But if a client should do active throtteling means the client needs two things a) intelligence when throtteling is useful. How to measure the speed of a xserver? b) intelligence how to throttle down What about a kind of callback each time called when the cairo xlib backend allocates/deallocate a shared memory arena? For the client it would be a good hint there is something strange with xserver Or can you think for other measuremnt parameters indicating a a xserver load ? Oh I think I am too directly attached to my problem. What about cairo_device_throttle_strategy(..) e.g. with NONE (=old behavior), COWARD (=try to get in sync with xserver every time), BEST (=sync if really needed) ? Maybe second solution would be much better. What do you think?
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/cairo/cairo/issues/212.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.