bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#36337: 26.1; XBM images are sometimes not displayed correctly


From: Eli Zaretskii
Subject: bug#36337: 26.1; XBM images are sometimes not displayed correctly
Date: Fri, 28 Jun 2019 15:43:15 +0300

> From: Pip Cet <pipcet@gmail.com>
> Date: Fri, 28 Jun 2019 08:29:04 +0000
> Cc: triska@metalevel.at, 36337@debbugs.gnu.org
> 
> On Fri, Jun 28, 2019 at 7:58 AM Eli Zaretskii <eliz@gnu.org> wrote:
> > > From: Pip Cet <pipcet@gmail.com>
> > > Date: Sun, 23 Jun 2019 19:16:04 +0000
> 
> Having thought about it, I would rather require the bool vector passed
> to XBM to be in the right format: the width can be 100, but the
> stride, specified by a new :stride argument, must be the smallest
> multiple of 8 greater or equal to the width. If you don't want that,
> pass a vector of bool vectors which is copied together, but let's not
> pretend we can take a 10,000-bit bool vector and display it
> efficiently.

I'm not sure I understand what you mean, exactly.  Can you show an
example of the new API?

> I think my mistake was not to distinguish between stride and width,
> but we can easily do so. Shall I prepare a patch?

Maybe a patch will be the best means to explain what you mean, but if
you'd like to show it before you invest too much effort, please show
an example.

> > I'm sorry, but I object to removing a feature that has been with us
> > since Emacs 19
> 
> Okay. Thanks for taking the time to explain. One serious question,
> though unrelated to the current bug: do you think it is just the Lisp
> API that we're stuck with for eternity, or is the C representation of
> bool vectors forbidden territory as well?

The external public APIs are the primary concern; they should be
changed in backward-compatible manner (e.g., by adding &optional
arguments or adding compatible interpretations of existing arguments).
C-level implementation details matter only inasmuch as they affect the
provided features visible by callers (e.g., signaling errors in some
cases or producing certain results in specific use cases), and also if
they affect other related functionalities.

> > What you propose is not what I think I had in mind.  I meant to extend
> > make-bool-vector (or make a new function, if extending proves
> > inconvenient or inelegant) that generates a bool-vector given 2
> > dimensions, not one.  Then such vectors could be used to create XBM
> > images of arbitrary dimensions.  We could even call this new function
> > something like make-xbm-data or somesuch, if its utility is limited to
> > XBM images.
> 
> How is a vector of bool vectors different from a 2-dimensional bool
> vector, from the point of view of Lisp?

I didn't mean to introduce a 2-dimensional bool-vector, I meant to be
able to create a unidimensional vector in a way that it could be then
used as data for XBM.  In practice, that means the number of bits in
the vector will be more than strictly required by multiplying the two
dimensions.

> As for the problem at hand, how would you feel about adding a :stride
> argument which must be a multiple of 8 and ensures that the bool
> vector passed to the XBM code has the right memory layout?

Could be fine, but I'd like to see an example of using such an API
before I make up my mind.

Thanks.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]