Thanks! Will check this in detail later today, but I wanted to mention this: #754

We want to make alpha a separate graphic feature and thus an entirely independent Graphic property (in general we're trying to make the constructor as symmetric as possible with the settable properties, just like pygfx) . This would probably be a good time to do that?

We want to make alpha a separate graphic feature and thus an entirely independent Graphic property

Good to know this was already on the agenda! Yeah I think it makes sense both from an API perspective, but also technically; changing a color is fine, but changing an alpha value might affect how you want to blend things.

Then they can set it to 0.999 to fix it.

This seems a bit awkward. I foresee users would complain about having to do this.

• Or check the alpha values in images and colorlists, and automatically set the alpha_mode when values < 1 are present.

From your list of options, this seems most straight forward.

• Default to "dither", which always works. Then users can set alpha_mode="blend" for smoother results of transparent objects.

After thinking about this for a while, I guess what I would expect from a 2D plotting library as a user:

• All graphics have alpha_mode="blend"
• Graphics are drawn in the order that I add them to the figure, transparent or not, so the depth buffer is kind of ignored I guess

I'm not sure if fastplotlib also does 3D plotting, but in that case I would expect it to behave as pygfx does naturally.

By the way, I appreciate you calling for my thoughts, so I'm sharing them here, but I really have not been keeping up with fastplotlib's development for a while, so take it with a grain of salt.

• Or check the alpha values in images and colorlists, and automatically set the alpha_mode when values < 1 are present.

From your list of options, this seems most straight forward.

I'm leaning towards this as well.

After thinking about this for a while, I guess what I would expect from a 2D plotting library as a user:

• Graphics are drawn in the order that I add them to the figure, transparent or not, so the depth buffer is kind of ignored I guess

When using an orthographic projection graphics are stacked in z.

I'm not sure if fastplotlib also does 3D plotting, but in that case I would expect it to behave as pygfx does naturally.

Everything is 3D just like pygfx, perspective camera for everything. We just don't have a high level API for meshes yet, I've rarely used meshes myself so I hope someone else would be able to contributre a high level API for that. Or maybe meshes are so specific that the pygfx level of abstraction is the best for it, I don't know yet.

When using an orthographic projection graphics are stacked in z.

Do you mean that the objects are offset in their ob.local.z?

Is it possible to clearly identify whether the current graphic is in a 2D or 3D scene? If that is the case we could indeed default to blend.

Or maybe meshes are so specific

Haha!. Some Pygfx users consider meshes the "normal object" and think all the non-meshes are special 😉

When using an orthographic projection graphics are stacked in z.

And what determines the stacking order? Insertion order?

When using an orthographic projection graphics are stacked in z.

Do you mean that the objects are offset in their ob.local.z?

Yup!

When using an orthographic projection graphics are stacked in z.

And what determines the stacking order? Insertion order?

Yup. Though the z can be set when added, or later at any time.

Is it possible to clearly identify whether the current graphic is in a 2D or 3D scene? If that is the case we could indeed default to blend.

If camera.fov == 0

You can switch between them and it's something I do all the time when looking at low dimensional projections with lines and scatters.

Tests pass again! (or am I missing something?)

oh lol, all tests are skipped 😆

📚 Docs preview built and uploaded! https://www.fastplotlib.org/ver/alpha

How are you feeling about this refactor @almarklein, now that you can experience the revamped transparency system as a user?

How are you feeling about this refactor @almarklein, now that you can experience the revamped transparency system as a user?

I'm feeling pretty good about it in general.

I felt rather disappointed that we cannot abstract the whole transparency thing away from the user. But after having done quite a bit of research on the topic I'm confident that even with the more advanced methods (which would consume more memory and/or be slower) it'd still not be fool proof. That's what it is.

So the only way to go is to shove the problem on the user 😄 , but as gentle as possible, and providing multiple different options to deal with it. I think we've now now done that pretty well, providing pretty powerful options, but also easy-to-use shorthands with alpha_mode.

As for this PR in Fastplotlib, I think it helps a lot if we can determine/assume the scene to be 2D, so we can just use 'blend'. If no object writes depth, Pygfx will not create the depth buffer, so it'd be a bit lighter too.

if we can determine/assume the scene to be 2D, so we can just use 'blend'. If no object writes depth, Pygfx will not create the depth buffer, so it'd be a bit lighter too

3D is used often, easiest way to check is if camera.fov > 0

This will also need some refactoring of the graphic features, will add more thoughts soon

You may want to consider introducing an Enum or a dict with a list of custom render queues, just so they're easier to organize and manage.

Ok, the approach I implemented now:

• Background and overlays use alpha_mode=='blend'; we don't really need the depth buffer there.
• Same for annotations like the selector tools, but these are rendered in the same scene so I used render_queue=3500 so they always render later, and they don't use the depth buffer (no write and no test).
• For these underlays and overlays I used 'ob.render_order` to define the order of rendering within that group, instead of using z.
• Axes are solid, except for the text labels, for which we want aa.
• Lines and Points have alpha_mode='auto' by default, but user can change with an arg. The aa is turned on if the alpha mode is 'blend'.

The screenshot tests fail. obviously. What's the best way to update these? Same as in Pygfx?

This will also need some refactoring of the graphic features, will add more thoughts soon.

What kind of changes?