emacs-devel
[Top][All Lists]
Advanced

[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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]