
2012 Wine bug "Drawing in Photoshop CS5 is almost impossible" now fixed - ashitlerferad
https://bugs.winehq.org/show_bug.cgi?id=29871
======
rayalez
I'm pretty happy with the way CS6 works with PlayOnLinux(Ubuntu 16.04, Wine
1.7.24-CS-0.9.1-DXHR). It's not perfect, but I have no problem getting the
work done (mostly design). I wouldn't use it for drawing/painting though.

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.

~~~
ravenstine
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.

------
userbinator
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."

~~~
majewsky
I thought the saying goes, "Every problem can be solved by adding another
abstraction, except the problem of too many layers of abstraction." ;)

~~~
jcadam
That's not funny - I work in an enterprise Java shop :'(

------
tambourine_man
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.

~~~
uhhhhhhh
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

~~~
notrly
> alternatives

Don't know about Krita, but Gimp still (?) has no good CMYK support, so buh
bai printing industry. Not an alternative.

~~~
uhhhhhhh
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.

------
pjc50
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.

------
b15h0p
Slightly off topic: Does anyone here have CS6 running on the macOS >= Sierra?
I was only able to find information that this is not possible because the
launcher requires Java and Apple removed the JRE from macOS.

~~~
nerdponx
It's pretty easy to install Java on Mac.

------
snvzz
So Photoshop CS5 being usable is a bug?

~~~
jstanley
I read it that way too. I think they fixed a bug that made Photoshop _un_
usable.

------
zazzi
>drawing in photoshop cs5 is almost impossible

usable?

------
fps_doug
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.

~~~
pjc50
I skimmed it and saw at least two attempts that were backed out for various
reasons.

~~~
uhhhhhhh
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.

~~~
web007
> 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.

~~~
uhhhhhhh
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.

