Memoryleak / Incremental render updates in scheduler #1403

New Issue

claunia · 2026-01-29T17:53:14Z

claunia commented

2026-01-29 17:53:14 +00:00

Originally created by @HansenBerlin on GitHub (Sep 23, 2024).

Description

If an appointment item is dragged/moved in the scheduler (weekview) this triggers the slot changed event for every pixel(?) the item is being dragged. This causes a huge overhead, up to crashing the application if any conditional logic is happening within the event method (like changing styles etc.)

Reproduction:

Go to https://blazor.radzen.com/scheduler?theme=material3
in the first example add this line at the end of the OnSlotRender method: console.Log($"SlotRender: Start={args.Start} End={args.End}");
Click on run
Drag one of the appointments for a very short period. There is a slight delay but it works
Drag one of the events around for one or two seconds. The console is filled with output and depending on the timespan the appointment was dragged the website completly freezes.

Expected behavior

Not crashing... :-) Either a way to throttle the update frequency or to not update at all. In my case I render the backgrounds of the slots only once based on some business logic (holidays etc.). The actual appointments can change but wouldnt cause the slots to change, so in that case some switch to disable rerendering the slots completly would be nice.
As a workaround I tried returning from the method without changing the style (after it was changed once already), but then the current style is wiped.

Originally created by @HansenBerlin on GitHub (Sep 23, 2024). ## Description If an appointment item is dragged/moved in the scheduler (weekview) this triggers the slot changed event for every pixel(?) the item is being dragged. This causes a huge overhead, up to crashing the application if any conditional logic is happening within the event method (like changing styles etc.) ## Reproduction: 1. Go to https://blazor.radzen.com/scheduler?theme=material3 2. in the first example add this line at the end of the OnSlotRender method: console.Log($"SlotRender: Start={args.Start} End={args.End}"); 3. Click on run 4. Drag one of the appointments for a very short period. There is a slight delay but it works 5. Drag one of the events around for one or two seconds. The console is filled with output and depending on the timespan the appointment was dragged the website completly freezes. ## Expected behavior Not crashing... :-) Either a way to throttle the update frequency or to not update at all. In my case I render the backgrounds of the slots only once based on some business logic (holidays etc.). The actual appointments can change but wouldnt cause the slots to change, so in that case some switch to disable rerendering the slots completly would be nice. As a workaround I tried returning from the method without changing the style (after it was changed once already), but then the current style is wiped.

claunia closed this issue

2026-01-29 17:53:14 +00:00

claunia commented

2026-01-29 17:53:14 +00:00

@akorchev commented on GitHub (Sep 24, 2024):

Not sure if we can address that. Blazor does the event handling and UI updates.

@akorchev commented on GitHub (Sep 24, 2024): Not sure if we can address that. Blazor does the event handling and UI updates.

claunia commented

2026-01-29 17:53:15 +00:00

@illiniguy commented on GitHub (Sep 26, 2024):

FWIW I personally don't see that issue if I use the demo as-is. That added line of code and the overhead of printing to that console I think is what causes it to go haywire. If I follow the added step I saw the same freezing, etc. But if I use the demo as-is I only saw CPU go up in the tab but memory, responsiveness, etc. seemed fine. I assume if you had a needed side effect you could debounce it yourself to only write to console for instance after a certain time passes.

@illiniguy commented on GitHub (Sep 26, 2024): FWIW I personally don't see that issue if I use the demo as-is. That added line of code and the overhead of printing to that console I think is what causes it to go haywire. If I follow the added step I saw the same freezing, etc. But if I use the demo as-is I only saw CPU go up in the tab but memory, responsiveness, etc. seemed fine. I assume if you had a needed side effect you could debounce it yourself to only write to console for instance after a certain time passes.

claunia commented

2026-01-29 17:53:15 +00:00

@akorchev commented on GitHub (Oct 17, 2024):

Closing this issue as I don't thing there is anything actionable we can do.

@akorchev commented on GitHub (Oct 17, 2024): Closing this issue as I don't thing there is anything actionable we can do.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/radzen-blazor#1403