unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Daniel Colascione <dancol@dancol.org>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: emacs-devel@gnu.org
Subject: Re: RFC: flicker-free double-buffered Emacs under X11
Date: Thu, 27 Oct 2016 16:10:21 -0700	[thread overview]
Message-ID: <r025oa258k2q.fsf@dancol.org> (raw)
In-Reply-To: <1706d8c5-118b-7d68-bd25-1f95b1787aa2@cs.ucla.edu> (Paul Eggert's message of "Thu, 27 Oct 2016 15:18:38 -0700")

Paul Eggert <eggert@cs.ucla.edu> writes:

> Thanks for working on this.
>
> I tried building with that patch, and had problems because your email
> client munged the patch. I cleaned it up by hand and arrived at the
> attached patch instead. (It needs a better commit message of course.)
> Maybe next time you could attach the output of git-format-patch.

I need to get Gnus working on that machine. I'd hoped Squirrelmail would
have been too simplistic to munge the patch, but I was wrong.

> Although the resulting system builds under Fedora 24 x86-64 with GTK,
> I can't tell any difference in flickering. I don't see much flicker
> without the patch, or with it. (I am using X, not Wayland.) Maybe my
> eyes are not good enough....

I've found the flickering while editing to be very machine-dependent. It
was driving me nuts on mine, which is why I wrote the patch. Flickering
while resizing seems to be a more general problem though.

I've found I can reliably reproduce the flickering by isearching for a
string that appears in a buffer only once, then leaning on C-s.

> I don't see the need to expose double-buffering to Lisp via
> x-double-buffered-p or inhibit-double-buffering. Unless there's a
> demonstrated need, I'd remove these from the Lisp interface, to
> simplify it.

I'll feel more comfortable about removing the lisp interface (and so any
way for users to this the thing off) once we're sure it's not
causing problems.

> The configure.ac change should use AC_CACHE_CHECK.

None of the other X extension checks do. I'm sure AC_CACHE_CHECK is
great, but it feels out of scope.

> set_up_x_back_buffer should be a static function, since it's not used
> outside its module.

Thanks; it wasn't always internal to that file. I'll fix the function.

> In C code we typically use comment /* like this */, not // like
> this. Also, the spacing for pointer decls is typically 'type *id', not
> 'type * id' or 'type* id'.

Thanks. I thought I'd gotten rid of all of those. Speaking of comments
though: if we're C99-only anyway now, we might as well allow
C99 comments.



  parent reply	other threads:[~2016-10-27 23:10 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-21  1:32 RFC: flicker-free double-buffered Emacs under X11 Daniel Colascione
2016-10-21  2:27 ` Lars Ingebrigtsen
2016-10-21  2:31   ` Daniel Colascione
2016-10-21  3:24 ` Óscar Fuentes
2016-10-21  3:31   ` Clément Pit--Claudel
2016-10-21  3:41     ` Óscar Fuentes
2016-10-21  3:50       ` Clément Pit--Claudel
2016-10-21  8:23     ` Andreas Schwab
2016-10-21  8:25       ` Andreas Schwab
2016-10-21  3:56 ` Clément Pit--Claudel
2016-10-21  8:49 ` Eli Zaretskii
2016-10-21 11:04   ` Daniel Colascione
2016-10-21 17:43     ` Eli Zaretskii
2016-10-21 18:27       ` Daniel Colascione
2016-10-21 19:27         ` Eli Zaretskii
2016-10-23 20:51           ` Daniel Colascione
2016-10-24  8:05             ` Eli Zaretskii
2016-10-24 18:43               ` Ken Raeburn
2016-10-27 19:06               ` dancol
2016-10-27 19:36                 ` Eli Zaretskii
     [not found]                   ` <db81befd-7a72-58d9-b7a8-107df89bcab3@dancol.org>
2016-10-27 19:56                     ` Daniel Colascione
2016-10-28  6:31                       ` Eli Zaretskii
2016-10-27 22:18                 ` Paul Eggert
2016-10-27 22:46                   ` Clément Pit--Claudel
2016-10-28 13:14                     ` Stefan Monnier
2016-11-01  0:03                       ` Dmitry Gutov
2016-10-27 23:10                   ` Daniel Colascione [this message]
2016-10-28  2:07                     ` Paul Eggert
2016-10-28  7:19                       ` Eli Zaretskii
2016-11-06  3:51                         ` Paul Eggert
2016-11-06 15:46                           ` Eli Zaretskii

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=r025oa258k2q.fsf@dancol.org \
    --to=dancol@dancol.org \
    --cc=eggert@cs.ucla.edu \
    --cc=emacs-devel@gnu.org \
    /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).