[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: XCB and 32- vs 64-bit 'long'
From: |
Ken Raeburn |
Subject: |
Re: XCB and 32- vs 64-bit 'long' |
Date: |
Sat, 14 Nov 2015 05:33:06 -0500 |
> On Nov 13, 2015, at 13:05, Paul Eggert <address@hidden> wrote:
>
> Valgrind pointed out a bug in recent XCB-related changes, in that Xlib
> converts 32-bit quantities to 'long' but XCB does not. The distinction
> matters on platforms like x86-64 where 'long' is 64 bits. Also, on my
> platform at least, xcb_get_property_value_length returns a byte count, not a
> word count; unfortunately this does not appear to be documented anywhere.
Yes, I found the documentation to be rather poor in that area. I did find a
discussion in an old bug report at freedesktop.org about how it was supposed to
and supposedly did return a count of values rather than of bytes. But poking
around on the net at other applications using the routine, it does appear that
the byte count is what’s expected, consistent with what you’re seeing. Thanks
for catching these.
> I just now installed a patch that I hope fixes this:
>
> http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=4c4b520520cf6b99ce7128331a4e108e58095705
>
> Ken, could you please check this patch? I am by no means an expert in XCB.
> Thanks.
It looks good to me. And I’ve run a few tests to confirm that it’s getting the
right lengths for me. It also turns out that the two properties in question
are set very rarely in my testing setup, which surprised me. So I do want to
look at that a little more closely. I’m no expert either.
> While we're on the subject, I assume that the goal is to replace all Xlib
> calls with XCB calls, on platforms that have XCB. Can Emacs start assuming
> XCB, and drop the old Xlib-only code? That would simplify Emacs maintenance.
My immediate goal was to speed up certain Emacs activities on moderate-latency
networks; my connection from home to work has about a 30ms round trip time, and
the non-pipelined requests for information and the synchronization calls to
check for errors really added up. It’s still slower than I’d like — takes
about a second to create a new frame remotely — but it’s better than it was.
It would certainly simplify things if we could just pick one version to
support, but I don’t know if it’s reasonable to assume that all the systems we
want to support have moved to XCB.
Ken