xsplash wallpaper gradients are massively distorted at 16bpp depth

Bug #423632 reported by Oliver Grawert on 2009-09-03
32
This bug affects 10 people
Affects Status Importance Assigned to Milestone
xsplash
Medium
Cody Russell
xsplash (Ubuntu)
Medium
Cody Russell

Bug Description

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

Changed in xsplash (Ubuntu):
status: New → Confirmed
Oliver Grawert (ogra) wrote :

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) wrote :
Oliver Grawert (ogra) wrote :

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

Changed in xsplash (Ubuntu):
importance: Undecided → Medium
milestone: none → ubuntu-9.10
David Barth (dbarth) on 2009-09-24
Changed in xsplash:
importance: Undecided → Medium
assignee: nobody → Cody Russell (bratsche)
milestone: none → ubuntu-9.10-beta-freeze
Mat Tomaszewski (mat.t.) wrote :

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) wrote :

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.

Hernando Torque (htorque) wrote :
David Barth (dbarth) on 2009-09-25
Changed in xsplash:
milestone: ubuntu-9.10-beta-freeze → ubuntu-9.10
Changed in xsplash (Ubuntu):
assignee: nobody → Cody Russell (bratsche)
Changed in xsplash:
status: New → Triaged

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.

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) wrote :

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.) wrote :

Would converting the image to svg solve the problem?

Hernando Torque (htorque) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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.

Ara Pulido (apulido) on 2009-10-02
Changed in xsplash (Ubuntu):
status: Confirmed → Triaged
Cody Russell (bratsche) on 2009-10-02
Changed in xsplash:
status: Triaged → Fix Committed
Cody Russell (bratsche) on 2009-10-02
Changed in xsplash (Ubuntu):
status: Triaged → Fix Committed
Launchpad Janitor (janitor) wrote :

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

Changed in xsplash (Ubuntu):
status: Fix Committed → Fix Released
Cody Russell (bratsche) on 2009-10-09
Changed in xsplash:
status: Fix Committed → Fix Released
Remco (remco47) wrote :

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.) wrote :

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.

tags: added: iso-testing
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers