xsplash wallpaper gradients are massively distorted at 16bpp depth

[Oliver Grawert]

Binary package hint: xsplash

on armel architectures where we have to use the framebuffer for all display by default and usually default to 16bpp, xsplash looks very ugly, all gradients on the wallpaper have a massive "stairstepping" effect, please use a wallpaper that can be handled at 16bpp

[Oliver Grawert (ogra)]

while it still looked bearable with the old jaunty wallpaper, the new karmic one looks just awful, please make a version that is usable on 16bpp displays

[Oliver Grawert (ogra)]

all other used wallpapers display fine without such issues btw (gdm, nautilus or the gnome-seession wallpaper before nautilus is started on the desktop)

[Mat Tomaszewski (mat.t.)]

I can confirm that there's nothing wrong with the images themselves (please try viewing them in the browser at 16bpp) - the problem seems to lie within xsplash rendering mechanism.

[Hernando Torque (htorque)]

I can confrm Mat Tomaszewski's observation: I've set the image Xsplash uses as my desktop's wallpaper and there's definitely a difference. It looks like the difference between nearest neighbor and dithering mode when using my graphics software to reduce the bit depth.

[Michael Casadevall (mcasadevall)]

This issue seems to be imx51 specific. I can't reproduce on armel+dove; the images themselves look OK, but there is a natural video distortion. Still, my images look correct compared to the desktop images.

[Michael Casadevall (mcasadevall)]

Please disregard above, it seems I'm blind. I showed a screenshot to ogra, and he can clearly see the issue in it.

[Oliver Grawert (ogra)]

michal sent me this picture (disregard the vertical stripes, they come from a timing issue in the driver), imho it pretty clearly exposes "tree rings"

[Mat Tomaszewski (mat.t.)]

Would converting the image to svg solve the problem?

[Hernando Torque (htorque)]

That wouldn't change anything concerning this bug. The images themselves look ok-ish (yes, gradient banding is visible like described in the other bug) when used as GDM and session backgrounds so it's just Xsplash doing something wrong.

[Oliver Grawert (ogra)]

right, i tested with all kinds of images now and see the issue with all of them (png, svg, jpg, even bitmaps)
looking at the code i suspect the scaling mechanism for the wallpaper, i'm trying out some patches that use a simpler approach for scaling and leave the actual scaling work to gdk

[Daniel Lee (longinus00)]

There's nothing wrong with the scaling. If you take the scaling code out the banding still remains. One of the drawing functions must have a problem with 16bpp mode.

[Oliver Grawert (ogra)]

right, even with different scaling code it didnt change ...

also commenting out all functions that use composite (to rule out that gdk is reporting composite support falsely for the window) didnt change a thing.

i tried changing the way the pixbuf for the window gets loaded with code i know working but no change.

i also tried forcing the default colormap of the screen, the system colormap as well as an rgb colormap onto the app window.

nothing of the above changed a thing and i'm, slowly running out of ideas.

[Hernando Torque (htorque)]

I'm still suspecting missing dithering to be the problem.

The function gdk_draw_pixbuf (http://library.gnome.org/devel/gdk/stable/gdk-Drawing-Primitives.html#gdk-draw-pixbuf) explicitly allows you to set a dither mode (http://library.gnome.org/devel/gdk/stable/gdk-GdkRGB.html#GdkRgbDither) but I'm not a GTK coder, so I can't test that...

[Oliver Grawert (ogra)]

using the attached testcode i see the same issue, so its this toplevel way of loading the pixbuf or using a gtkImage here which is at fault, i see nautilus doing pretty low level stuff in eel and gnome-settings-daemon using gnome functions to render the pixbuf (which presumably uses lower level gdk stuff in the backend)

as a workaround i now hacked up the framebuffer driver for the affected armel board to default to 32bpp (which is very ugly and wont help other users with 16bpp displays indeed, so the bug should still be fixed in xsplash by properly implementing a low level gdk pixbuf loader) i personally can live with xsplash as is for karmic due to this.

#include <gtk/gtk.h>
#include <gdk-pixbuf/gdk-pixbuf.h>

int main(int argc, char *argv[])
{
  GdkPixbuf *pixbuf;
  GtkWidget *window, *image;
  GError *error = NULL;

  gtk_init(&argc, &argv);
  window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
  pixbuf = gdk_pixbuf_new_from_file(argv[1], &error);
  image = gtk_image_new_from_pixbuf(pixbuf);
  gtk_container_add(GTK_CONTAINER(window), image);
  g_signal_connect(window, "destroy", G_CALLBACK(gtk_main_quit), NULL);
  gtk_widget_show_all(window);
  gtk_main();

  return 0;
}

[Daniel Lee (longinus00)]

I uploaded a branch that "fixes" the problem with the drawing in 16bpp displays. It only fixes the background as that's where the banding is more obvious. xsplash should still be shippable like this because the banding around the logo and throbber is very hard to notice unless you look really closely. A more complete overhaul of the drawing routine is recommended as it's stifling to the artists if they can only choose logos or throbbers with little color variation.

[Launchpad Janitor (janitor)]

This bug was fixed in the package xsplash - 0.8.3-0ubuntu1

---------------
xsplash (0.8.3-0ubuntu1) karmic; urgency=low

  * New upstream version (LP: #446658)
    - watch for monitors-changed signal (LP: #413348)
    - set a blank cursor on the cow foreign window (LP: #432179)
    - setgid fixes (LP: #439268)
    - 16bpp depth fixes (LP: #423632)
  * debian/patches/90_correctly-setuid.patch
    - Removed, merged upstream

 -- Ken VanDine <email address hidden> Fri, 09 Oct 2009 08:16:49 +0200

[Remco (remco47)]

I still have problems with 0.8.4-0ubuntu1. It's not as bad as in some of the screenshots, but still annoying. Is a small amount of banding to be expected still, after the fixes?

[Mat Tomaszewski (mat.t.)]

Please download the proposed fix for https://bugs.launchpad.net/ubuntu/+source/xsplash/+bug/441210 and report the results. The fix should minimise the banding issues at 16bpp.