From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 80208 invoked by alias); 19 Jun 2015 17:13:40 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 80199 invoked by uid 89); 19 Jun 2015 17:13:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_40,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 X-HELO: mail-oi0-f44.google.com Received: from mail-oi0-f44.google.com (HELO mail-oi0-f44.google.com) (209.85.218.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 19 Jun 2015 17:13:39 +0000 Received: by oigx81 with SMTP id x81so84541051oig.1 for ; Fri, 19 Jun 2015 10:13:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=wcUx33vJ9fhIJJkdHw0NWXbnXfJAcO+CTTAFrQpUTEI=; b=eBUhgP8xjpsfUVe9/6gWxE7xBHWDxsefCKDAIK/y8sN4UL/leyVdLLZLiuDtXKvjLI mzednrZ0txzaIYpHWi+jhsUmDf5eHPRxhYNWXoOeQwEN7GFHxxisiXtmko9aFvZVwJz3 cFTtHaF3fvr16OQbWfSxAJU0rAIezcg7CoY83H1+DKEk87yKOg/iPoULrdXI5+QWGFvm pgF9d8JPlzYMw/9Y7oHkeQxOihFkmwUfky67OOmkpSsORjAbNMrKwCND79Ttk4lD5TSz t1TiIM+gaDCksawMsXwZ3Nda6Q2vlWA+eKt1aRdZgfmo8LR+jFD0mHACssQraCM/0kGb ivWQ== X-Gm-Message-State: ALoCoQmxNmyhJUy2cN1RcJfP9Muue1oDSot0/p23RUTehI3jGOMJ95xsoViuAyoNaiGARmP1H5ky X-Received: by 10.182.211.66 with SMTP id na2mr14501116obc.43.1434734017405; Fri, 19 Jun 2015 10:13:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.96.167 with HTTP; Fri, 19 Jun 2015 10:13:16 -0700 (PDT) In-Reply-To: <1434688566-2549-1-git-send-email-patrick@parcs.ath.cx> References: <1434688566-2549-1-git-send-email-patrick@parcs.ath.cx> From: Patrick Palka Date: Fri, 19 Jun 2015 17:13:00 -0000 Message-ID: Subject: Re: [PATCH] Fix TUI flicker resulting from frequent frame changes (PR tui/13378) To: "gdb-patches@sourceware.org" Cc: Patrick Palka Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2015-06/txt/msg00408.txt.bz2 On Fri, Jun 19, 2015 at 12:36 AM, Patrick Palka wrote: > This patch fixes the perceived flicker of the TUI screen (and subsequent > slowdown) that most apparent when running an inferior while a > conditional breakpoint is active. The cause of the flicker is that each > internal event GDB responds to is accompanied by a multitude of calls to > select_frame() and each such call forces the TUI screen to be refreshed. > We would like to not update the TUI screen after each such frame change. > > The fix for this issue is pretty straightforward: do not update the TUI > screen when select_frame() gets called while synchronous execution of > the inferior is enabled. This works because synchronous execution > remains enabled during the processing of internal events. And since > during synchronous execution the user has no control of the TUI anyway, > it does not hurt to avoid updating the screen then. > > The select_frame hook is still undesirable and should be removed, but > in the meantime this fix is seemingly an effective approximation of a > more disciplined approach of updating the TUI screen. > > [ When the inferior is running while sync_execution is disabled, e.g. > via "continue&" it looks like GDB lacks access to frame information > thorughout -- and the hook never gets called -- so seemingly no > worries in that case. ] > > [ up/down etc still work properl of course ] > > [ I am not sure that the change in tui_on_sync_execution_done is > necessary/desirable. It seems normal_stop already calls > select_frame (get_current_frame ()) after sync_execution is toggled > off. ] > > gdb/ChangeLog: > > * tui/tui-hooks.c (tui_selected_frame_level_changed_hook): Don't > update the screen while synchronous execution is active. > * tui/tui-interp.c (tui_on_sync_execution_done): Make sure that > TUI's frame information is refreshed. > --- > gdb/tui/tui-hooks.c | 8 ++++++++ > gdb/tui/tui-interp.c | 5 +++++ > 2 files changed, 13 insertions(+) > > diff --git a/gdb/tui/tui-hooks.c b/gdb/tui/tui-hooks.c > index 8d84551..ca8358d 100644 > --- a/gdb/tui/tui-hooks.c > +++ b/gdb/tui/tui-hooks.c > @@ -133,6 +133,14 @@ tui_selected_frame_level_changed_hook (int level) > if (level < 0) > return; > > + /* Do not respond to frame changes occurring while synchronous execution is > + enabled. Updating the screen in response to each such frame change just > + results in pointless flicker and slowdown. Once synchronous execution is > + done this hook will get called again to ensure that our frame information > + is refreshed. */ > + if (sync_execution) > + return; > + > old_chain = make_cleanup_restore_target_terminal (); > target_terminal_ours_for_output (); > > diff --git a/gdb/tui/tui-interp.c b/gdb/tui/tui-interp.c > index 1a5639d..2477536 100644 > --- a/gdb/tui/tui-interp.c > +++ b/gdb/tui/tui-interp.c > @@ -107,6 +107,11 @@ tui_on_sync_execution_done (void) > { > if (!interp_quiet_p (tui_interp)) > display_gdb_prompt (NULL); > + > + /* Make sure our frame information is refreshed now that synchronous > + execution is done. */ > + if (tui_active) > + deprecated_selected_frame_level_changed_hook (0); This condition ought to be if (tui_active && has_stack_frames ()) so that we don't call the hook (and thus, try to lookup frame information) after the inferior has exited (which would result in a confusing "No stack." error). > } > > /* Observer for the command_error notification. */ > -- > 2.4.4.410.g43ed522.dirty >