Repository: vispy/vispy

Issue:
Add transparent color to internal color dictionary
Hi, 

I've been working extending and improving `napari`'s color support (mostly [here](https://github.com/napari/napari/pull/782)) and we'd be very happy to have a "transparent" color in your internal `color_dict`, which simply corresponds to `#00000000`. This modification is very minimal (I'd be happy to do it myself) and can provide us with the bare-bones support we'd like to see.

Is that possible?
Thanks.

_Originally posted by @HagaiHargil in https://github.com/vispy/vispy/issues/1345#issuecomment-566884858_


Discussion:
@hagaihargil I'm not super familiar with the internals of napari, but why is this needed?

I am not against a "transparent" color being added in principal. It looks like the colors in https://github.com/vispy/vispy/blob/master/vispy/color/_color_dict.py are mostly CSS colors. Any idea if CSS has an idea of a transparent color name? I don't see it in the json file our list was originally created from.
https://stackoverflow.com/a/26538388/433202

Looks like `transparent` can be used in CSS.
Hi, I didn't see it as well in existing online lists. The idea behind it is pretty straight-forward - a user can choose to display a group of points in napari's viewer, for example. The user can then choose individual points and change their features - color, size, etc. It could be nice to allow our users to make a point's face color transparent, while keeping it's edge color colored, to help with viewing data located "underneath" that point.
Ok, that's fine, but why does the name have to exist in vispy for this to work? Couldn't napari send an RGBA color tuple or even a full ColorArray object with whatever colors it wants? I can see how letting vispy handle this would be easier, just curious.
We're currently completely reliant on your color pallette when interpreting named colors. This means that if a user gives napari a list or a `ColorArray` of colors, napari hands the parsing of these color arrays straight to vispy. This is done so that the list of colors will be traversed only once - by vispy. If we were to add our own "transparent" keyword, then when a color list is passed we'd need to:
1. Iterate over the list and check whether there are any "transparent" colors in it.
2. Change these colors into their hex repr.
3. Pass the modified list back to vispy for actual parsing and rendering.
This iteration is done in pure Python, and color lists can contain tens of thousands of elements, so performance might be an issue. Vispy already traverses this list at least twice in pure Python, and possibly a few times more (the `any` call, recursion).

It's obviously possible, and we might decide to follow that pipeline I just described in the mean time, but it definitely seems much cleaner and clearer to add a single "transparent" key to vispy's color dictionary from our perspective.

I hope things are a bit clearer.
Makes sense. I guess I didn't realize people would be providing a list of names of colors for a color map in napari.

Anyway, feel free to make the PR.

Resolving patch:
diff --git a/vispy/color/_color_dict.py b/vispy/color/_color_dict.py
--- a/vispy/color/_color_dict.py
+++ b/vispy/color/_color_dict.py
@@ -190,4 +190,5 @@ def get_color_dict():
     "tomato": "#ff6347",
     "white": "#ffffff",
     "yellow": "#ffff00",
+    "transparent": "#00000000",
 }


Test patch: