While this maybe works (I didn't check), this will likely not fix the same issue with e.g. marker capstyles and joinstyles. A more general fix seems appropriate.

As a possible more general fix, I was thinking of preserving additional marker state when creating the new MarkerStyle, for example by also copying attributes like _transform (and any other other relevant marker state ) from the original marker.

Would this be a reasonable direction, or would you recommend a different approach here ?

I think everything not explicitly changed should be copied.

I experimented with copying additional marker state when recreating the MarkerStyle. However, some internal attributes (for example _snap ) are not present on MarkerStyle objects and caused errors. Also , when I tried cloning the marker more broadly, the reproduction case from the issue started producing a fully filled marker instead of the expected half-filled one.

Current implementation recreates the MarkerStyle with the new fillstyle while preserving the existing _user_transform, which fixes the rotation issue in the reproduction example.

Would like to know if there is a specific marker state that should also be preserved.

AFAICS, Markers are immutable. Similar to cmap.with_extremes() should we define a factory method that creates a new marker with changes attributes, e.g. new_marker = marker.with_attrs(fillstyle="right")? IMHO putting this functionality into the Marker class makes sense.

I see your point about keeping markers immutable and creating a new marker with modified attributes (similar to cmap.with_extremes). That approach makes sense from an API design perspective.
For this PR, would you prefer keeping the fix minimal (preserving the relevant marker state when recreating MarkerStyle) , or should I explore introducing something like a with_attrs() helper in MarkerStyle?

Happy to adjust the approach based on your preference.

I will unilaterally claim that this discussion is not taking place between the reviewers and the PR author, but between the reviewers and a LLM. We don't need to spend time on talking to a LLM via the Github interface -- we could just do that directly ourselves. Closing accordingly.
Feel free to appeal if my interpretation is wrong.

Hii @anntzer, I'm sorry if my previous comment came across the wrong way. That wasn't my intention.

I did reproduce the issue and worked on the patch locally while looking into the MarkerStyle behavior. I was trying to discuss the direction I was thinking about for the fix.
If I misunderstood something in the design or the expected approach, I'd be glad to learn and adjust.

@jayaprajapatii sorry in case we wrongly assumed this was AI generated. We get a lot of AI spam nowadays and it's sometimes difficult to distinguish between genuine work and blind AI usage. Please make sure to follow our AI policy.

I would re-open, but the solution should towards the factory method approach, and there the code here does not help. More precisely, let's go with creating a MarkerStyle._with_attrs(). Keep it private for a start, so we don't have to care about naming too much. You are welcome to create a PR for that.

@timhoffm Thankyou, for the clarification and for pointing me to the factory method approach.

I'll look into implementing this using a MarkerStyle._with_attrs() helper as suggested and will open a new PR once I have a working version.

Hello @timhoffm ,
I tried experimenting with the factory-method approach by updating MarkerStyle._with_attrs so that the marker transform is preserved when changing the fillstyle. This resolves the rotation issue.

However, when the marker is rebuilt this way, the half-filled star becomes fully filled. It looks like the _alt_path used for half filled markers is not preserved. For reference, the localized fix in Line2D.set_fillstyle (recreating the marker while copying _user_transform) keeps both rotation and half-fill correct, but I understand that the prefered direction is to avoid that approach.
Could you please suggest how the half-filled behavior should be preserved when updating the fillstyle using factory method approach.

It's showing like this..

@jayaprajapatii The problem is well scoped. It must be possible to solve this only based on the internals of MarkerStyle. Finding out how the implementation has to look like is part of the task.
If I could right now tell you exactly what to do, I could as well quickly implement it myself.

Superseeded by #31301.