This is probably a stupid question, but:
Is Perspective Workstation basically just a wrapper around launching perspective projects? Or does/can it act as a client itself and able perform tasks independently from the GW? EG perform animations of objects that don’t make references to any resources in the GW
It’s just an embedded Chromium browser running the same Perspective project.
The real value lies in features that are currently unimplemented, like native file system access, native camera access, and other things that you can’t do with with just a browser.
OK, so Perspective Workstation is just a skinned browser. And like all Perspective systems everything is basically running on the GW.
(maybe this should be a new question, but here it goes anyway)
Now I've seen these:
Vision & Perspective: Which Module is Best for Your Next Project?
Vision and Perspective — Which Visualization System Is Best for Me?
Where about all it says about Vision is
Vision is and has been for many years a top-class desktop application. It is the best choice for traditional industrial plant-floor and desktop screens, standalone HMIs, and the like. If you need a full, production-ready application right now, then it is best to choose Vision.
So the big question I really have is:
At a mile high level, is the Vision architecture an equivalent to Perspective, (IE the client only acts as an interface to the system, and each type is just using different transport and visualization technologies?) Or is the Vision client fundamentally smarter than Perspective, and does allow local processing?
The reason behind this is that I have whipped up my beautifully skeuomorphic demonstration HMI in Perspective and I am having some issues with missing some mouse events in my fancy momentary pushbuttons [1] and I'm trying to decide if I should have built this in Vision instead [2]
[1] This system is never going anywhere near a real machine, it was only ever intended as a demonstrator of what could be done visually and how far I could push my design skills.
[2] Never-less it's been a great ride with Perspective and I have learnt an huge amount of things.
I'm not sure I could recommend one or the other, maybe others will have an opinion. I don't know why you'd be missing mouse events in Perspective, regardless of what you're doing... but 
It does allow local processing. Client scope scripts run in the client, which is why Vision Clients can access things like the file system and serial ports or get the hostname without relying on what the IP address that gateway sees.
Have you tried adding button components on top of your graphics and using those for your mouse actions? You can make the button styling invisible
One caveat: While the execution of code happens locally, it will not happen without a connection back to the gateway - not because it couldn't, but because the decision was made a long time ago to not allow this in Vision.
That's an interesting concept that I haven't tried. But fundamentally wouldn't the button component still rely on the same mouse events that I am relying on explicitly?
Going off into the weeds the flow of my button architecture is:
What I have encountered is that sometimes when I click a button, it presses OK, but doesn't un-press at all, even when I move the mouse off the button. It's only when I move back on and then off does the un-press trigger.
I am not sure why this occurs, but if everything (including local properties) are stored on the GW then this could simply be an issue with data transport from the Perspective session back to the GW.
Not a problem, I'm not trying to make an application that is independent of the GW. But thanks for the heads up
Does that mean a script attached to a component will run in the Vision client itself (EG one that calculates a new fill color based on a local property attached to that component)? My understanding of Perspective is that all scripts run on the GW
Yes
Scripts run in the GW for Perspective, but expressions don’t, right? I don’t think i’ve ever bothered to clarify that before…
Nope, gateway as well.
Well then… lucky it’s only my first day using Ignition! 
Is there any public documentation that shows this level of detail, for both Vision and/or Perspective?
The only user-provided stuff that can run in the frontend in Perspective are (most) actions.
Hmm. I’m not sure if there’s anything that breaks it down specifically regarding where things run, but it’s actually pretty simple:
In Perspective, EVERYTHING RUNS ON THE GATEWAY. That’s it. What you see in the browser is basically just the view of the current session state being rendered by the browser. The session is synced between browser and gateway. All the logic runs on the gateway and the changes to the session are synced up to the browser, and your input events from the browser are relayed down to the session to react to.
edit: I don’t even know what actions Paul is talking about, but that’s probably my lack of Perspective knowledge. Maybe that in code running on the gateway you can trigger certain things to happen in the browser? 
So what’s your elevator speech for Vision then?
Use it if you still need local file system / serial / other access?
Certainly don’t use it if you have any kind of high DPI screen 
There’s other things too… Perspective hasn’t reached 1:1 Vision feature parity, but it’s steadily on its way.
We’ve wandered beyond where you should be listening to my advice. I don’t have to use either of these to deploy real world applications. Listen to the other guys here who actually do.
Specifically, by actions, I’m referring to these:
https://docs.inductiveautomation.com/display/DOC81/Component+Events+and+Actions
~Most of these are able to execute locally before any roundtrip to the gateway.
Ok … but if an Event has a script attached to it, doesn’t that imply that there is a trip to the GW in its future?
(and isn’t the state of local properties maintained in GW?)