[cairo] [Patch] Limit the amount of shared memory that cairo-xcb uses

[Uli Schlachter]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Am 30.01.2011 22:15, Chris Wilson wrote:
> On Sun, 30 Jan 2011 20:54:39 +0100, Uli Schlachter <psychon at znc.in> wrote:
>> cairo_surface_create_similar / _cairo_xcb_surface_create_similar already does
>> exactly this. (Mesh gradients always use SHM currently, too)
>>
>> But why do you think we need client participation for SHM? It works just fine
>> currently without any magic on the client side.
> 
> We are using an extremely limited resource; or at least excessive use of a
> global resource by multiple applications. Just remember those embedded
> systems where even a 16 MiB segment will be too much.

On such a system, wouldn't the surface pattern cache already cause this kind of
problem? When using an image surface as a source, we create a
cairo_xcb_picture_t and cache in screen->surface_pattern_cache. That cache
already has a hardcoded size limit of 16 MiB.

So embedded systems would already have to modify hardcoded patterns. IMHO that
shouldn't stop us from limiting the amount of shared memory we use. And 16 MiB
is still better than unlimited memory usage.

I'd vote for handling memory usage problems on embedded systems once someone
actually hits those. And even then, they could just --disable-xcb-shm.

Cheers,
Uli
- -- 
Q: Because it reverses the logical flow of conversation.
A: Why is putting a reply at the top of the message frowned upon?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBCAAGBQJNRd5tAAoJECLkKOvLj8sGURQH/1GFh8/77opk7R7N/1tm9RFX
WBBEcFW6EGTBIHJQDz4fRYqt1hMdPC8T8zrkELZ6Xv6VffvN9UUmjYOcRJ/nQXrJ
ctq4Hk6SO4WYvozXLLSqZ9X6fE9kCUEFVPnp/KAp0m9PHGXsrsYvn+/DRbqVhv9G
1v6gIBm9EYrU8w9TqUbonQnP6A3fO+Gh4sKmYaFPLEajUarIlFS9NtFHlZvqltFd
xofGJUKTEto7n5KjcgbPa9BBmwD1ko3p5nInw73TXONfJTOzMt4ZsNxYuNqe9YZq
d7YXeqsRRao58SqthtrP0ONsfxmo/deY40y4HNP96PpAyopQpAmd5W80VvuCGsg=
=SgGh
-----END PGP SIGNATURE-----