Re: Emacs, colors and gdk-pixbuf.

[David Kastrup <dak@gnu.org>]

"Jan D." <jan.h.d@swipnet.se> writes:

> Some time ago there was some discussion about improving image and
> color handling in Emacs.

Meaning that I said "oh this sucks so bad, can't be do something
about it?".  And of course the easiest way out is to use existing
code that sucks less.  There is a disadvantage of course: it is not
nice if the only Emacs that offers reasonable performance and
semantics for images and colors is the GTK version.  There are two
answers to that:

a) other toolkits usually should also have their own favorite ways of
dealing with the same problem, so one could try shifting work load
more into the toolkits if that is found to be the case.

b) the generic Emacs code for handling the stuff gets an overhaul.

> One suggestion as to use gdk-pixbuf to handle images.  I have made
> some tests, the actual code to get gdk-pixbuf in is not that big.

The problem is not to get gdk-pixbuf or other stuff "in".  The
problem is making sure that everything it does well no longer needs
to be tampered with by Emacs in any way.

Now Emacs does have one particular frame-specific setting, the gamma
correction, that would probably need some thought to integrate well.
And color allocation of Emacs is abysmal.

> I haven't actually checked if this does make color handling
> better.

There needs to be one consistent strategy for color allocation also
for text/borders/etc.  Gdk should be able to be used for that.

> First, gdk-pixbuf is inherently single displayed.  This means that
> Emacs would be limited to one display.  Since GTK also is
> single-displayed (perhaps not 2.2, there has been talk about some
> changes, I haven't checked this yet), we could make gdk-pixbuf the
> default for GTK.

>From the release announcements:

    GTK+-2.1.5 is now available for download at:

     ftp://ftp.gtk.org/pub/gtk/v2.1/

    This is the final prerelease before GTK+-2.2. The major 
    change as compared to the stable GTK+-2.0.6 is support for
    multiple displays and multiple screens in GDK, although there are
    numerous minor changes as well.

Since Emacs is potentially multiheaded (see, for example, the
talk-connect function), it would probably be better if the GTK port
followed suit where possible and supported.  I _do_ have the nagging
suspicion that multihead in Emacs might be broken anyway, that it
might possibly behave erratically when confronted with a mixture of
displays with different display characteristics and color depths,
perhaps even a tty among them.  XEmacs deals with part of this problem
through specifiers (which I don't really understand) which it
instantiates into a displayed object when confronted with a particular
locale (such as a display with its own characteristics).

> The part of gdk-pixbuf is the part that renders into X11.  Emacs
> could use its own version of this code, suitable modified.  Is that
> something people think is OK (using private versions of other
> libraries)?  Must license issues be investigated or is it OK to
> modify stuff from GTK?

There are people more suitable than myself to answer this on this
list.  If you don't get an answer soon, I can give you a guess at what
it might be.

> Another thing is that gdk-pixbuf may have been compiled with image
> support that is different from the one Emacs has today
> (i.e. gdk-pixbuf may not have, for example, TIFF support compiled
> in).  Should we try to make a configure test to see what image types
> gdk-pixbuf supports, and then fall back to "native" support for the
> others?  Or just fail at runtime if an image type is used that
> gdk-pixbuf supports?

Better to fail when an image type is used that is _not_
supported...  I'd not try making an odd mixture in one executable.  Of
course, this might mean that EPS images are scheduled for extinction.
I might have been the only one that was as foolish to try using them
in a serious application (preview-latex) anyhow, and they were and
still are completely unusable which is why preview-latex has been
reworked to do its own handling of GhostScript for image conversion.
I don't think that many people would particularly notice their loss.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum