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: 23/NS: redraws according to mouse-face are slow Date: Wed, 06 May 2009 11:25:35 +0900 Organization: Faculty of Science, Chiba University Message-ID: References: <4383E9F6-9B66-4DA4-AA3C-D602EB059B97@gmail.com> <139B721E-A1B4-4256-B202-D4472C0331FB@gmail.com> <87d4aowc1l.fsf@cyd.mit.edu> <2E6E5869-2F70-4AF5-A917-7EA863D6BD42@gmail.com> <1ACB40A8-4422-4B9A-A0F7-FE0B9C738299@gmail.com> NNTP-Posting-Host: lo.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 1241576764 9191 80.91.229.12 (6 May 2009 02:26:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 6 May 2009 02:26:04 +0000 (UTC) Cc: 2530@emacsbugs.donarmstrong.com, David Reitter , Chong Yidong , Emacs-Devel devel To: Adrian Robert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed May 06 04:25: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 1M1WpR-0002Pg-RA for ged-emacs-devel@m.gmane.org; Wed, 06 May 2009 04:25:50 +0200 Original-Received: from localhost ([127.0.0.1]:52112 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M1WpR-0003gS-1Y for ged-emacs-devel@m.gmane.org; Tue, 05 May 2009 22:25:49 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M1WpM-0003g5-3L for emacs-devel@gnu.org; Tue, 05 May 2009 22:25:44 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M1WpG-0003cD-Um for emacs-devel@gnu.org; Tue, 05 May 2009 22:25:43 -0400 Original-Received: from [199.232.76.173] (port=58992 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M1WpG-0003c5-Sc for emacs-devel@gnu.org; Tue, 05 May 2009 22:25:38 -0400 Original-Received: from ntp.math.s.chiba-u.ac.jp ([133.82.132.2]:62944 helo=mathmail.math.s.chiba-u.ac.jp) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M1WpG-0005Hh-7P for emacs-devel@gnu.org; Tue, 05 May 2009 22:25:38 -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 0D0E42C40; Wed, 6 May 2009 11:25:36 +0900 (JST) In-Reply-To: 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 monty-python.gnu.org: NetBSD 3.0 (DF) 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:110702 Archived-At: >>>>> On Wed, 6 May 2009 08:55:36 +0700, Adrian Robert said: >> The effect of ns_update_begin seems to avoid -[NSWindow >> flushWindow] call (via ns_unfocus) for each ns_draw_glyph_string >> call. Does this frequent flushing necessary in the first place? >> Other terms don't seem to do flushing for each string drawing call. > My assumption was that it is legal to call draw_glyph_string() > outside of an update_begin()-end() pair. So draw_glyph_string() > must be able to operate in "self-contained" mode, which and the > flush is needed. The same logic holds for other RIF functions -- > that they can either be called in one-shot mode or in batch mode > (inside update begin-end). In the latter case, focus/unfocus > reflect the batching by holding screen flush until end. Other terms don't do flushing even at update_end, let alone at the end of each one-shot drawing operation (you may see XFlush calls in the code but they are mostly defined as no-ops). IIUC, flushing happens only by explicit flush_display(_optional) RIF calls or at the timing of polling/receiving window system events (e.g., XPending on X11, and ReceiveNextEvent on Carbon) implicitly. YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp