Optimize dragging performance with requestAnimationFrame

[Sidharthwin]

Summary

This PR improves performance when resizing dialogs (e.g., JS Editor and resizable widgets) by throttling mousemove-based resize logic using requestAnimationFrame.

Currently, resize logic is executed directly inside a mousemove event handler, which can trigger hundreds of DOM updates per second. This leads to unnecessary layout recalculations and increased CPU usage during drag operations.

---

Changes

• Wrapped doResize logic inside a requestAnimationFrame loop

• Ensured only one resize update runs per frame

• Reduced excessive DOM writes during continuous mouse movement

• Applied changes to:

  • js/widgets/jseditor.js
  • js/utils/mb-dialog.js

---

Before

• Resize handler executed on every mousemove event
• Frequent layout recalculations
• Noticeable lag/jank during resizing
• Higher CPU usage

---

After

• Resize updates aligned with browser render cycle (~60fps)
• Reduced layout thrashing
• Smoother resizing experience
• Lower CPU usage

---

Implementation Details

A simple RAF-based throttle was introduced:

• Store latest mouse position
• Schedule resize using requestAnimationFrame
• Prevent multiple RAF calls from stacking

This approach is consistent with existing optimizations used for block dragging.

---

Notes

This change focuses on improving performance without altering existing behavior or UI logic.

---

Checklist

• Code follows project guidelines
• No breaking changes introduced
• Tested manually for resizing interactions
• Ready for review

---

• Performance

[github-actions]

✅ All Jest tests passed! This PR is ready to merge.

[github-actions]

✅ All Jest tests passed! This PR is ready to merge.

[github-actions]

❌ Some Jest tests failed. Please check the logs and fix the issues before merging.

Failed Tests:

help.test.js

[github-actions]

❌ Some Jest tests failed. Please check the logs and fix the issues before merging.

Failed Tests:

help.test.js

[github-actions]

❌ Some Jest tests failed. Please check the logs and fix the issues before merging.

Failed Tests:

help.test.js

[Sidharthwin]

@walterbender , @Ashutoshx7 pls review this . Whenever free :) . Checking the jest test case

[github-actions]

✅ All Jest tests passed! This PR is ready to merge.

[Ashutoshx7]

@zealot-zew take a look
your thoughts on this
as u are the one who build this

update : i did test it out and did the code review looks goood to me

[Ashutoshx7]

@Sidharthwin thanks for working on this

the raf throttle pattern is consistent with our current implementation in widgetwindows
but just minor fix in setupwindowresize() add a null guard for resize direction inside the raf callback to prevent the potential crash id stopresize() between schedulling and excution

resizeRafId = requestAnimationFrame(() => {
    if (!isResizing || !resizeDirection) {
        resizeRafId = null;
        return;
    }
    // ... rest of resize logic
});

[karthik-dev56]

Hey @Sidharthwin Using requestAnimationFrame here is absolutely the right call for improving dragging and resizing performance—nice work overall, the code looks really solid.

There’s just one subtle issue with how the coordinates are being captured during the throttling. Right now, clientX and clientY are taken at the moment requestAnimationFrame is triggered, and any subsequent mousemove events get ignored until that frame finishes. Because of this, the UI ends up using the first coordinates within that ~16ms frame instead of the latest ones. The result is a slight lag where the dragged element doesn’t fully keep up with the cursor, especially noticeable when the mouse stops moving.

Suggested fix:
Let’s store latestClientX and latestClientY outside of the requestAnimationFrame. Update these values on every mousemove event, and then read from them inside the requestAnimationFrame callback.

Could you apply this small adjustment in mb-dialog.js and also in both resize handlers within jseditor.js?

[Ashutoshx7]

Hey @Sidharthwin Using requestAnimationFrame here is absolutely the right call for improving dragging and resizing performance—nice work overall, the code looks really solid.

There’s just one subtle issue with how the coordinates are being captured during the throttling. Right now, clientX and clientY are taken at the moment requestAnimationFrame is triggered, and any subsequent mousemove events get ignored until that frame finishes. Because of this, the UI ends up using the first coordinates within that ~16ms frame instead of the latest ones. The result is a slight lag where the dragged element doesn’t fully keep up with the cursor, especially noticeable when the mouse stops moving.

Suggested fix: Let’s store latestClientX and latestClientY outside of the requestAnimationFrame. Update these values on every mousemove event, and then read from them inside the requestAnimationFrame callback.

Could you apply this small adjustment in mb-dialog.js and also in both resize handlers within jseditor.js?

hy i don't think so current implmentation is already good enough
i tried out locally i didn't notice any delay and also performance is up to the mark

[karthik-dev56]

Hey @Ashutoshx7, you won't notice it on a fast laptop, but on lower-end devices it causes jitter. The current logic ignores the newest mouse movements during frame drops. It's only a 2-line change to make it completely bulletproof for all devices, let's just get it right!"

[Ashutoshx7]

Hey @Ashutoshx7, you won't notice it on a fast laptop, but on lower-end devices it causes jitter. The current logic ignores the newest mouse movements during frame drops. It's only a 2-line change to make it completely bulletproof for all devices, let's just get it right!"

but still i think having this as a addition is great ( just acts as a fallback or gaurdrail)

[Ashutoshx7]

@zealot-zew whenever u get time take a look
i am approving look good to me

[Chaitu7032]

LGTM

[Sidharthwin]

@Ashutoshx7 and @karthik-dev56 , Thanks for the feedback and suggestions . I will look into both the things , and get back to you with the best possible outcome

[github-actions]

✅ All Jest tests passed! This PR is ready to merge.

[Sidharthwin]

@Ashutoshx7 and @karthik-dev56 , I agree with both of your feedbacks

I've updated the implementation :

• Now it tracks the latest mouse coordinates outside the RAF callback and use them inside it
• And added a guard inside the RAF callback to handle cases where dragging stops before execution

This should improve smoothness and avoid stale coordinate issues, especially on lower-end devices.

[Sidharthwin]

@walterbender please you also give it a look , and tell me if any change is required

[Ashutoshx7]

@walterbender ready for the merge