Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.


#14 Enhancement for color slider arrows

Jon A. Cruz

The marker arrows in the color sliders are usually a
single color and are easy to lose track of when moving
into a range of the slider that has a similar color.

By switching from a GTK+ arrow, who's look is
determined by the GTK+ theme in action at the moment,
to custom drawn arrows, it's better to match the custom
drawn slider trough.

This patch as-is gives two small black arrows with
white borders. That's the most common solition for
things such as subtitles, karaoke, and general video
work. It also saves work not having to determine the
relative value of the part of the slider image that
it's over at the moment.

This code is easy to tweak to get a solid white and
solid black triangle (as The Gimp does), but then some
find that to be hard to 'track' as the arrow moves from
light to dark areas in a slider.

I believe that this addresses half of bug #830500


  • Jon A. Cruz
    Jon A. Cruz

    Color slider arrow update

  • Logged In: YES

    I think this patch is correct. Gtk styled arrows are often
    not very well suited for precision control :-)
    On the other hand - if drawing arrows by hand, maybe drop
    Gdk completely, and compose arrow into RGB buffer, before
    it will be drawn onto widget. Thus we will save few X
    calls, and get cleaner code IMHO?

  • Jon A. Cruz
    Jon A. Cruz

    Logged In: YES

    Good points.

    I think, though, that it doesn't give cleaner code. That was
    one consideration. At the moment (with the patch as-is)
    either sp_color_slider_render_map or
    sp_color_slider_render_gradient get called to render either
    a map or a gradient. Keeping these to just doing one thing
    (rendering a map or gradiet) and not combining UI control
    widgets seems to be a cleaner way. Then only the place in
    sp_color_slider_paint that actually draws the arrows and the
    place in sp_color_slider_adjustment_value_changed that
    queues the arrow area need to know about them.

    Of course, that has to be ballanced with pragmatic concerns.
    What would saving a few X calls gain us? On a 500MHz PIII,
    all those gdk line calls for both arrows total to about 28
    microseconds (that's 0.028 milliseconds). Additionally, the
    arrows are updated in response to user action so I tested
    maxing out user interaction. Dragging things as fast as I
    could, and with all sliders updating in response, I was
    unable to get my total CPU usage to go over 60% (with no
    difference seen with arrow drawing commented out). Given
    that, it appears to be safe from a performance standpoint to
    keep the buffer generation and the arrow drawing separate.