From: martin rudalics <rudalics@gmx.at>
To: Stefan <monnier@iro.umontreal.ca>
Cc: "Christian Lynbech" <christian@defun.dk>,
"James Cloos" <cloos@jhcloos.com>,
"\"Kan-Ru Chen (陳侃如)\"" <kanru@kanru.info>,
emacs-devel@gnu.org
Subject: Re: Redisplay problems?
Date: Thu, 20 Mar 2014 20:22:38 +0100 [thread overview]
Message-ID: <532B3FFE.5020403@gmx.at> (raw)
In-Reply-To: <jwvfvmduk91.fsf-monnier+emacs@gnu.org>
> Yes, tho I'm not sure I agree with "subsumes": according to the comment,
> setting more things "garbaged" may cause some frame's content to stay
> blank for a while (because Emacs is in the middle of something which
> prevents redisplay from taking place).
OK. But the major issue is to prevent a frame's contents to stay blank
forever (unless the user intervenes in some way or the other).
> And of course, the frame's "garbaged" bit may not always be needed: if
> the frame was simply iconified+deiconified without any other change,
> there's no need to recompute matrices nor redraw anything, since it's
> pretty much the same as obscuring the frame with another and then
> exposing it again.
Yes, that's the main difference. But it requires to carefully keep
track of changes via the `garbaged' slot.
> I'm not 100% clear either, but my current understanding is that
> "garbaged" means that the frame needs to be fully redrawn
... where "fully" means all windows?
> in the
> following sense:
>
> Normal redisplay takes place by first computing new matrices, then
> comparing the old matrices to the new matrices to discover what needs to
> be changed on screen, then redrawing the parts that have changed.
>
> So "garbaged" means that we should not try to only redraw the parts that
^^^
> have changed.
I'm not sure I follow you here. If we do a resize of the frame we may
need larger matrices so we tell the display engine via the resized_p
slot. If a change is restricted to a certain buffer or window only, we
can tell the display engien which one is affected. Other from that what
kind of guidance can you possibly give to the display engine?
> Note that the drawing that takes place in response to Expose events is
> not a "redraw": "redraw" is when a change inside Emacs causes a need to
> change the display, whereas expose events are due to changes outside
> of Emacs.
But it's a redraw when we expose a hitherto invisible/obscured frame
whose contents have changed while it was invisible/obscured.
> Part of the reason it's still fuzzy is that xdisp.c seems to recompute
> the matrices when it finds a "garbaged" frame,
But we do have to compute the new matrices to know whether they have
changed. I'm fully confused now.
> so it seems that it
> doesn't just cause it to "redraw". I have the impression that this is
> a mistake in that it's more work than needed, and also in that some code
> relies on that behavior (i.e. it sets the bit to cause a complete
> redisplay+redraw).
What is the "less work" that's needed?
martin
next prev parent reply other threads:[~2014-03-20 19:22 UTC|newest]
Thread overview: 90+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-10 20:37 Redisplay problems? Christian Lynbech
2014-03-13 20:34 ` Eli Zaretskii
2014-03-15 18:10 ` James Cloos
2014-03-18 10:48 ` Kan-Ru Chen (陳侃如)
2014-03-18 16:06 ` Eli Zaretskii
2014-03-18 16:17 ` Óscar Fuentes
2014-03-18 16:46 ` Eli Zaretskii
2014-03-18 16:53 ` Óscar Fuentes
2014-03-18 17:00 ` Christian Lynbech
2014-03-18 17:09 ` Eli Zaretskii
2014-03-18 21:18 ` Óscar Fuentes
2014-03-19 0:55 ` Kan-Ru Chen (陳侃如)
2014-03-20 17:59 ` Stefan
2014-03-20 19:37 ` Óscar Fuentes
2014-03-18 18:46 ` James Cloos
2014-03-19 16:26 ` martin rudalics
2014-03-19 18:04 ` Óscar Fuentes
2014-03-20 0:54 ` Stefan
2014-03-20 9:52 ` martin rudalics
2014-03-20 16:07 ` Glenn Morris
2014-03-20 19:23 ` martin rudalics
2014-03-20 4:46 ` Stefan
2014-03-20 9:52 ` martin rudalics
2014-03-20 12:45 ` Stefan
2014-03-20 14:01 ` Stefan
2014-03-20 17:22 ` Eli Zaretskii
2014-03-20 18:00 ` Stefan
2014-03-20 18:19 ` Eli Zaretskii
2014-03-20 18:12 ` Eli Zaretskii
2014-03-20 20:55 ` Stefan Monnier
2014-03-21 7:37 ` Eli Zaretskii
2014-03-21 12:59 ` Stefan
2014-03-21 16:12 ` Eli Zaretskii
2014-03-21 19:31 ` Stefan Monnier
2014-03-22 7:43 ` Eli Zaretskii
2014-03-22 13:48 ` Stefan
2014-03-22 13:53 ` martin rudalics
2014-03-22 15:37 ` Stefan
2014-03-22 14:29 ` Eli Zaretskii
2014-03-22 15:42 ` Stefan
2014-03-22 16:07 ` Eli Zaretskii
2014-03-22 18:43 ` Stefan
2014-03-22 19:08 ` Eli Zaretskii
2014-03-24 1:58 ` Stefan
2014-03-24 3:55 ` Eli Zaretskii
2014-03-24 8:32 ` David Kastrup
2014-03-24 16:58 ` Eli Zaretskii
2014-03-24 18:15 ` Stefan
2014-03-24 19:34 ` Eli Zaretskii
2014-03-24 12:33 ` Stefan
2014-03-24 17:36 ` Eli Zaretskii
2014-03-24 18:07 ` Stefan
2014-03-24 19:30 ` Eli Zaretskii
2014-03-24 20:43 ` Stefan
2014-03-25 3:52 ` Eli Zaretskii
2014-03-25 13:10 ` Stefan Monnier
2014-03-26 15:28 ` Eli Zaretskii
2014-03-27 13:55 ` Stefan Monnier
2014-03-27 17:33 ` Eli Zaretskii
2014-03-27 21:13 ` Stefan Monnier
2014-03-28 7:15 ` Eli Zaretskii
[not found] ` <<jwvzjkeqvcg.fsf-monnier+emacs@gnu.org>
[not found] ` <<83d2h9yo5m.fsf@gnu.org>
2014-03-26 15:37 ` Drew Adams
2014-03-22 19:13 ` Eli Zaretskii
2014-03-24 1:56 ` Stefan
2014-03-20 19:22 ` martin rudalics [this message]
2014-03-20 20:36 ` Eli Zaretskii
2014-03-21 8:03 ` martin rudalics
2014-03-21 8:36 ` Eli Zaretskii
2014-03-21 9:51 ` martin rudalics
2014-03-21 10:29 ` Eli Zaretskii
2014-03-22 2:00 ` Kan-Ru Chen (陳侃如)
2014-03-22 2:37 ` Stefan Monnier
2014-03-22 3:38 ` Kan-Ru Chen (陳侃如)
2014-03-22 7:28 ` Eli Zaretskii
2014-03-21 13:08 ` Stefan
2014-03-21 16:19 ` Eli Zaretskii
2014-03-21 19:42 ` Stefan Monnier
2014-03-22 7:49 ` Eli Zaretskii
2014-03-22 13:56 ` Stefan
2014-03-22 14:50 ` Eli Zaretskii
2014-03-20 21:00 ` Stefan Monnier
2014-03-21 7:41 ` Eli Zaretskii
2014-03-21 13:02 ` Stefan
2014-03-21 16:13 ` Eli Zaretskii
2014-03-21 19:39 ` Stefan Monnier
2014-03-22 7:47 ` Eli Zaretskii
2014-03-22 13:49 ` Stefan
2014-03-22 14:29 ` Eli Zaretskii
2014-03-20 16:19 ` Eli Zaretskii
2014-03-27 21:17 ` Christian Lynbech
[not found] <<m2bnxdg58p.fsf@defun.dk>
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=532B3FFE.5020403@gmx.at \
--to=rudalics@gmx.at \
--cc=christian@defun.dk \
--cc=cloos@jhcloos.com \
--cc=emacs-devel@gnu.org \
--cc=kanru@kanru.info \
--cc=monnier@iro.umontreal.ca \
/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).