[subsurface] Prettier profile colors (#89)

Linus Torvalds torvalds at linux-foundation.org
Mon Nov 28 12:01:22 PST 2011


On Mon, Nov 28, 2011 at 5:00 AM, henrik242
<reply+i-2367030-22df6d3716b3a7f680fb3a594ca46d284a94afd4-1024025 at reply.github.com>
wrote:
> The profile colors aren't very pretty, and the grid lines are too thick.
> This commit tries to improve that.

[ For others.. the pull request is at

   git://github.com/henrik242/subsurface profile-colors

  so you can look at it ]

So looking at before-and-after side-by-side, I do think this may be an
improvement, but I have a few objections, some of which are big enough
that I won't be pulling this as-is.

First off, the new background color is some kind of very light beige,
which is neutral and fairly pleasing, but the new thin white gridlines
are really hard to see. I bet it depends on just how contrasty the
monitor settings are, but and for me it's kind of borderline usable,
but it's borderline enough that I worry. The yellow warning markers
are also much less visible.

I like the new water fill colorization, though.

The depth printout changes are horrible, though, and totally unusable.
We used to have nice readable "black-on-white" depth markers, they
have now turned into these monstrous bold-black text on top of gray.
That's not just ugly, it's also totally unreadable on lots of
real-life printers that do gray with various dithering schemes (think
traditional laser printer), so now that text is just an unreadable
blob when actually printed out.

Finally, in the code itself, I kind of like having things in one
place, but quite frankly, that one table is broken. It turns the
random "color indexes" into random RGB values, which makes it not very
readable at all.

I'd suggest having a mapping of "color names to RGB" (which may be
just a list of #define's), and then having a mapping from color index
to color name instead. That way the global color index array would be
a lot more readable.

I would also suggest that perhaps the color index array would map to
*two* colors: the screen color and the printer color. That way we
could automatically have some nice way of showing "don't print this"
(by just making the printer color some invalid color), but it would
also avoid the issue with random mappings of colors for printing. Now
you hack around it with nasty "DEPTH_FILL_PRINTER" things.

Finally: maybe you should make the "rgb_t" a "rgba_t". Now you have
that odd "we have indexes to the color table, and then we have a
separate alpha channel value". But who knows. I don't have a very
strong opinion on this part.

                            Linus


More information about the subsurface mailing list