GNOME Bugzilla – Bug 352500
misdisplays ordinary pbm
Last modified: 2010-07-10 04:08:15 UTC
Forwarded from: https://launchpad.net/distros/ubuntu/+source/eog/+bug/57125 See attached screenshot showing strange diagonal stripy artefacts. bug.png is the screenshot of my whole screen showing eog misbehaving but ImageMagick working. t.pbm is the file in question. Here is the output of xdpyinfo: liberator:~> xdpyinfo name of display: :0.0 version number: 11.0 vendor string: The X.Org Foundation vendor release number: 60801000 maximum request size: 16777212 bytes motion buffer size: 256 bitmap unit, bit order, padding: 32, LSBFirst, 32 image byte order: LSBFirst number of supported pixmap formats: 7 supported pixmap formats: depth 1, bits_per_pixel 1, scanline_pad 32 depth 4, bits_per_pixel 8, scanline_pad 32 depth 8, bits_per_pixel 8, scanline_pad 32 depth 15, bits_per_pixel 16, scanline_pad 32 depth 16, bits_per_pixel 16, scanline_pad 32 depth 24, bits_per_pixel 32, scanline_pad 32 depth 32, bits_per_pixel 32, scanline_pad 32 keycode range: minimum 8, maximum 255 focus: window 0x3e00022, revert to PointerRoot number of extensions: 30 BIG-REQUESTS DAMAGE DOUBLE-BUFFER DPMS Extended-Visual-Information GLX LBX MIT-SCREEN-SAVER MIT-SHM MIT-SUNDRY-NONSTANDARD RANDR RECORD RENDER SECURITY SGI-GLX SHAPE SYNC TOG-CUP X-Resource XC-APPGROUP XC-MISC XFIXES XFree86-Bigfont XFree86-DGA XFree86-Misc XFree86-VidModeExtension XInputExtension XKEYBOARD XTEST XVideo default screen number: 0 number of screens: 1 screen #0: dimensions: 1600x1200 pixels (406x305 millimeters) resolution: 100x100 dots per inch depths (7): 24, 1, 4, 8, 15, 16, 32 root window id: 0x40 depth of root window: 24 planes number of colormaps: minimum 1, maximum 1 default colormap: 0x20 default number of colormap cells: 256 preallocated pixels: black 0, white 16777215 options: backing-store NO, save-unders NO largest cursor: 64x64 current input event mask: 0xd2001d KeyPressMask ButtonPressMask ButtonReleaseMask EnterWindowMask StructureNotifyMask SubstructureRedirectMask PropertyChangeMask ColormapChangeMask number of visuals: 8 default visual id: 0x23 visual: visual id: 0x23 class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x24 class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x25 class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x26 class: TrueColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x27 class: DirectColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x28 class: DirectColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x29 class: DirectColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits visual: visual id: 0x2a class: DirectColor depth: 24 planes available colormap entries: 256 per subfield red, green, blue masks: 0xff0000, 0xff00, 0xff significant bits in color specification: 8 bits liberator:~> (attachments will follow shortly) http://librarian.launchpad.net/3962587/bug.png (screenshot) http://librarian.launchpad.net/3962602/t.pbm (file in question)
This seems to be a problem with GdkPixbuf, because it shows up as well when showing the image with a GtkImage widget.
I confirm this as a gdk-pixbuf bug. It appears in F-spot and GThumb too. Re-assigning to gtk+/gdk-pixbuf
Looks like pnm_read_ascii_scanline should simply fill the pixbuf, rather than trying to collect bits and then call that explode function.
I believe I fixed this a while ago. Reopen if not.
Not fixed with GTK 2.10.3 and eog 2.16.0.1, works nicely with gimp 2.2.13 though - might be fixed in GTK 2.10.4 though - although ftp://ftp.gnome.org/pub/GNOME/sources/gtk+/2.10/gtk+-2.10.4.news doesn't look like it.
From gdk-pixbuf/ChangeLog: 2006-09-22 Matthias Clasen <mclasen@redhat.com> * === Released 2.10.4 === 2006-09-06 Matthias Clasen <mclasen@redhat.com> * io-pnm.c: Simplify and fix reading of ASCII images. Sorry that I forgot to mention that fix in the NEWS
Thanks a lot - I'll report back with 2.10.4 - thanks again, you ROCK!