Can we please refrain from attacking wined3d?
There's a difference between attacking vs giving an accurate analysis and assessment based on my own account and research to better understand if my account is indeed most accurate.
I cannot express how much the worst part of my job is listening to people comparing our project to DXVK, calling it pointless, accusing us of NIH (a hilarious accusation against a project that existed over a decade earlier),
I am fully aware of the wined3d's sentiments towards DXVK but comparisons are inevitable when decisions are made to deliberately impair users freedom to run their apps how they want. Seeing "dead end" used again to describe my bug fix felt very appropriate to bring up DXVK as another "dead end" for comparison since construction plans to close that road are still delayed indefinitely which may equally apply to my bug fix. I preferred to contribute to wined3d not DXVK. Failing for `D3D11_CREATE_DEVICE_VIDEO_SUPPORT` was not a hack. It was a bug fix until properly supported. And once properly supported it is a feature that promotes users freedom who may not care whether someone refers to it as a workaround and just want the freedom to use it especially when it breaks nothing else for wine.
and generally making this my least favourite part of Wine to work on.
Likewise. My intent was course correction not further disruption. Prioritizing user freedom even over design docs may lead out of further degradation and lack of enthusiasm.
Having that happen in the Wine patch tracker of all places makes this even worse.
Patch tracker is appropriate to raise concerns and comparisons as someone who has spent considerable spare time working on wined3d to acquire an accurate and valid critique and not some of random misinformed troll on reddit from 7 years.
"hack around it now, fix it later maybe" style of development is better than our "get the design right first"
Perhaps DXVK "hacks around" instead of "design right" but I have not looked closely enough to say either way. However failing for `D3D11_CREATE_DEVICE_VIDEO_SUPPORT` was not a hack and simply a bug fix and also a feature that respects users freedom.
I don't think you can understand how important code quality is until you've had to maintain a code base like this for multiple years.
I don't think you understand anything about my background to make a judgement call about my lack of understanding about code quality. My patch did not degrade code quality and was inline with it. It simply added an option to promote users freedom and fix a bug.
The one thing I've always loved about wined3d is the code itself; it's been the easiest thing to read and understand in the entire code base, whereas DXVK apparently managed to become unmaintainable after just over two years of development, so maybe not a unilateral win there.
I have spent little time with DXVK code base but much with wined3d which has felt much less maintainable compared to the few other wine modules I've worked. My assessment is simply about effectiveness to address bugs without compromising users freedom unnecessarily.
(Frankly, I'd also attribute some of the difference to the sudden and tragic loss of one of our most valuable and prolific contributors, as well as CodeWeavers investing in direct Metal-based solutions, the lead maintainer of wined3d burning out, and the current maintainer fighting both health problems and burnout, to the point that I'm still here mostly because someone has to be. But yes, DXVK has its advantages.)
If my experience with wined3d recently is not how it operated in the past of some far better era then it is indeed very tragic and whoever may have been lost who steered the ship in a better direction is dearly missed and their quality and loss is felt among those who have never met them.
Anyway, I understand that you find it tedious and unnecessary, and lack the time, to work on solutions that fit within our planned design,
Design plan was absent but would have avoided tedious unnecessary work I put in to relate 8 years of bugs and finally mark them duplicates and explain to users the problem with clarity and fix their bugs while promoting their freedom which did not conflict with a design plan.
so I've taken what spare time I can muster to implement shared resources properly.
Your spare time seems much more valued more than mine. If I'd submitted identical work it may have been delayed indefinitely. There's an uneven burden of trust and proof that discourages contributors from wasting more of their time when not even their most trivial harmless patches are merged.
That's time I was hoping to spend on getting Damavand to parity sooner, but it's clear this is a higher priority.
My understanding is that shared resources solution only supports to Damavand so it seems to have contributed to higher parity regardless. Based on the number of on-going collected of unmarked duplicates over 8 years, these bugs should have been considered higher priority long before now and should not have required me to raise the priority per missing planned design in any comments. This merge and MR-11398 fix both Damavand and gl. Therefore if your latest Damavand shared resources solution fixes videos alternatively then it is still hidden from users without requiring them to use a special flag like `renderer=vulkan` which is functionality equivalent of `no_create_flags=0x800` Regardless of shared resources, users should still have the freedom to play games using whatever methods UnityPlayer offers. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11612#note_149343