[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MS Windows double buffering
From: |
Eli Zaretskii |
Subject: |
Re: MS Windows double buffering |
Date: |
Sat, 30 Apr 2022 12:10:14 +0300 |
> 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?
- MS Windows double buffering, Po Lu, 2022/04/28
- Re: MS Windows double buffering, Eli Zaretskii, 2022/04/28
- Re: MS Windows double buffering, Po Lu, 2022/04/28
- Re: MS Windows double buffering, Po Lu, 2022/04/28
- Re: MS Windows double buffering, Po Lu, 2022/04/30
- Re: MS Windows double buffering, Eli Zaretskii, 2022/04/30
- Re: MS Windows double buffering, Po Lu, 2022/04/30
- Re: MS Windows double buffering,
Eli Zaretskii <=
- Re: MS Windows double buffering, Po Lu, 2022/04/30
- Re: MS Windows double buffering, Eli Zaretskii, 2022/04/30
- Re: MS Windows double buffering, Po Lu, 2022/04/30
- Re: MS Windows double buffering, Eli Zaretskii, 2022/04/30
- Re: MS Windows double buffering, Po Lu, 2022/04/30
- Re: MS Windows double buffering, Eli Zaretskii, 2022/04/30
- Re: MS Windows double buffering, Po Lu, 2022/04/30
- Re: MS Windows double buffering, Ken Brown, 2022/04/30
- Re: MS Windows double buffering, Eli Zaretskii, 2022/04/30
- Re: MS Windows double buffering, Po Lu, 2022/04/30