GNOME Bugzilla – Bug 631698
Rhythmbox stars (ratings) not updated properly when scrolling up in the playlist
Last modified: 2010-10-14 14:29:21 UTC
Hi ! This bug appeared in RB 0.13.x (Maverick Meerkat or Lucid + PPA). When displaying a "ratings" column in the playlist and scrolling up in a playlist (not down) the stars are not displayed properly as you can see in the provided screenshot. (either invisible or partly drawn) How to reproduce ? 1) in the options, tick the "ratings" column 2) in a playlist (big enough so that you can scroll into it) rate a few tracks, rather at the top of the playlist 3) scroll from the bottom to the point where the rated tracks are, preferably with the elevator (because when the mouse is hovering over the playlist lines, it forces a redraw of those lines) 4) notice that the stars are incorrectly / not drawn Cheers ! (launchpad bug ID : https://bugs.launchpad.net/ubuntu/+source/rhythmbox/+bug/649738)
This broke in the gdk_draw_pixbuf->cairo change. Reverting commit 1bddf3b fixes it. Benjamin, any ideas on what I've screwed up here? The cell renderer code is here: http://git.gnome.org/browse/rhythmbox/tree/widgets/rb-cell-renderer-rating.c and the code that actually renders the stars is here: http://git.gnome.org/browse/rhythmbox/tree/widgets/rb-rating-helper.c#n161 Some simple experiments show that when cell_area->y is negative, pixbuf drawing fails, but drawing a solid color (cairo_set_source_rgb) works properly. Seems weird that it'd ever be negative, but I don't see why it wouldn't work.
That took me a bit to find. It didn't help that the code does a lot of mumbo-jumbo that's not really useful to do (like the rectangle intersecting magic) and could be simplified quite a bit. Anyway, the problem is that x_offset and y_offset are unsigned long. So if cell_area.x is -5, it'll be passed as 18446744073709551610. gdk_draw_pixbuf() used to cast it back to an int, so it became -5 again, but Cairo uses doubles... So I guess the fix is to make rb_rating_render_stars() take signed arguments.
That's kind of face slappingly obvious now that you point it out. Thanks. I think that code was originally based on gtk-cell-renderer-pixbuf.c many years ago, so maybe I should rebase it on a current version.
fixed in commit 46550f4
Thanks for fixing it folks !