bug#38109: 27.0.50; xpm image scaling doesn't work

classic Classic list List threaded Threaded
38 messages Options
12
Reply | Threaded
Open this post in threaded view
|

bug#38109: 27.0.50; xpm image scaling doesn't work

Emacs - Bugs mailing list

I *think* scaling of xpm images used to work (maybe back when
ImageMagick did the scaling?) - but it doesn't now, e.g. if you go:

  (insert-image (create-image "/usr/src/emacs/etc/images/smilies/medium/wry.xpm" nil nil :scale 20.0))

a tiny 16x16 image is inserted. The expected result was a huge 320x320
image.

If I convert the image to png:

  convert /usr/src/emacs/etc/images/smilies/medium/wry.xpm /tmp/wry.gif

and insert it with:

  (insert-image (create-image "/tmp/wry.gif" nil nil :scale 20.0))

I do get a bug 320x320 pixel image in my buffer.

(Interestingly, if I convert it to PNG and insert it, I get a 320x320
pixel image, with the original small 16x16 graphics inside it, so
scaling seems to not work for PNG either, in a different way.)

This is what it looks like in emacs -Q:




In GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.12)
 of 2019-10-31 built on tullinupnew
Repository revision: 058e293fddeaa7821f13055b451951360a135b0c
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12004000
System Description: Debian GNU/Linux bullseye/sid

Recent messages:
Reading active file via nnml...done
Reading active file from archive via nnml...
Opening nnml server on archive...done
Reading active file from archive via nnml...done
Reading active file via nnir...done
Reading active file via nndraft...done
Opening nnml server...done
Registering 1 specific articles as ham using backend spam-use-move
Opening nntp server on gm...done
Mark set

Configured using:
 'configure --without-pop'

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND GPM DBUS GSETTINGS GLIB NOTIFY INOTIFY
ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM THREADS LIBSYSTEMD PDUMPER LCMS2
GMP

Important settings:
  value of $LANG: en_GB.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Group

Minor modes in effect:
  gnus-topic-mode: t
  gnus-undo-mode: t
  pixel-scroll-mode: t
  engine-mode: t
  global-magit-file-mode: t
  magit-auto-revert-mode: t
  global-git-commit-mode: t
  dumb-jump-mode: t
  which-function-mode: t
  global-auto-complete-mode: t
  shell-dirtrack-mode: t
  save-place-mode: t
  jabber-activity-mode: t
  winner-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t

Load-path shadows:
/usr/share/emacs/site-lisp/elpa-src/ess-18.10.2/debian-autoloads hides /usr/share/emacs/site-lisp/elpa-src/dpkg-dev-el-37.0/debian-autoloads
/usr/share/emacs/site-lisp/elpa-src/boxquote-2.1/boxquote hides ~/elisp/extra/boxquote
~/elisp/let-alist/let-alist hides ~/elisp/extra/let-alist
~/elisp/with-editor/with-editor hides ~/elisp/extra/with-editor
~/elisp/with-editor/with-editor-autoloads hides ~/elisp/extra/with-editor-autoloads
~/elisp/let-alist/let-alist hides /usr/src/emacs/lisp/emacs-lisp/let-alist

Features:
(shadow emacsbug bbdb-gnus-aux misearch multi-isearch shr-color color
canlock ispell bbdb-message sendmail nnir compface gnus-gravatar
gravatar sort smiley gnus-cite mm-archive gnus-async gnus-bcklg gnus-dup
qp gnus-ml gmane gnus-topic paren utf-7 imap rfc2104 epa-file
network-stream nnml bbdb-gnus bbdb-mua nnnil gnus-demon gnus-delay
gnus-draft gnus-agent gnus-srvr gnus-score score-mode nnvirtual nntp
gnus-cache nndraft nnmh mail-extr spam spam-stat bbdb-com gnus-uu yenc
gnus-msg gnus-html url-queue help-fns radix-tree url-cache bbdb-picture
gnus-art mm-uu mml2015 mm-view mml-smime smime dig gnus-sum gnus-group
gnus-undo gnus-fun hashcash gnus-start gnus-cloud nnimap nnmail
mail-source utf7 netrc nnoo gnus-spec gnus-int gnus-range gnus-win
gopher shr with-url mm-url gnus nnheader svg pixel-scroll litable
engine-mode gitpatch magithub magithub-ci magithub-issue magithub-cache
magithub-core magit-submodule magit-obsolete magit-blame magit-stash
magit-bisect magit-push magit-pull magit-fetch magit-clone magit-remote
magit-commit magit-sequence magit-notes magit-worktree magit-tag
magit-merge magit-branch magit-reset magit-collab ghub-graphql treepy
graphql ghub url-http url-gw nsm url-auth let-alist magit-files
magit-refs magit-status magit magit-repos magit-apply magit-wip
magit-log magit-diff smerge-mode diff magit-core magit-autorevert
autorevert filenotify magit-process magit-margin magit-mode git-commit
recentf tree-widget magit-git magit-section magit-utils magit-popup
vc-git diff-mode crm log-edit message rmc rfc822 mml mml-sec epa epg
epg-config gnus-util rmail rmail-loaddefs text-property-search mm-decode
mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 mm-util
ietf-drums mail-prsvr mailabbrev mail-utils gmm-utils mailheader
pcvs-util with-editor term disp-table ehelp eshell esh-cmd esh-ext
esh-opt esh-proc esh-io esh-arg esh-module esh-groups esh-util wgrep-ag
wgrep grep ag vc-svn find-dired dumb-jump f dash s ucs-normalize etags
fileloop generator tex-site auto-loads expand-region
cperl-mode-expansions text-mode-expansions html-mode-expansions
er-basic-expansions expand-region-core expand-region-custom which-func
cperl-mode auto-complete-config auto-complete popup cl-extra help-mode
ess-site ess-toolbar ess-mouse mouseme ess-swv ess-noweb
ess-noweb-font-lock-mode ess-jags-d ess-bugs-l essd-els ess-xls-d
ess-vst-d ess-stata-mode ess-stata-lang cc-vars cc-defs make-regexp
ess-sp6w-d ess-sp5-d ess-sp4-d ess-sas-d ess-sas-l ess-sas-a ess-s4-d
ess-s3-d ess-omg-d ess-omg-l ess-arc-d ess-lsp-l ess-sp6-d ess-dde
ess-sp3-d ess-julia julia-mode ess-r-mode ess-r-flymake rx flymake-proc
flymake warnings thingatpt ess-r-xref xref project ess-trns
ess-r-package ess-r-syntax pcase ess-r-completion ess-roxy ess-rd essddr
noutline outline hideshow ess-s-lang speedbar sb-image ezimage dframe
ess-help info reporter ess-mode ess ess-noweb-mode ess-inf ess-tracebug
easy-mmode ess-generics compile ess-utils ido ess-custom executable
tramp tramp-loaddefs trampver tramp-integration files-x tramp-compat
shell pcomplete parse-time iso8601 ls-lisp debian-changelog-mode imenu
add-log dpkg-dev-el saveplace vc vc-dispatcher bbdb derived bbdb-site
timezone bbdb-loaddefs boxquote rect jabber-http-file-upload url
url-proxy url-privacy url-expand url-methods url-history url-cookie
url-domsuf url-util jabber-print-html jabber-otr jabber
jabber-notifications notifications jabber-libnotify dbus jabber-awesome
jabber-osd jabber-wmii jabber-xmessage jabber-festival jabber-sawfish
jabber-ratpoison jabber-tmux jabber-screen jabber-socks5
jabber-ft-server jabber-si-server jabber-ft-client jabber-ft-common
jabber-si-client jabber-si-common jabber-feature-neg jabber-truncate
jabber-time jabber-autoaway time-date jabber-vcard-avatars
jabber-chatstates jabber-events jabber-vcard jabber-avatar mailcap
jabber-activity jabber-watch jabber-modeline advice jabber-ahc-presence
jabber-ahc jabber-version jabber-ourversion jabber-muc-nick-completion
hippie-exp comint ansi-color jabber-browse jabber-search jabber-register
jabber-roster format-spec jabber-presence jabber-muc jabber-bookmarks
jabber-private jabber-muc-nick-coloring hexrgb jabber-widget
jabber-disco wid-edit jabber-chat jabber-history jabber-chatbuffer
jabber-alert jabber-iq jabber-core jabber-console sgml-mode dom ewoc
jabber-keymap jabber-sasl sasl sasl-anonymous sasl-login sasl-plain fsm
jabber-logon jabber-conn srv dns starttls tls jabber-xml xml jabber-menu
jabber-util cl winner ring gnutls puny find-file-from-selection
find-lisp dired dired-loaddefs cap-words superword subword edmacro
kmacro server finder-inf package easymenu browse-url url-handlers
url-parse auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs
password-cache json subr-x map url-vars seq byte-opt gv bytecomp
byte-compile cconv cl-loaddefs cl-lib tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote threads dbusbind inotify lcms2 dynamic-setting
system-font-setting font-render-setting move-toolbar gtk x-toolkit x
multi-tty make-network-process emacs)

Memory information:
((conses 16 903266 194934)
 (symbols 48 41175 5)
 (strings 32 264148 17332)
 (string-bytes 1 11187328)
 (vectors 16 82347)
 (vector-slots 8 2589302 201528)
 (floats 8 706 677)
 (intervals 56 1323 779)
 (buffers 1000 93))

--
 "Please don't "meh" the panopticon. You are                   Adam Sjøgren
  not making things better by doing that."                [hidden email]

emacs27-image-scaling.png (168K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

bug#38109: Updated Emacs to HEAD, consistently not scaling now

Emacs - Bugs mailing list
I just updated my Emacs build to master HEAD now (previously was built
in mid-October), and the results are consitent no scaling for XPM, GIF
and PNG now, as can be seen in this image:


emacsmasterhead-scaling.png (95K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

bug#38109: Updated Emacs to HEAD, consistently not scaling now

Lars Ingebrigtsen
Unknown <[hidden email]> writes:

> I just updated my Emacs build to master HEAD now (previously was built
> in mid-October), and the results are consitent no scaling for XPM, GIF
> and PNG now, as can be seen in this image:

Hm.  Odd.  When I try

(insert-image (create-image "/tmp/foo.png" nil nil :scale 10))

etc, I get the proper scaling with png and gif, but not with xpm.
(Running from HEAD with -Q.)

--
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



Reply | Threaded
Open this post in threaded view
|

bug#38109: Updated Emacs to HEAD, consistently not scaling now

Emacs - Bugs mailing list
Lars writes:

>> I just updated my Emacs build to master HEAD now (previously was built
>> in mid-October), and the results are consitent no scaling for XPM, GIF
>> and PNG now, as can be seen in this image:
>
> Hm.  Odd.

Argh, I tested the wrong Emacs binary. How embarrasing. Ignore my second
email.

> I get the proper scaling with png and gif, but not with xpm. (Running
> from HEAD with -Q.)

I don't, the XPM is unscaled and the PNG is inserted on a large canvas
with the original image unscaled in the corner:

emacsmasterheadforreal-scaling.png (186K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

bug#38109: 27.0.50; xpm image scaling doesn't work

Stephen Berman
In reply to this post by Emacs - Bugs mailing list
On Thu, 07 Nov 2019 22:11:14 +0100 Unknown <[hidden email]> wrote:

> I *think* scaling of xpm images used to work (maybe back when
> ImageMagick did the scaling?) - but it doesn't now, e.g. if you go:
>
>   (insert-image (create-image
> "/usr/src/emacs/etc/images/smilies/medium/wry.xpm" nil nil :scale 20.0))
>
> a tiny 16x16 image is inserted. The expected result was a huge 320x320
> image.
[...]
> Configured features:
> XPM JPEG TIFF GIF PNG RSVG SOUND GPM DBUS GSETTINGS GLIB NOTIFY INOTIFY
> ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF XFT ZLIB
> TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM THREADS LIBSYSTEMD PDUMPER LCMS2
> GMP

On Thu, 07 Nov 2019 22:30:57 +0100 Unknown <[hidden email]> wrote:

> I just updated my Emacs build to master HEAD now (previously was built
> in mid-October), and the results are consitent no scaling for XPM, GIF
> and PNG now [...]

Cf. NEWS:

 ** Emacs now supports resizing and rotating images without ImageMagick.
 All modern systems support this feature.  (On GNU and Unix systems,
 Cairo drawing or the XRender extension to X11 is required for this to
 be available; the configure script will test for it and, if found,
 enable scaling.)

I'm not sure about XRender; I think my X has it, but I only get scaling
(also of XPM and PNG images) with the Cairo build.

Steve Berman



Reply | Threaded
Open this post in threaded view
|

bug#38109: Updated Emacs to HEAD, consistently not scaling now

Lars Ingebrigtsen
In reply to this post by Emacs - Bugs mailing list
Adam Sjøgren <[hidden email]> writes:

> I don't, the XPM is unscaled and the PNG is inserted on a large canvas
> with the original image unscaled in the corner:

I made two PNGs from wry.xpm.

file /tmp/wry*.png
/tmp/wry2.png: PNG image data, 13 x 14, 8-bit/color RGBA, non-interlaced
/tmp/wry.png:  PNG image data, 13 x 14, 2-bit colormap, non-interlaced

With the colormap png, I see the same as you -- no scaling, but a large
canvas.  With the non-colormap one, I get the proper scaling, too.

Odder and odder.

--
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

wry.png (466 bytes) Download Attachment
wry2.png (9K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

bug#38109: Updated Emacs to HEAD, consistently not scaling now

Emacs - Bugs mailing list
Lars writes:

> I made two PNGs from wry.xpm.
>
> file /tmp/wry*.png
> /tmp/wry2.png: PNG image data, 13 x 14, 8-bit/color RGBA, non-interlaced
> /tmp/wry.png:  PNG image data, 13 x 14, 2-bit colormap, non-interlaced
>
> With the colormap png, I see the same as you -- no scaling, but a large
> canvas.  With the non-colormap one, I get the proper scaling, too.

Interesting; the files I tested with:

  $ file wry.*
  wry.gif: GIF image data, version 89a, 16 x 16
  wry.png: PNG image data, 16 x 16, 4-bit colormap, non-interlaced

So that's consistent with what you see. Perhaps testing was done with
RGB(A) images, and not with colormaps/palettes.

--
 "Please don't "meh" the panopticon. You are                   Adam Sjøgren
  not making things better by doing that."                [hidden email]



Reply | Threaded
Open this post in threaded view
|

bug#38109: 27.0.50; xpm image scaling doesn't work

Eli Zaretskii
In reply to this post by Emacs - Bugs mailing list
> Date: Thu, 07 Nov 2019 22:11:14 +0100
> From: Adam Sjøgren via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <[hidden email]>
>
> I *think* scaling of xpm images used to work (maybe back when
> ImageMagick did the scaling?) - but it doesn't now, e.g. if you go:
>
>   (insert-image (create-image "/usr/src/emacs/etc/images/smilies/medium/wry.xpm" nil nil :scale 20.0))
>
> a tiny 16x16 image is inserted. The expected result was a huge 320x320
> image.

You need to build either with XRender support (should be automatic if
you have it installed) or with ImageMagick.  Does config.h define
HAVE_XRENDER to 1?




Reply | Threaded
Open this post in threaded view
|

bug#38109: Updated Emacs to HEAD, consistently not scaling now

Eli Zaretskii
In reply to this post by Lars Ingebrigtsen
> From: Lars Ingebrigtsen <[hidden email]>
> Date: Thu, 07 Nov 2019 22:49:13 +0100
> Cc: [hidden email]
>
> Hm.  Odd.  When I try
>
> (insert-image (create-image "/tmp/foo.png" nil nil :scale 10))
>
> etc, I get the proper scaling with png and gif, but not with xpm.
> (Running from HEAD with -Q.)

Maybe there's some X-specific problem.  I see no problem on
MS-Windows.



Reply | Threaded
Open this post in threaded view
|

bug#38109: 27.0.50; xpm image scaling doesn't work

Emacs - Bugs mailing list
In reply to this post by Eli Zaretskii
Eli writes:

> You need to build either with XRender support (should be automatic if
> you have it installed) or with ImageMagick.  Does config.h define
> HAVE_XRENDER to 1?

It does:

  asjo@tullinup:/usr/src/emacs$ grep HAVE_XRENDER src/config.h
  #define HAVE_XRENDER 1

and ImageMagick isn't defined:

  asjo@tullinup:/usr/src/emacs$ grep HAVE_IMAGEMAGICK src/config.h
  /* #undef HAVE_IMAGEMAGICK */
  /* #undef HAVE_IMAGEMAGICK7 */



Reply | Threaded
Open this post in threaded view
|

bug#38109: Updated Emacs to HEAD, consistently not scaling now

Alan Third
In reply to this post by Emacs - Bugs mailing list
On Thu, Nov 07, 2019 at 11:12:31PM +0100, Adam Sjøgren via Bug reports for GNU Emacs, the Swiss army knife of text editors wrote:

> Lars writes:
>
> > I made two PNGs from wry.xpm.
> >
> > file /tmp/wry*.png
> > /tmp/wry2.png: PNG image data, 13 x 14, 8-bit/color RGBA, non-interlaced
> > /tmp/wry.png:  PNG image data, 13 x 14, 2-bit colormap, non-interlaced
> >
> > With the colormap png, I see the same as you -- no scaling, but a large
> > canvas.  With the non-colormap one, I get the proper scaling, too.
>
> Interesting; the files I tested with:
>
>   $ file wry.*
>   wry.gif: GIF image data, version 89a, 16 x 16
>   wry.png: PNG image data, 16 x 16, 4-bit colormap, non-interlaced
>
> So that's consistent with what you see. Perhaps testing was done with
> RGB(A) images, and not with colormaps/palettes.

OK, that makes sense. Check out the comment and code at line 2593 of
image.c:

    /* FIXME: Do we need to handle all possible bit depths?
       XRenderFindStandardFormat supports PictStandardARGB32,
       PictStandardRGB24, PictStandardA8, PictStandardA4,
       PictStandardA1, and PictStandardNUM (what is this?!).
   
       XRenderFindFormat may support more, but I don't
       understand the documentation.  */
    format = XRenderFindStandardFormat (display,
                                        depth == 32 ? PictStandardARGB32
                                        : depth == 24 ? PictStandardRGB24
                                        : PictStandardA8);
    *picture = XRenderCreatePicture (display, *pixmap, format, 0, &attr);

There should be an error message somewhere telling you that Emacs
doesn’t support scaling with that bit depth.

I guess it should be simple enough to add 4 and 1 bit to the above
which I hope would cover some of the above cases...
--
Alan Third



Reply | Threaded
Open this post in threaded view
|

bug#38109: Updated Emacs to HEAD, consistently not scaling now

Alan Third
On Fri, Nov 08, 2019 at 07:34:07PM +0000, Alan Third wrote:
> On Thu, Nov 07, 2019 at 11:12:31PM +0100, Adam Sjøgren via Bug reports for GNU Emacs, the Swiss army knife of text editors wrote:
>
> I guess it should be simple enough to add 4 and 1 bit to the above
> which I hope would cover some of the above cases...

Although I don’t understand why the png displays unscaled in a big
canvas. We must have missed a check against the Picture member to
prevent it resizing if there is no Picture.

This is at the top of image_set_transform:

    # if !defined USE_CAIRO && defined HAVE_XRENDER
      if (!img->picture)
        return;
    # endif

which should prevent any attempt to scale right at the start... I’m
really not sure what’s going on there.
--
Alan Third



Reply | Threaded
Open this post in threaded view
|

bug#38109: Updated Emacs to HEAD, consistently not scaling now

Emacs - Bugs mailing list
In reply to this post by Emacs - Bugs mailing list
Alan writes:

[...]

> There should be an error message somewhere telling you that Emacs
> doesn’t support scaling with that bit depth.

Indeed there is for the:

  /tmp/wry.png: PNG image data, 16 x 16, 4-bit colormap, non-interlaced

image. But not for the .xpm. Ah, but xpm doesn't go through
image_create_x_image_and_pixmap_1(), so that explains that.

> I guess it should be simple enough to add 4 and 1 bit to the above
> which I hope would cover some of the above cases...

Yes, with this patch:

diff --git a/src/image.c b/src/image.c
index 870f008b14..bb76e9db60 100644
--- a/src/image.c
+++ b/src/image.c
@@ -2585,7 +2585,7 @@ image_create_x_image_and_pixmap_1 (struct frame *f, int width, int height, int d
     {
       if (depth <= 0)
  depth = DefaultDepthOfScreen (FRAME_X_SCREEN (f));
-      if (depth == 32 || depth == 24 || depth == 8)
+      if (depth == 32 || depth == 24 || depth == 8 || depth == 4 || depth == 1)
         {
           XRenderPictFormat *format;
           XRenderPictureAttributes attr;
@@ -2600,12 +2600,16 @@ image_create_x_image_and_pixmap_1 (struct frame *f, int width, int height, int d
           format = XRenderFindStandardFormat (display,
                                               depth == 32 ? PictStandardARGB32
                                               : depth == 24 ? PictStandardRGB24
-                                              : PictStandardA8);
+                                              : depth ==  8 ? PictStandardA8
+                                              : depth ==  4 ? PictStandardA4
+                                              : PictStandardA1);
           *picture = XRenderCreatePicture (display, *pixmap, format, 0, &attr);
         }
       else
         {
-          image_error ("Specified image bit depth is not supported by XRender");
+          Lisp_Object depth_err;
+          XSETINT(depth_err, depth);
+          image_error ("Specified image bit depth (%d) is not supported by XRender", depth_err);
           *picture = 0;
         }
     }

the error in *Messages* doesn't appear.

However the png-image is still not scaled, and still shown in the larger
canvas.

I apparently haven't got Cairo enabled in my build, maybe that's a
problem?

  asjo@tullinup:/usr/src/emacs$ grep CAIRO src/config.h
  /* #undef USE_CAIRO */

An observation: when displaying the colormapped .png,
image_create_x_image_and_pixmap_1() is called twice, the first time
depth is <= 0, and the second time it isn't.



Reply | Threaded
Open this post in threaded view
|

bug#38109: Updated Emacs to HEAD, consistently not scaling now

Lars Ingebrigtsen
In reply to this post by Eli Zaretskii
Eli Zaretskii <[hidden email]> writes:

>> Hm.  Odd.  When I try
>>
>> (insert-image (create-image "/tmp/foo.png" nil nil :scale 10))
>>
>> etc, I get the proper scaling with png and gif, but not with xpm.
>> (Running from HEAD with -Q.)
>
> Maybe there's some X-specific problem.  I see no problem on
> MS-Windows.

Did you try with the test images I posted?  The problem is that png
images with a colormap aren't scaled, but rgb (etc) ones are.

--
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



Reply | Threaded
Open this post in threaded view
|

bug#38109: Updated Emacs to HEAD, consistently not scaling now

Lars Ingebrigtsen
In reply to this post by Alan Third
Alan Third <[hidden email]> writes:

> OK, that makes sense. Check out the comment and code at line 2593 of
> image.c:
>
>     /* FIXME: Do we need to handle all possible bit depths?
>        XRenderFindStandardFormat supports PictStandardARGB32,
>        PictStandardRGB24, PictStandardA8, PictStandardA4,
>        PictStandardA1, and PictStandardNUM (what is this?!).
>
>        XRenderFindFormat may support more, but I don't
>        understand the documentation.  */
>     format = XRenderFindStandardFormat (display,
>                                         depth == 32 ? PictStandardARGB32
>                                         : depth == 24 ? PictStandardRGB24
>                                         : PictStandardA8);
>     *picture = XRenderCreatePicture (display, *pixmap, format, 0, &attr);

But isn't that about the depth of the screen, not the number of bits in
the image?

--
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



Reply | Threaded
Open this post in threaded view
|

bug#38109: Updated Emacs to HEAD, consistently not scaling now

Lars Ingebrigtsen
In reply to this post by Emacs - Bugs mailing list
Adam Sjøgren <[hidden email]> writes:

>> There should be an error message somewhere telling you that Emacs
>> doesn’t support scaling with that bit depth.
>
> Indeed there is for the:
>
>   /tmp/wry.png: PNG image data, 16 x 16, 4-bit colormap, non-interlaced
>
> image. But not for the .xpm. Ah, but xpm doesn't go through
> image_create_x_image_and_pixmap_1(), so that explains that.

Where do you get the error message?

--
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



Reply | Threaded
Open this post in threaded view
|

bug#38109: Updated Emacs to HEAD, consistently not scaling now

Emacs - Bugs mailing list
Lars writes:

> Where do you get the error message?

In the *Messages* buffer.



Reply | Threaded
Open this post in threaded view
|

bug#38109: Updated Emacs to HEAD, consistently not scaling now

Emacs - Bugs mailing list
In reply to this post by Emacs - Bugs mailing list
Alan writes:

> Although I don’t understand why the png displays unscaled in a big
> canvas. We must have missed a check against the Picture member to
> prevent it resizing if there is no Picture.
>
> This is at the top of image_set_transform:
>
>     # if !defined USE_CAIRO && defined HAVE_XRENDER
>       if (!img->picture)
>         return;
>     # endif
>
> which should prevent any attempt to scale right at the start... I’m
> really not sure what’s going on there.

This is what stops the .xpm from being scaled, I think. At least I see
image_set_transform() being called for the .xpm, and that if() is hit
and it returns early.

The colormapped .png, however, passes by that if() and the entire
function is executed.



Reply | Threaded
Open this post in threaded view
|

bug#38109: Updated Emacs to HEAD, consistently not scaling now

Lars Ingebrigtsen
In reply to this post by Emacs - Bugs mailing list
Adam Sjøgren <[hidden email]> writes:

> Lars writes:
>
>> Where do you get the error message?
>
> In the *Messages* buffer.

Hm.  I don't get any on saying

(insert-image (create-image "/tmp/wry.png" nil nil :scale 10))

Do I have to switch error reporting to verbose somehow?

--
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



Reply | Threaded
Open this post in threaded view
|

bug#38109: Updated Emacs to HEAD, consistently not scaling now

Emacs - Bugs mailing list
Lars writes:

>>> Where do you get the error message?
>>
>> In the *Messages* buffer.
>
> Hm.  I don't get any on saying
>
> (insert-image (create-image "/tmp/wry.png" nil nil :scale 10))
>
> Do I have to switch error reporting to verbose somehow?

I may have confused myself.

I get the error in *Messages* the _first_ time I display the .gif.

I only get the error in *Messages* on the .xpm, if it is the first image
I try to insert.

I don't get it on either .png's now (so I maybe have been cross-eyed
when I said I did previously).

This is not for kids.



12