From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: YAMAMOTO Mitsuharu Newsgroups: gmane.emacs.devel Subject: Re: x-display-pixel-width/height inconsistency Date: Fri, 10 May 2013 15:00:33 +0900 Organization: Faculty of Science, Chiba University Message-ID: References: <514A5DE1.10009@gmx.de> <831ub767wf.fsf@gnu.org> <83mwtu4p7c.fsf@gnu.org> <83vc8h313t.fsf@gnu.org> <5073D6B8-95E4-4012-AA74-106F428379DC@swipnet.se> <8BD4B041-5A3F-4D7C-AFD3-E997E194AA9D@swipnet.se> <02B98FCD-71DB-47EC-B58B-41A2539FF61A@swipnet.se> <83vc6tcqss.fsf@gnu.org> <83haibdipo.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Trace: ger.gmane.org 1368165662 2921 80.91.229.3 (10 May 2013 06:01:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 10 May 2013 06:01:02 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri May 10 08:01:00 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UagO4-0000xB-36 for ged-emacs-devel@m.gmane.org; Fri, 10 May 2013 08:01:00 +0200 Original-Received: from localhost ([::1]:53777 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UagO3-0007CD-Ly for ged-emacs-devel@m.gmane.org; Fri, 10 May 2013 02:00:59 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:51785) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UagNz-0007C6-Fr for emacs-devel@gnu.org; Fri, 10 May 2013 02:00:56 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UagNy-0006Vx-0f for emacs-devel@gnu.org; Fri, 10 May 2013 02:00:55 -0400 Original-Received: from mathmail.math.s.chiba-u.ac.jp ([133.82.132.2]:52458) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UagNu-0006UF-SO; Fri, 10 May 2013 02:00:51 -0400 Original-Received: from church.math.s.chiba-u.ac.jp (church [133.82.132.36]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id C280DC055D; Fri, 10 May 2013 15:00:33 +0900 (JST) In-Reply-To: <83haibdipo.fsf@gnu.org> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 133.82.132.2 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:159463 Archived-At: >>>>> On Thu, 09 May 2013 23:03:15 +0300, Eli Zaretskii said: >> + static BOOL CALLBACK >> + w32_monitor_enum (HMONITOR monitor, HDC hdc, RECT *rcMonitor, LPARAM dwData) >> + { >> + Lisp_Object *monitor_list = (Lisp_Object *) dwData; >> + >> + *monitor_list = Fcons (make_save_pointer (monitor), *monitor_list); >> + >> + return TRUE; >> + } > It makes me nervous to have consing inside a Win32 API callback. Are > we even sure the callback gets called in the context of our main > tread? If not, and if consing causes GC, we could blow up the stack. If the callback can be called from the thread/context other than the one for EnumDisplayMonitors and that can cause memory synchronization issue, then API documentation should clearly say so, because such kind of problem can happen even with other data structures. And it is not Fcons but Feval that can cause GC. > And actually, I don't see why you need the list of monitor HMONITOR > handles, you get them from MonitorFromWindow anyway. All you need is > the count of the monitors, and then you can create the vector in > monitor_frames by simply inserting every monitor you get from > MonitorFromWindow, and leave the rest at nil. Or am I missing > something? > So could we please get rid of the consing inside the callback, and > just count them instead? The display-monitor-function lists all the monitors regardless of the existence of Emacs frames in it. >> + if (FRAME_W32_P (f) && FRAME_W32_DISPLAY_INFO (f) == dpyinfo >> + && !EQ (frame, tip_frame)) > The test against dpyinfo is redundant, it will always be true: there's > only one dpyinfo on Windows. I would like to remove it, because it's > confusing. (There's one more such test in another place in the > patch.) I'm aware of that. It's just for resemblance to X11 code. I'd rather leave it to make it easier to compare with the code for X11 if it were for the Mac port, but I don't have a strong opinion for W32. >> + name = make_unibyte_string (mi.szDevice, strlen (mi.szDevice)); > Why make_unibyte_string? Is szDevice documented to be an ASCII-only > string? make_unibyte_string does not assume that the passed bytes are only of ASCII characters. I made it on the safe side in case the contents of szDevice member accidentally matches with Emacs internal encoding and misinterpreted. Of course, you can decode the string if its encoding is known (I'm not sure how it is encoded because I'm not familiar with W32). But you should be careful because code conversions can involve GC in general unlike Fcons. Alternatively, as the `name' attribute is optional, you can remove it entirely if you don't like make_unibyte_string. YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp