it seems some image comparisons tests fail. this is most likely because before it was 'inout' displayed even though default is 'out'? That would be my guess.

I looked at the failing tests - and it seems all of them are the "out" default, which was before "inout" as it was done incorrectly. So the fix seems to be correct.

Thanks, making this configurable is good. I think the previous state was just hard-coded to an 'in-out' solution and ignoring the tick params settings.

There's a bit of trouble with the defaults: On 2D we have classes XTick and YTick, which take their defaults from rcParams['xtick.direction'] and rcParams['ytick.direction'].
On 3D all directions populate their axis with XTick and take their value from rcParams['xtick.direction']. Note that we neither have a ZTick class nor rcParams['ztick.*'].
Also note that this inconsistency has existed for other tick defaults rcParams['xticks.*'] (e.g. xticks.color) as well. So this is not new, it just becomes additionally visible in the tick direction now that it is not hard-coded anymore but follows rcParams['xticks.direction'].

There are several ways one could go forward, however I think the following is the best for now:
Patch the 3D ticks to default to a hard-coded internal 'inout', but let it be overwritten by tick_params(direction=...).

Advantages:

• We do not modify existing plots/defaults
• Users can now change the direction via tick_params(direction=...).
• We don't have to get into the business of untangling the rcParams mess for 3d ticks right now.
• This is still open for future changes. Any additional change we could make here now can be added later with the same amount of user impact.

Disadvantages:

• The tick direction is still not configurable via rcParams.

I have not looked into the details how the 3D tick default direction could be patched, but assume that it can be done by a few lines of code.
This is a bit hacky, but every other solution will require either significant rewrites for 3D tick handling, or changed default behavior or have inconsistencies in rcParams usage; likely two or all three of them.

@timhoffm, so you want me to add code, which will be removed anyway just to postpone fixing the tests? I can't say I see any advantages in that, just disadvantages.

The suggestions is not motivated by the tests. This is about user-facing behavior and API.

Before the tick direction was hard-coded. If we now do nothing special, the default tick direction would be determined by rcParams['xticks.direction'] for all axes.

1. This would change the default behavior from 'out' to 'inout'. We are very hesitant with such changes because it changes the appearance of user figures. Even if that's acceptable, we have an additional complication:
2. The ticks directions for all 3D axes are taken from 'xticks.direction' (because for some reason they are all XTick instances). In contrast, for 2D we use 'xticks.direction' and 'yticks.direction'.
   There are again two possible ways out:
   3a) Create a new 3dticks.direction rcParam (naming t.b.d.) - Possibly, what's a good default for 2D is not necessarily a good default for 3D.
   3b) Change the 3D ticks to XTicks, YTicks and create a new ZTicks class and add 'zticks.*' rcParams.
   Both 3a) and 3b) would require quite a bit internal refactoring.

In summary, as soon as we start using rcParams for 3D, we are getting undesired API/behavior in the intermediate solutions. Only if we fully implement 3a or 3b, we get back to a reasonable API. But that's requires quite a bit internal restructuring, and we would need to decide whether 3a or 3b is the desired solution. IHMO this is beyond the scope of this PR and could significantly delay the adoption of this PR.

Thank you for explanations Tim. Yes, indeed it seems there is much more work on this. I just wanted to add ability to do the ticks 'in' as sometimes they went out and got too close to text and it made it look a bit weird - not acceptable for publication. By adding ability setting ticks 'in', it would resolve a lot of headaches in the future.

I may be late on the ball here and not following all the discussions properly, but wouldn't it make sense to not change the test images, but to use the same styles for them? And then add one image, like the one in the opening post of this PR to prove the functionality?

This is from the aspect of saving repository space by not updating test images unless absolutely necessary.

(Being able to configure it is 👍🏻 )

Well, quite frankly I am bit lost here.

I may be late on the ball here and not following all the discussions properly, but wouldn't it make sense to not change the test images, but to use the same styles for them? And then add one image, like the one in the opening post of this PR to prove the functionality?

This is from the aspect of saving repository space by not updating test images unless absolutely necessary.

(Being able to configure it is 👍🏻 )

@oscargus: Yes.

@Pepe78: Have we scared you away? If so, sorry for that. The large user base and legacy code makes it sometimes hard to introduce changes or even only fixes. But your PR is a good addition and there's not much lacking for it to be merged.

Hah. No. I just realized that it takes shorter time to write my own libraries than checking in three and half lines of code fix into matplotlib:
https://github.com/pepe78/subdivision_opencl
(to be specific: https://github.com/pepe78/subdivision_opencl/blob/main/display.py)

as i am currently considering switching languages anyway:
https://github.com/pepe78/python-performance

I guess i will be most likely using other library in future for displaying graphs anyway (maybe rust?).

Sorry that I wasn't more helpful. You guys can take the code and check it in if you know how to do it properly. I obviously didn't.

Thanks :) - as I said - I wished I was more helpful. I understand that matplotlib is going through a lot of changes (I actually looked at a lot of code) and I saw you guys are trying to figure the best ways (which is often hard on a moving train). I just felt I am going to slow you down :). And yes, matplotlib can be used with other languages as well. Happy plotting (I will still be using matplotlib a lot in future).

Will try to pick this up after #22587 is in.

Just FYI - matplotlib's 3D graphs got into my latest publications:
https://www.sciencedirect.com/science/article/pii/S0167691122000329

So Thank you for all the hard work to make them look pretty!