2012 Wine bug "Drawing in Photoshop CS5 is almost impossible" now fixed(bugs.winehq.org)
bugs.winehq.org
2012 Wine bug "Drawing in Photoshop CS5 is almost impossible" now fixed
https://bugs.winehq.org/show_bug.cgi?id=29871
83 comments
Maya definitely works, but I've always needed to create symbolic links and other tweaks for it to work on non-fedora distrust. Can also confirm that Nuke works great on Linux, if you can afford the price tag.
Consider this an "outside opinion" from an external developer, but my first impression upon reading the thread is that I think the whole design of "key state caching" is wrong and a symptom of a bigger problem.
Apps are polling GetAsyncKeyState() for good reason --- because they want that low-latency responsiveness which is important in situations like drawing with the mouse. Adding a cache defeats that, hence leading to bugs like this one. If your API implementation is slow, then profile and figure out how to make it faster because it obviously works fine in Windows.
As the saying goes, "Never add another layer of complexity when your problem can be solved by removing and/or optimising the existing ones."
Apps are polling GetAsyncKeyState() for good reason --- because they want that low-latency responsiveness which is important in situations like drawing with the mouse. Adding a cache defeats that, hence leading to bugs like this one. If your API implementation is slow, then profile and figure out how to make it faster because it obviously works fine in Windows.
As the saying goes, "Never add another layer of complexity when your problem can be solved by removing and/or optimising the existing ones."
The architecture is inherently different: it works fine in Windows because there's only one canonical key state and the operating system is looking after it.
Wine, on the other hand, is running within X Windows, and the canonical key state belongs to X. It's in a different process and it might even be on a different computer. So either they have to poll it (slowly), arrange for asynchronous notifications (may not be possible and undoubtedly has similar conflicts with synchronous access), or poll it a limited amount and then cache it.
The whole point of Wine is adapting one API to a fundamentally different one. It is the added layer of complexity.
Edit: another discussion suggests the X by design does not allow an application to see keystrokes aimed at another window, nor is there a global hook mechanism.
https://bugs.winehq.org/show_bug.cgi?id=5623
Wine, on the other hand, is running within X Windows, and the canonical key state belongs to X. It's in a different process and it might even be on a different computer. So either they have to poll it (slowly), arrange for asynchronous notifications (may not be possible and undoubtedly has similar conflicts with synchronous access), or poll it a limited amount and then cache it.
The whole point of Wine is adapting one API to a fundamentally different one. It is the added layer of complexity.
Edit: another discussion suggests the X by design does not allow an application to see keystrokes aimed at another window, nor is there a global hook mechanism.
https://bugs.winehq.org/show_bug.cgi?id=5623
"they want that low-latency responsiveness which is important in situations like drawing with the mouse"
Yes to this in general, not just with mouse polling- I've noticed a disturbing trend towards more and more buffering, caching, and latency in a lot of modern software and hardware. In my humble opinion, if your API/interface can't match the response time of the human nervous system, then it's just flat out broken. Nerves fire at 100 hz, for pete's sake. Transistors operate on a gigahertz level. Let's get our sh together, people.
Yes to this in general, not just with mouse polling- I've noticed a disturbing trend towards more and more buffering, caching, and latency in a lot of modern software and hardware. In my humble opinion, if your API/interface can't match the response time of the human nervous system, then it's just flat out broken. Nerves fire at 100 hz, for pete's sake. Transistors operate on a gigahertz level. Let's get our sh together, people.
Post like that brings me back to earth every time I dream of running Linux only. I commend the work of everyone involved, people working for free on their spare time for the common benefit is great. But celebrating CS5 compatibility in late 2017… it's sobering.
To be fair, this is not for CS5 compatibility specifically (that was one of the more visible impacted apps), but multi-threaded applications that continuously poll for mouse state against a non-thread safe state-cache introduced in an earlier version.
Also wine is not linux, and photoshop is not a linux program. If you want to run Linux only, then alternatives like krita, gimp etc.. exist that work natively. While I admit they often don't line up with adobe's tools yet, Krita's come a long way from what I've been told, and for a good portion of basic photoshop tasks (rgb only for the most part) you can use gimp quite effectively.
As a non-graphic designer I use linux daily and love it. I only keep windows around for the few windows-only games I still play
Also wine is not linux, and photoshop is not a linux program. If you want to run Linux only, then alternatives like krita, gimp etc.. exist that work natively. While I admit they often don't line up with adobe's tools yet, Krita's come a long way from what I've been told, and for a good portion of basic photoshop tasks (rgb only for the most part) you can use gimp quite effectively.
As a non-graphic designer I use linux daily and love it. I only keep windows around for the few windows-only games I still play
Unfortunatly, there are no serious Photoshop alternatives. On any platform. It's very sad, but true.
> alternatives
Don't know about Krita, but Gimp still (?) has no good CMYK support, so buh bai printing industry. Not an alternative.
Don't know about Krita, but Gimp still (?) has no good CMYK support, so buh bai printing industry. Not an alternative.
Krita + Gimp can cover nearly all use cases from my understanding. Yes, as I mentioned GIMP doesn't really have CMYK support so that's limited to RGB editing (web, digital etc..), however Krita has it and has come a long ways.
So I'll double down on my statement that a good 20-30% of photoshop use cases can be covered by GIMP, with the exception of non-RBG requirements like printing that could possibly move to Krita or other tools.
So I'll double down on my statement that a good 20-30% of photoshop use cases can be covered by GIMP, with the exception of non-RBG requirements like printing that could possibly move to Krita or other tools.
That is incorrect, it exists since 2011.
https://en.wikipedia.org/wiki/GEGL#babl http://www.gegl.org/babl/
https://en.wikipedia.org/wiki/GEGL#babl http://www.gegl.org/babl/
> Post like that brings me back to earth every time I dream of running Linux only.
It's not a Linux problem, it's a Windows emulation problem in Wine.
As for Linux, I'm using it for 25+ years, and I ditched Windows 10+ years ago. Windows is not necessary to do stuff. However, if you vitally depend on CS5 then running CS5 in emulation is not the best idea. At least you can use it properly in a PC emulator like VMware in Linux.
It's not a Linux problem, it's a Windows emulation problem in Wine.
As for Linux, I'm using it for 25+ years, and I ditched Windows 10+ years ago. Windows is not necessary to do stuff. However, if you vitally depend on CS5 then running CS5 in emulation is not the best idea. At least you can use it properly in a PC emulator like VMware in Linux.
> It's not a Linux problem, it's a Windows emulation problem in Wine.
If you need to run Photoshop, it is a Linux (as a plataform), problem. Also “Wine Is Not an Emulator”.
If you need to run Photoshop, it is a Linux (as a plataform), problem. Also “Wine Is Not an Emulator”.
been using it for 22 years and ditched Windows some 15 years ago at home. Unfortunately, I use my work PC a lot and that's Windows...
now, I do mostly web and dev, so Linux is a sweet spot there...
now, I do mostly web and dev, so Linux is a sweet spot there...
Emulation is still a very hard problem in computer science. We may never get a proper xbox emulator. And more obscure consoles are doomed to be forgotten. Emulating Windows is a bit easier because it's on the same hardware, but it's still never going to be perfect.
That said, so what? It's cool that you can use Windows software on Linux. But even without that it's still a perfectly usable OS.
That said, so what? It's cool that you can use Windows software on Linux. But even without that it's still a perfectly usable OS.
> And more obscure consoles are doomed to be forgotten.
That’s why projects like MAME are very important.
That’s why projects like MAME are very important.
Yes, it took them literally years to fix it and it wasn't a particularly difficult fix. That's why companies prefer paid software - if something doesn't work, they can complain to the company and the company is obliged to fix it... as opposed to waiting years for the right volunteer developer to prioritize one of many issues.
This really does go to show that cache invalidation is a Hard Problem. And that GetAsyncKeyState() is a bit of a pain even for Windows developers.
>drawing in photoshop cs5 is almost impossible
usable?
usable?
martin_andrino(12)
Too bad I don't have the time to read the long comment thread on there right now. Hopefully I will remember to do so after work. :)
Instances like this are really interesting to me, as it seems early on in the thread the commit the broke Photoshop was identified, yet it took them 5 years to finally commit a fix. From the outside it's easy to say the wine devs are lazy/stupid for not having fixed it right away, but I suspect there is a story buried in there that tells why it wasn't that simple.
I skimmed it and saw at least two attempts that were backed out for various reasons.
From a rudimentary reading.
They introduced a state cache to fix conditions where applications poll continuously for certain states (mouse button press for example). This wasn't thread safe however, and multi-threaded applications could get a previous/incorrect state back from the cache and stop functioning as intended. This was highly visible for photoshop tools where you click and hold, as the separate mouse poller thread would get a state of 'button not clicked" and stop, or in some cases start/stop repeatedly giving a series of dots instead of a line.
The patches submitted early were to disable the global cache, which while it fixed the multi-threaded use cases didn't fix the high-polling rate issue that the global cache was attempting to fix.
The fix, years later, was to look at the global cache when changing state and invalidate it at the time of state change so any immediate calls to retrieve that state from the cache will not get the previous cached state.
There was also another issue that came up in the middle of that thread that was unrelated it seems.
They introduced a state cache to fix conditions where applications poll continuously for certain states (mouse button press for example). This wasn't thread safe however, and multi-threaded applications could get a previous/incorrect state back from the cache and stop functioning as intended. This was highly visible for photoshop tools where you click and hold, as the separate mouse poller thread would get a state of 'button not clicked" and stop, or in some cases start/stop repeatedly giving a series of dots instead of a line.
The patches submitted early were to disable the global cache, which while it fixed the multi-threaded use cases didn't fix the high-polling rate issue that the global cache was attempting to fix.
The fix, years later, was to look at the global cache when changing state and invalidate it at the time of state change so any immediate calls to retrieve that state from the cache will not get the previous cached state.
There was also another issue that came up in the middle of that thread that was unrelated it seems.
> Regressions tend to be high priority for the devs though so this will be fixed eventually.
"eventually" is right...
This seems to be a failure on the part of the devs to prioritize. AFAIK code that causes a regression should be reverted and fixed properly, not left affecting the product for FIVE YEARS before finding a fix. The burden can not be on every use case to work around a bug that was introduced, the core "fix" is clearly a half-fix and should have been reverted on identification.
"eventually" is right...
This seems to be a failure on the part of the devs to prioritize. AFAIK code that causes a regression should be reverted and fixed properly, not left affecting the product for FIVE YEARS before finding a fix. The burden can not be on every use case to work around a bug that was introduced, the core "fix" is clearly a half-fix and should have been reverted on identification.
I mostly agree, but if we want to be pedantic, this didn't regress something so much as fix horrible performance for 90% of apps and introduced a previous non-existent bug into certain applications due to a non-thread safe bug.
The solution itself turned out to be simple enough, and the time it took to fix is definitely not excusable considering the effort vs impact IMO.
The solution itself turned out to be simple enough, and the time it took to fix is definitely not excusable considering the effort vs impact IMO.
If you're interested in doing digital art on linux - I highly recommend checking out Krita. I've discovered it a year ago and was blown away, if you're an artist - it does everything you may need, and works extremely well.
----
Slightly off topic - I'm also quite happy with using linux for the rest of my digital art needs:
- Kdenlive is an excellent video editor. Works extremely well, and is pure joy to use.
- Nuke and Houdini have native linux versions that work perfectly. I think Maya should work fine too, but I haven't tested that.
- Silo 2.5(most recent version) works flawlessly under wine, and is perfect for any 3d modeling.
- I don't develop games, but both Unreal and Unity work very well.
The point is, several years ago you couldn't realistically use linux for professional 2D/3D work, now you totally can.