From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Carlos Pita Newsgroups: gmane.emacs.bugs Subject: bug#37755: Logic in init_fringe_bitmap should be moved to backends (maybe rif->define_fringe_bitmap) Date: Sun, 27 Oct 2019 11:47:01 -0300 Message-ID: References: <83a7a2gxp0.fsf@gnu.org> <83a79v620e.fsf@gnu.org> <83y2xf4d00.fsf@gnu.org> <83imobvli8.fsf@gnu.org> <83r22ztrxv.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000703c8b0595e575a0" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="109407"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 37755@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Oct 27 15:51:21 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iOjt2-000SIO-IK for geb-bug-gnu-emacs@m.gmane.org; Sun, 27 Oct 2019 15:51:20 +0100 Original-Received: from localhost ([::1]:45542 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iOjt0-0000yA-NM for geb-bug-gnu-emacs@m.gmane.org; Sun, 27 Oct 2019 10:51:18 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34961) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iOjps-0005Me-B5 for bug-gnu-emacs@gnu.org; Sun, 27 Oct 2019 10:48:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iOjpq-0004gN-P9 for bug-gnu-emacs@gnu.org; Sun, 27 Oct 2019 10:48:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:34554) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iOjpq-0004gI-MJ for bug-gnu-emacs@gnu.org; Sun, 27 Oct 2019 10:48:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iOjpq-0001cq-JF for bug-gnu-emacs@gnu.org; Sun, 27 Oct 2019 10:48:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Carlos Pita Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 27 Oct 2019 14:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 37755 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 37755-submit@debbugs.gnu.org id=B37755.15721876446197 (code B ref 37755); Sun, 27 Oct 2019 14:48:02 +0000 Original-Received: (at 37755) by debbugs.gnu.org; 27 Oct 2019 14:47:24 +0000 Original-Received: from localhost ([127.0.0.1]:43375 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iOjpC-0001br-0G for submit@debbugs.gnu.org; Sun, 27 Oct 2019 10:47:24 -0400 Original-Received: from mail-yb1-f182.google.com ([209.85.219.182]:44943) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iOjp9-0001bd-Uv for 37755@debbugs.gnu.org; Sun, 27 Oct 2019 10:47:20 -0400 Original-Received: by mail-yb1-f182.google.com with SMTP id w5so2907991ybs.11 for <37755@debbugs.gnu.org>; Sun, 27 Oct 2019 07:47:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XVBityvtVV1J9nWhixIvmweO5UwFUNeYBebP0n3wKjc=; b=L0G/s4lXV2qq73gAq1JNkiIVYg2uZcPlFRBmA3OeF+LXF4292n6WZsDAIcwaI4/jEy emLciqrHQCSGN5JNwYJHBzHTXM5XMxyi2hF6rtkIpTQebUy1m6Y0NulWWbr9C+HUqgv1 iset+uFq5XdHOxSWc7a4kWtOc8S9pGQ+aMbRjiVuZ/TUSLpb4bj3zmxKd+CSaqhb78vY KBm1jwNkWkJ2NOtD+EYID7O6p+FzmKwO49ifVPG1CCnYEIDdhYykZ39BUdLTVgP+aKTq hnhRePiwsImHeC5jFcSIsORDrWCYWj7H47q6gbiUFKdAhFsYaMmGdi2Q09TyJgu/9sTe SuQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XVBityvtVV1J9nWhixIvmweO5UwFUNeYBebP0n3wKjc=; b=ejJuH4OnDJIgZBqmmJ7NKJy0QPShbUhg7PhZjOtcqQtFEHDxLQh1bzveKnQ7aEEb1H zD/dbFhv6c/FlIiyvv7e8bM9DjuMuso8DWE6n31IdCimoXTMvWXoCusTe9kXG7iQc2Vy spKxgy9ywRM5Qr9XO/xedv/2VKQT84WNQmS8HG2zN0fYDt5dx+CyeVIA9PjUu+nL+guA fzyeYw8cqz8Hl7csBeW0lX+TO+k3xQw3UyrleQ3BBuXrooxuw8G57yeiL5Y+X/gFBBHi O9wt12xbYlNYDKFxgrTNxji7x4upvGazSASk+i4VSmMlF0OG5T9OTYZVtSrtqpR1jzkT NI6w== X-Gm-Message-State: APjAAAVRbIHbyLhGZXnaWa+H+J3Y0VEEIPsWOR0WqOnAQqTlLOvEcG+K DpsV0/PM9UddEUIwAccrwxi0xyAwDUjOu99FCEw= X-Google-Smtp-Source: APXvYqw5qZUbt1o7kGPQqPEdSNj5SkP/BfwjmEdNUyYf9TvK1zJpl1pG3WGRpgjUI9U9apTvDbGpmFske+S8iC8DWDA= X-Received: by 2002:a05:6902:4e4:: with SMTP id w4mr5763495ybs.263.1572187633891; Sun, 27 Oct 2019 07:47:13 -0700 (PDT) In-Reply-To: <83r22ztrxv.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:170249 Archived-At: --000000000000703c8b0595e575a0 Content-Type: text/plain; charset="UTF-8" > > > > > Ok, I'm not sure about how dumping works, but the patterns that you > store are backend specific. Does the > > dumper take that into account? > > The pdump file, like the Emacs binary, is architecture-specific. So > yes, this is inherently taken into account. > I kept thinking about this and there is also the fact that is not only the architecture (I mean x, w32, ns, endianness) that is assumed in that bit shuffling but also, for example, if we have cairo or pure xlib backend, and that's because I'm quite sure that code was written with the input format assumed by the rif (even if the rif still doesn't exist at that point) in mind. Again, I don't know about the dumper but my intuition says there is something potentially wrong in this arrangement. What I proposed is: 1. Static initialization of fringe rif/platform-independent structures, that I guess will be dumped. 2. Prepare. Per-rif initialization of the rif/platform-dependent structures. This shouldn't affect the independent structures, although in some cases the original bit pattern is still destructively changed because it was simpler to keep the existing implementation. 3. Draw. Rendering of the rif/platform-dependent structures to the screen. What you argue for is: 1. Idem. 1'. Init. Initialization of the platform-dependent but rif->independent structures. 2'. Prepare. Initialization of the rif/platform-dependent structures from the platform-dependent but rif->independent structures. 3. Idem. Now 1' is just cheap bit shuffling of some twenty or so standard bitmaps having an average grid of 8x8 bits. Also there are might be bugs if output patterns are not rif specific and the dumper is unaware of that (again I can't say for sure because of my lack of knowledge of the dumper). Moreover, having 1' and 2' merged in 2 may actually speed things up, because there is no need for two separate iterations over the bitmaps, the first one producing the bit pattern for the second one. It's natural to simply iterate over the original pattern and directly produce the input expected by the particular rendering backend. So, having exposed my reasoning as detailed as I could, and once again, are you sure that you want to keep that phase 1' just to save some milli (micro?) seconds, if any? There is a price in code complexity and the risk of coupling fringe.c too much with backend specific logic. Also, suppose that there is a problem with this cairo vs xlib decision hardcoded there, before the dumping happens. One option is to move that xlib vs cairo decision to the rif (that is to 2 or 2' above). And this way you will be converging to an empty 1' and 2'->2. --000000000000703c8b0595e575a0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


> Ok, I'm not sure about how dumping works, but the patterns that yo= u store are backend specific. Does the
> dumper take that into account?

The pdump file, like the Emacs binary, is architecture-specific.=C2=A0 So yes, this is inherently taken into account.

I kept thinking about this and t= here is also the fact that is not only the architecture (I mean x, w32, ns,= endianness) that is assumed in that bit shuffling but also, for example, i= f we have cairo or pure xlib backend, and that's because I'm quite = sure that code was written with the input format assumed by the rif (even i= f the rif still doesn't exist at that point) in mind. Again, I don'= t know about the dumper but my intuition says there is something potentiall= y wrong in this arrangement.

What I proposed is:

1. Static initialization of=C2=A0fringe rif/platform-independent structure= s, that I guess will be dumped.

2. Prepare. Per-rif initialization of the rif/platform-dependent = structures. This shouldn't affect the independent structures, although = in some cases the original bit pattern is still destructively changed becau= se it was simpler to keep the existing implementation.

3. Draw. Rendering of the rif/platform-depen= dent structures to the screen.

What you argue for is:

1. Idem.

1'. I= nit. Initialization of the platform-dependent but rif->independent struc= tures.

2'. Prepare.= =C2=A0Initialization of the rif/plat= form-dependent structures from the platform-dependent but rif->independe= nt structures.

3. Idem.

Now 1' is just cheap bit shuffling of some twenty or so stand= ard bitmaps having an average grid of 8x8 bits. Also there are might be bug= s if output patterns are not rif specific and the dumper is unaware of that= (again I can't say for sure because of my lack of knowledge of the dum= per).
=
M= oreover, having 1' and 2' merged in 2 may=C2=A0actually=C2=A0speed things up, because there is no need for two separate ite= rations over the bitmaps, the first one producing the bit pattern for the s= econd one. It's natural to simply iterate over the original pattern and= directly produce the input expected by the particular rendering backend.

So, havi= ng exposed my reasoning as detailed as I could, and once again, are you sur= e that you want to keep that phase 1' just to save some milli (micro?) = seconds, if any? There is a price in code complexity and the risk of coupli= ng fringe.c too much with backend specific logic. Also, suppose that there = is a problem with this cairo vs xlib decision hardcoded there, before the d= umping happens. One option is to move that xlib vs cairo decision to the ri= f (that is to 2 or 2' above). And this way you will be converging to an= empty 1' and 2'->2.
--000000000000703c8b0595e575a0--