2012 Wine bug "Drawing in Photoshop CS5 is almost impossible" now fixed
bugs.winehq.org
bugs.winehq.org
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.
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."
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.
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.
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
Don't know about Krita, but Gimp still (?) has no good CMYK support, so buh bai printing industry. Not an alternative.
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.
https://en.wikipedia.org/wiki/GEGL#babl http://www.gegl.org/babl/
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.
now, I do mostly web and dev, so Linux is a sweet spot there...
If you need to run Photoshop, it is a Linux (as a plataform), problem. Also “Wine Is Not an Emulator”.
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’s why projects like MAME are very important.
usable?
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.
"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.
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.