Comment 16 for bug 423632

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;
}