From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: problem disabling display optimizaions Date: Wed, 10 Aug 2011 19:30:13 +0300 Message-ID: <83y5z1xm96.fsf@gnu.org> References: Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1312993847 10424 80.91.229.12 (10 Aug 2011 16:30:47 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 10 Aug 2011 16:30:47 +0000 (UTC) Cc: emacs-devel@gnu.org To: joakim@verona.se Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 10 18:30:43 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QrBg1-00076g-LD for ged-emacs-devel@m.gmane.org; Wed, 10 Aug 2011 18:30:41 +0200 Original-Received: from localhost ([::1]:59164 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QrBg0-0005To-N3 for ged-emacs-devel@m.gmane.org; Wed, 10 Aug 2011 12:30:40 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:54553) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QrBfu-0005Tc-RU for emacs-devel@gnu.org; Wed, 10 Aug 2011 12:30:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QrBfq-0007AF-Lr for emacs-devel@gnu.org; Wed, 10 Aug 2011 12:30:34 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:40611) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QrBfq-0007A8-D0 for emacs-devel@gnu.org; Wed, 10 Aug 2011 12:30:30 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0LPQ00B000FSOD00@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Wed, 10 Aug 2011 19:30:13 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.228.94.185]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LPQ005QM0IBXH32@a-mtaout20.012.net.il>; Wed, 10 Aug 2011 19:30:12 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 80.179.55.166 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:143114 Archived-At: > From: joakim@verona.se > Date: Wed, 10 Aug 2011 16:06:00 +0200 > > > I disable display optimizations in the xwidget branch currently because > I need to reliably catch redisplays notion about where objects are on the > screen. The idea has always been to get back to this and re-enable > optimizations in stages. FWIW, I have never found myself in the need of disabling optimizations. They never gave me any trouble, and not because I'm terribly smart when it comes to reasoning about what redisplay does. Perhaps the reason is that my changes never touched anything related to layout in general and glyph string level in particular. > I can restore the previous behavior by disabling scrolling_window() by > making it return early. Then it sounds like stepping with a debugger through scrolling_window is your best bet to find the problem. Although what you say below seems to point out that you already know the answer. > This function is similar to the try_* fns. Not really, but this isn't important for your purposes. > Now I would like to verify how redisplay works. Welcome to the club ;-) > The problem happens because fill_xwidget_glyph_string doesn't get called > during redisplay any more. This works the same as the other > fill_*_glyph_string functions. If display opimizations are completely > disabled it should be called. Redisplay tries to optimize away the fill > calls by using hardware scrolling if possible. But if the screen is > scrolled that way the xwidget won't be notified that Emacs desires its > movement(yet). scrolling_window exists precisely to _avoid_ recreating and redrawing glyph strings. If xwidget cannot tolerate that, then you will have no choice but disable the scrolling_window optimization. One way of doing that would be to fiddle with row_equal_p, so that it never returns non-zero when xwidget won't like that. (I cannot formulate the condition more accurately, because I have no idea what xwidget is and how it modifies the display engine.) However, please try to see if at least matrix rows that aren't related to xwidget can be reused in scrolling_window. Disabling redisplay optimizations generally makes Emacs unusable. Can you explain why you need to re-fill xwidget glyph strings when a window is scrolled, in terms that could be understood by someone who knows nothing about xwidget? > GLYPH_DEBUG allows for disabling of optimizations and I have been using > that. GLYPH_DEBUG now compiles here but doesn't disable optimization as > I expect. AFAIK, GLYPH_DEBUG disables optimizations in xdisp.c, but does not affect update_frame and its subroutines, to which scrolling_window belongs. > produce_xwidget_glyph gets called like the other produce_*_glyph > functions but at that time we don't know screen placement. Not sure what this tries to say or how important it is for understanding of the overall issue. How is the screen placement relevant? > so, to summarize, GLYPH_DEBUG doesn't seem to inhibit optimizations as > it used to. Are you saying that GLYPH_DEBUG could disable scrolling_window in the past? If so, when was that?