unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Po Lu <luangruo@yahoo.com>
Cc: kbrown@cornell.edu, emacs-devel@gnu.org
Subject: Re: MS Windows double buffering
Date: Sat, 30 Apr 2022 12:10:14 +0300	[thread overview]
Message-ID: <83v8ur7x8p.fsf@gnu.org> (raw)
In-Reply-To: <87v8urt3mk.fsf@yahoo.com> (message from Po Lu on Sat, 30 Apr 2022 15:46:43 +0800)

> From: Po Lu <luangruo@yahoo.com>
> Cc: Ken Brown <kbrown@cornell.edu>,  emacs-devel@gnu.org
> Date: Sat, 30 Apr 2022 15:46:43 +0800
> 
> > Here and elsewhere in the modified code, I'd like to have all the
> > changes that affect the no-double-buffering code to be conditioned on
> > some variable exposed to Lisp.  That way, if and when someone reports
> > a problem that could be related to this feature, we could easily get
> > back to exactly the old code as it was before the changeset, and see
> > if the problem is indeed due to this change.  For example, entering
> > the critical section above is one such change.
> 
> Thanks.  That's not something we do on X, but I will add such a
> variable.

Emacs is being tested on X much more than on MS-Windows, and people
who use it on X tend to be more knowledgeable about the technical
issues than a typical user of Emacs on Windows.  Moreover, the level
of expertise we have on our team about Windows-specific GUI aspects is
significantly lower than in the X case.

So having such a debugging device for significant changes in display
code is beneficial.

> > I don't understand why you enter the critical section here:
> > w32_show_back_buffer does that internally, and the old code didn't
> > need that.
> 
> `paint_buffer' can only be accessed safely inside the critical section,
> as long as get_frame_dc can be called from the message pump thread, but
> maybe it isn't called there.

So you are saying this code didn't work correctly before?  Or am I
misunderstanding something?

> >  . w32term.c is also used in the Cygwin w32 build, (which produces a
> >    Cygwin Emacs that uses the native MS-Windows GUI functions instead
> >    of X).  Will this code work in that build?  If not, the new code
> >    should be ifdef'ed away on Cygwin.  Ken, can you please chime in
> >    and help us DTRT here?
> 
> No idea, though I don't think double buffering uses anything that might
> not work on Cygwin.

Let's hope Ken will help us here.

> >  . how does one test this feature?  I rarely see any flickering on
> >    MS-Windows, so what should I try to see the effect of double
> >    buffering in action?
> 
> Emacs should flicker much less (or not at all) upon any of the test
> cases in the last thread(s) on flicker, or when you run this:
> 
>   (while t (redraw-display) (redisplay))

This still flickers considerably here, albeit with a significantly
lower frequency.

What other test cases in the discussions would you recommend to try?



  reply	other threads:[~2022-04-30  9:10 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <877d791thh.fsf.ref@yahoo.com>
2022-04-28  8:51 ` MS Windows double buffering Po Lu
2022-04-28  9:42   ` Eli Zaretskii
2022-04-28 12:45     ` Po Lu
2022-04-29  3:36       ` Po Lu
2022-04-30  5:41         ` Po Lu
2022-04-30  6:50           ` Eli Zaretskii
2022-04-30  7:46             ` Po Lu
2022-04-30  9:10               ` Eli Zaretskii [this message]
2022-04-30  9:55                 ` Po Lu
2022-04-30 10:23                   ` Eli Zaretskii
2022-04-30 10:33                     ` Po Lu
2022-04-30 10:55                       ` Eli Zaretskii
2022-04-30 11:01                         ` Po Lu
2022-04-30 11:32                           ` Eli Zaretskii
2022-04-30 11:54                             ` Po Lu
2022-05-03  8:23               ` Robert Pluim
2022-05-03  8:43                 ` Po Lu
2022-04-30 17:34             ` Ken Brown
2022-04-30 18:25               ` Eli Zaretskii
2022-05-01  0:35               ` Po Lu
2022-05-01 16:00               ` Arash Esbati
2022-05-01 16:07                 ` Eli Zaretskii
2022-05-01 16:11                   ` Arash Esbati

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83v8ur7x8p.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=kbrown@cornell.edu \
    --cc=luangruo@yahoo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).