From: Carlos Pita <carlosjosepita@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 37755@debbugs.gnu.org
Subject: bug#37755: Logic in init_fringe_bitmap should be moved to backends (maybe rif->define_fringe_bitmap)
Date: Tue, 15 Oct 2019 16:04:09 -0300 [thread overview]
Message-ID: <CAELgYhcwut8=oDGpYS7b1X7T0pkHAgmORopWmkJWUh1mW4BGZg@mail.gmail.com> (raw)
In-Reply-To: <83a7a2gxp0.fsf@gnu.org>
(Sorry, forgot to CC debbugs, resending all together below)
Hi Eli,
I've sketched the tree of define/init calls below and I believe I
pretty much understand how the initialization sequence works now and
I'm ready to think about how to properly extend the redisplay
interface in order to include init_fringe_bitmap.
But could you check that my understanding of the flow is sound?
# On emacs startup initialize all standard bitmaps but
# postponing rif->define_fringe_bitmap until frame creation
init_fringe_once
init_fringe_once_for_pdumper
for each standard bitmap
init_fringe_bitmap (oncep = 1)
since oncep: do not try to destroy previous
since !rif: do not rif->define_fringe_bitmap
# When a frame is created, actually call rif->define_fringe_bitmap
# for each standard bitmap and also for lisp defined
# bitmaps that were created in a daemon with no frame / rif
gui_init_fringe (I assume this is called once per frame)
for each standard bitmap
rif->define_fringe_bitmap
for each additional bitmap (recently introduced by [1])
rif->define_fringe_bitmap
# When defined from lisp do both steps at once (init and rif->define)
# except that we're in daemon with no frame / rif
define-fringe-bitmap (lisp)
init_fringe_bitmap (oncep = 0)
when rif && !oncep:
since !oncep: do destroy previous (if any)
since rif: do rif->define_fringe_bitmap (if not in daemon)
Also, I understand the roles of init_fringe_bitmap and define_fringe_bitmap as:
init_fringe_bitmap
Initialize bitmap as far as possible without assuming there is a rif/frame
available. For example, bit shuffling, endianness stuff.
define_fringe_bitmap
Do the remaining, backend specific, initialization, which is now possible
because we have a rif/frame. For example, create Cairo surfaces.
Now I see a problem here: abstracting from the platform/backend by
encapsulating platform/backend related logic in the rif is only
possible when there is a rif at hand! And there is no rif when there
is no frame. So that's probably the reason why quite a few
platform-specific assumptions have leaked into fringe.c. The sad part
is how coupled are those bit manipulations to those backends, it's not
like there is some platform-specific part first and then a
backend-specific part, because both are too intermingled and they
logically belong together.
So I'm again tempted to move init into define, I don't think there is
any real gain in splitting the initialization this way, it's not like
the initial part is time consuming or resource intensive so we better
do it ASAP or whatever and, as I've said, it neither provides an
orthogonal abstraction, there is no cartesian product of platforms and
backends here, so to speak. And part of the complexity of the
initialization sequence above is due to this split.
What do you think?
I'll be sending a patch quite soon.
---
[1] [PATCH] Fix initialization of user-defined fringe bitmaps in daemon
On Tue, Oct 15, 2019 at 6:33 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Carlos Pita <carlosjosepita@gmail.com>
> > Date: Mon, 14 Oct 2019 23:30:08 -0300
> >
> > In fringe.c you have init_fringe_bitmap with this structure:
> >
> > ```
> > #if defined (HAVE_X_WINDOWS)
> > ...
> > #ifdef USE_CAIRO
> > ...
> > #endif
> > ...
> > #endif
> > #ifdef HAVE_NTGUI
> > ...
> > #endif
> > if (!once_p)
> > {
> > ....
> > rif->define_fringe_bitmap (...)
> > ....
> > }
> > ```
> >
> > Now, this is backend specific code that should be moved behind the
> > redisplay_interface.
>
> Yes, it should.
>
> > It seems to me that the obvious candidate to host that code is
> > define_fringe_bitmap.
>
> No, I think we need another interface, as define_fringe_bitmap is used
> directly from other places.
next prev parent reply other threads:[~2019-10-15 19:04 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-15 2:30 bug#37755: Logic in init_fringe_bitmap should be moved to backends (maybe rif->define_fringe_bitmap) Carlos Pita
2019-10-15 9:33 ` Eli Zaretskii
2019-10-15 19:04 ` Carlos Pita [this message]
2019-10-15 19:45 ` Carlos Pita
2019-10-16 20:18 ` Carlos Pita
2019-10-16 22:07 ` Carlos Pita
2019-10-20 12:21 ` Eli Zaretskii
2019-10-20 15:47 ` Carlos Pita
2019-10-20 16:07 ` Eli Zaretskii
2019-10-20 16:32 ` Carlos Pita
2019-10-26 10:39 ` Eli Zaretskii
2019-10-26 15:46 ` Carlos Pita
2019-10-26 16:03 ` Eli Zaretskii
2019-10-26 16:11 ` Carlos Pita
2019-10-27 14:47 ` Carlos Pita
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAELgYhcwut8=oDGpYS7b1X7T0pkHAgmORopWmkJWUh1mW4BGZg@mail.gmail.com' \
--to=carlosjosepita@gmail.com \
--cc=37755@debbugs.gnu.org \
--cc=eliz@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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.