[Xcb] XCBImage

Jamey Sharp jamey at minilop.net
Sat Mar 5 00:54:45 PST 2005

On Fri, Mar 04, 2005 at 02:23:53PM -0800, Barton C Massey wrote:
> Just talking off the top of my head here, but it seems to me
> that the XShmSegmentInfo.{shmseg,shmaddr} might normally be
> reused with different images.

Absolutely. But for a given image, the shmseg and its associated
client-side shmaddr are fixed, AFAICT. I can't see how one could switch
shared memory segments without also changing the client-side address of
the image data, let alone why one would want to.

I suppose the client could call XCBShmDetach, allocate a new XCBShmSEG
XID, then call XCBShmAttach with it, without changing the shmaddr or the
image data buffer. But that's just silly...

If the XCBImage bits could efficiently look up the XCBShmSEG using the
base address of the segment, then only the base address need be stored.
If it could use any address contained within the segment, then no extra
data is necessary -- in fact, any XCBImage could be automatically sent
using MIT-SHM by simply looking up whether it was already in shared

Perhaps we could usefully provide an allocator for shared memory, in
order to track the above information and to allow users to efficiently
manage shared memory as easily as with malloc and free.

> Build it however to start with, and
> we'll write/port some code to use it and see how it goes.

Yup, sounds like a good plan to me.

On Sat, Mar 05, 2005 at 08:10:57AM +0100, Vincent Torri wrote:
> I think that i'll leave the xcbimage like it is right now, create a
> XCBShminfo struct that contains shmseg, shmid and shmaddr.

It's up to you, naturally. But nothing needs the shmid once the attach
is done, right?

> I don't really know if i add the readonly field. It will not be
> difficult to change this later.

Of course.

> Jamey: if i'm not wrong, XCBShmAttach requires a XCBshmSEG and the 2 other
> fields (shmid and readonly fields)

Yes... but there's no reason to put them in a structure. That's all I
was saying.

> i'm also writing a test for this stuff.



More information about the xcb mailing list