From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: grischka Newsgroups: gmane.emacs.devel Subject: Re: GTK frame changes Date: Fri, 03 Jul 2009 12:53:51 +0200 Message-ID: <4A4DE33F.4060006@gmx.de> References: <4A4CADCB.8000304@gmx.de> <4A4CC3D7.40109@swipnet.se> <4A4CD73D.2080802@gmx.de> <4A4CDDF2.4030608@swipnet.se> <4A4CF264.6040306@gmx.de> <4A4D0E0E.70405@swipnet.se> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1246618501 19179 80.91.229.12 (3 Jul 2009 10:55:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 3 Jul 2009 10:55:01 +0000 (UTC) Cc: emacs-devel@gnu.org To: =?UTF-8?B?SmFuIERqw6Rydg==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 03 12:54:54 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MMgPt-0003IW-Tv for ged-emacs-devel@m.gmane.org; Fri, 03 Jul 2009 12:54:54 +0200 Original-Received: from localhost ([127.0.0.1]:32770 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MMgPt-0001A4-84 for ged-emacs-devel@m.gmane.org; Fri, 03 Jul 2009 06:54:53 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MMgPM-0000i6-L6 for emacs-devel@gnu.org; Fri, 03 Jul 2009 06:54:20 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MMgPH-0000an-VK for emacs-devel@gnu.org; Fri, 03 Jul 2009 06:54:19 -0400 Original-Received: from [199.232.76.173] (port=60328 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MMgPF-0000Zv-GO for emacs-devel@gnu.org; Fri, 03 Jul 2009 06:54:13 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]:52280) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1MMgPE-0005jD-AR for emacs-devel@gnu.org; Fri, 03 Jul 2009 06:54:12 -0400 Original-Received: (qmail invoked by alias); 03 Jul 2009 10:54:07 -0000 Original-Received: from p57A08C7D.dip0.t-ipconnect.de (EHLO [192.168.1.4]) [87.160.140.125] by mail.gmx.net (mp030) with SMTP; 03 Jul 2009 12:54:07 +0200 X-Authenticated: #18588216 X-Provags-ID: V01U2FsdGVkX1+WJGpIuuKW4Aoy2RZymqhygu3CajPcX8UXnGh5V7 HUny9PZxpXctRR User-Agent: Thunderbird 2.0.0.18 (X11/20081125) In-Reply-To: <4A4D0E0E.70405@swipnet.se> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.62 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:111947 Archived-At: Jan Djärv wrote: > grischka skrev: >> Jan Djärv wrote: >>> XSync sends a request to the server and waits for a reply. The resize >>> request is sent before that, so the resize should be handeled before >>> the XSync reply is sent. >> >> Yes, but this reply is something in the sense of the X protocol, not >> in the sense of ConfigureNotify. It just means that the X server got >> the resize message when XSync returns. It doesn't mean at all that >> a ConfigureNotify is already in the client queue let alone that emacs >> now knows how big it is. >> > > The XProtocol specification (the oldest I have is R6.8, the newest is > 7.4, they say the same thing) says this: > > "Whether or not a server is implemented with internal concurrency, > the overall effect must be as if individual requests are executed to > completion in some serial order, > and requests from a given connection must be executed in delivery order > (that is, the total execution order is a shuffle of the individual > streams). > The execution of a request includes validating all arguments, > collecting all data for any reply, > and generating and queueing all required events. > However, it does not include the actual transmission of the reply and > the events. > In addition, the effect of any other cause that can generate multiple > events > (for example, activation of a grab or pointer motion) must effectively > generate and queue all required events indivisibly with respect to all > other causes and requests. > > For a request from a given client, > any events destined for that client that are caused by executing the > request > must be sent to the client before any reply or error is sent." I'm somehow confused what they mean by reply here. If events are sent before replies then replies must be something else. > I interpret this as for a given X connection, all requests are run to > completion and replies and events are queued in order. Since XSync > waits for the reply, it also means that after XSync has returned, events > and replies generated by previous requests have indeed arrived. Okay, I tested once more with an undecorated window and there indeed it looks like your interpretation might be right. Just with WM redirection (metacity here) the ConfigureNotify clearly arrives about 2 ms later and the behavior is completely unimpressed by XSync. --- grischka > Jan D. >