Slider: Changes not happening in real time

Hello there,

i’m a noob just playing around. Sorry for bugging you and i hope i don’t waste too much of your time.
I made a small panel in UXP for learning how things work. I’m using Alchemist for listening to events. Thank you so much for this brilliant plugin. Without it, UXP would be totally unaccessible to me.
Today i made a slider that controls brightness on an adjustment layer and surprisingly i got this working. But when i’m dragging the slider i only see the histogram changing in real time.
The visible changes in the document happen on mouse up after dragging, although i’m using “input” instead of “change”. I searched for some working code examples but did not find anything useful.
I’m still pretty much confused about async and sync and i don’t really know what i’m doing (still learning). Maybe that is the problem here and someone can point me in the right direction.
This is the code i used:

document.getElementById("brightnessSlider").addEventListener("input", evt => {

   //console.log(`brightness value: ${}`);




            "_obj": "set",

            "_target": [


                  "_ref": "adjustmentLayer",

                  "_enum": "ordinal",

                  "_value": "targetEnum"



            "to": {

               "_obj": "brightnessEvent",


               "center": 0,

               "useLegacy": false


            "_isCommand": false,

            "_options": {

               "dialogOptions": "dontDisplay"




         "synchronousExecution": true,

         "modalBehavior": "execute",

         "historyStateInfo": {

            "name": "Brightness",

            "_target": {

               "_ref": 'document',

               "_enum": 'ordinal',

               "_value": 'targetEnum',






It might have to do with the fact that Photoshop operations executed from scripts are generally quite slow.
I also made the experience that coupling slider input events directly with Photoshop operations performs quite bad.

Sliders are also quite sensitive to cursor movement, so even if you just try to click somewhere on the slider it will probably fire a few times. Even worse, when you drag it, the input event might fire several hundred times.

Now imagine that your dragging process takes 300ms and results in the input event firing 100 times.
If the Photoshop operation for applying the brightness takes 100ms, PS will be quickly overwhelmed, become unresponsive and maybe even crash.

1 Like

Thank you,
yes indeed i know that but: as far as i remember even ancient scriptUI was faster. And there was some options for that in the action descriptor code. Something like: stringIDtoTypeID blabla “Performance” “accelerated” what made sliders really fast in refreshing the document.
Maybe we could implement that in batchPlay somehow?

What bugs me is, that changes are only happening after dragging. Even when i hold the mouse totally still the UI is blocked (cursor just stops spinning). Is that normal behaviour?

Even In the old extendscript UI, I found that using .onChanging for sliders was very unstable. For just changing layer opacity then it would be OK. But anything that took longer to update, it would often cause lagging operation or freezing in some cases and it was different computer vs. computer. Therefore, I had to use onChange instead and only apply the changes when the user let go of the slider.

I haven’t even used sliders at all in UXP but I am guessing it may be similar just because it would be hard for it to keep up, depending on what the function is doing.

I usually just combine slider events with a debounce function. This way, it will wait for more events to come in within a given time frame and then execute the code (when no event came in for X milliseconds).

1 Like

What i thought was that the communication between js and jsx in CEP was what us kept us from real time performance. In my opinion a plugin or extension should extend the possibilities of the base program (Photoshop). Now with UXP, what surely is still in development, i only see more restrictions so far while in CEP we had nearly endless possibilities. I would really love to see some things changing to positive. The sliders were always a thing that put me down.
In Lightroom for example Lua is used to communicate between Lightroom and the User interface. It’s a scripting language as well and real time changes are possible.
Hmmm…I mean as long as we are not calculating on a pixel layer and instead on adjustment layers it should be possible to translate simple gamma or brightness adjustments in real time or am i wrong?
We could build things missing in Photoshop that users really want. Like color wheels for example. Nothing to complex for batchPlay.

Nothing here is related to performance, although you could certainly get into a case where complex adjustments might not be able to update at a high frame rate.

You can validate this in a couple of ways:

  • Use your keyboard to adjust the slider (works with sp-slider only, AFAICT). I have a pretty high repeat rate, and changes to the adjustment layer are immediate and smooth.
  • Add a setTimeout delay to your batchPlays. (Make sure to capture beforehand, so that the actions don’t end up using the latest value instead of the value at the time the timeout was created). If you set a delay of a second or more and move the slider slowly, being sure to release the mouse button before the timeout triggers, you’ll see the same animation occur on the Brightness slider in the Adjustments panel (and in the canvas).
  • Add mousemove event that gets the value from evt.clientX, a short setTimeout for the batchPlay, and DON’T hold the mouse button down while moving over the slider. Depending on how you’ve configured the batchPlay options, you can get real-time adjustment. Of course, this isn’t what you want from the user experience, but it does show that updates happen quite quickly.

Now, I’ll caveat this with: I’m not an expert on Ps internals or Batchplay. But I think what’s happening is that Ps is opting to suppress canvas and panel updates while the mouse button is pressed. I suspect there’s some code in Ps that modifies this behavior when you’re dragging the Brightness slider in the adjustment panel (so you can see the results in realtime), but in this case, Ps has no idea that’s what you’re after when you have a slider in your own panel, and so doesn’t modify how it updates the UI. I did check for a setting that you could use to tell Ps how to update the UI, but I didn’t see one.

I’ll note that this is not specific to sliders. Any time you hold down the mouse button can cause this behavior – Ps will just stop updating the UI until you release the mouse button.

So, it’s not that UXP/Ps can’t update the adjustment layer smoothly, but that Ps is suppressing UI updates while the mouse button is pressed. Odds are that this is for a good reason, since Ps doesn’t necessarily know what action is going to be triggered here, but perhaps the Ps team can add an option to batchPlay to let developers control if an action should always result in a UI update, rather than waiting for a mouse button release. [This is not something UXP controls—it’s up to the Ps team to decide.]

1 Like

That would be wonderful Kerri! Thank you for the detailed answer.

I suggest that you replace the input event with the mouseup event
document.getElementById("brightnessSlider").addEventListener("mouseup", evt => {})