Optimising Screen Updates and User Experience in the GenericEdit Framework

Posted 2 hours ago · 2026-06-22T09:47:09Z

My minimal understanding is start to butt up against achieving a nice UI experience and i was hoping people could part the clouds of understanding a little and establish some relevant ground truths (for me to direct my efforts and learning).if you would be kind enough to spare some time.

This is an AIs understanding of the Emby genericedit framework (im probably not using the right term..maybe genericUI?PluginUI?). Would people support the key bottom line points / disagree with any of it?
The main issue i want to get an understanding of is; how much 'liveness' is realistic to try and achieve in the UI whilst maintaining a reasonable user experience. Are the suggested patterns good ones to adopt?

'Issues' i am hitting

Being returned to the top of the page when clicking on checkbox in a dxgrid.
Rows in genericitemlist members bouncing in and out of view whilst a task which is working on them and moving them to 'completed' is processing them.
Different UI states when nothing is happening and i navigate away and backagain (Understanding the lifetime of data in the framework perhaps)

I am talking about plugins with what i assume are trivially small 'UI data sets'. I want the UI to be responsive, live and survive page navigations back to main emby and back to plugin but i wonder if my expectations are unrealistic and where I should focus efforts.

1. Does Emby require “full DOM model refreshes”?

In practice: yes — functionally it behaves that way.

But not in the literal browser-DOM sense.

What actually happens is:

Your EditableOptionsBase model is re-serialized server-side
The client receives a full updated view model
The UI is re-rendered from that model snapshot

So when people say:

“Emby sends the whole DOM model”

What they really mean is:

“Emby re-renders the entire page from a full server-provided model each time it updates”

There is no stable virtual DOM diffing system like React/Vue.

2. Are incremental UI updates supported?

Short answer: not really

There are only two “update modes”:

A. Full model refresh (your main tool)

Triggered by:

RaiseUIViewInfoChanged()
property updates on the view model
command execution returning updated state

This causes:

✔ full UI rebind
✔ full list regeneration
✔ full status refresh

This is what you are using now.

B. Limited partial updates (very constrained)

Some Emby UI components can update more surgically:

progress bars (PercentComplete)
status fields
some list item properties (depending on client implementation)

BUT:

This is inconsistent across:

Emby Web UI versions
mobile apps
different GenericEdit controls

So it is not safe to build architecture assumptions on it.

3. The key architectural truth (important for your design)

Your mental model should be:

“I am not patching UI. I am re-declaring UI state.”

NOT:

“I am updating a live UI tree.”

This is the single most important shift.

4. Why your current architecture actually works (and is close to optimal)

Your system already does something Emby-friendly:

You are doing snapshot rendering:

RebuildMovieList()
full replacement:
```
ui.MovieList = newList;
```

This aligns perfectly with Emby’s expectations.

5. Why you are seeing “bouncing / redraw pain”

The real issue is not Emby.

It is this:

You are mixing 3 state streams

Emby library state (Coming Soon rows)
Tracker state (live progress)
User transient state (toggledOn)

And you rebuild everything on:

timer tick
task events
commands

So you get:

“full recompute + full rebind every second”

That feels like instability, but it is actually correct behaviour for this framework.

6. Can you avoid full redraws?

Strict answer: not reliably

You can reduce frequency, but you cannot safely eliminate it.

What you can do:

Option A (recommended): “diff-lite model discipline”

Instead of trying to avoid redraws, you:

Only allow redraw when signature changes

You already do this:

if (signature != lastPolledSignature)

This is the correct strategy in Emby land.

✔ This is effectively your “manual diff system”

Option B: split “fast UI” vs “slow UI”

This is where you can gain performance and stability:

Fast updates (polling only):

progress %
status text
active rows only

Slow updates (full rebuild):

Coming Soon list
analysis results
toggles
history rebuild

This reduces UI churn massively.

Option freeze structural list during runs

Big improvement pattern:

Do NOT rebuild Coming Soon rows every tick

Instead:

build rows only on:
load

refresh

retry
only update tracker overlay on timer

This alone removes ~80% of UI redraw noise.

7. What Emby does NOT give you

To be very explicit:

no virtual DOM
no diff-based rendering guarantees
no stable component identity model
no incremental list patch API
no client-side state retention across full refreshes

So anything like:

“update only row 3”
“patch one field in list”
“incrementally mutate UI tree”

…is unreliable or not supported consistently.

8. What Emby does give you (and what you should lean into)

✔ deterministic full-state rendering
✔ server is source of truth
✔ UI = pure function of state (conceptually)
✔ timer-driven refresh is acceptable pattern
✔ stateless UI rebuild is expected pattern

9. The mental model you should adopt

This is the key shift:

Treat every UI render as:
“If I lost all UI state right now, could I reconstruct it from memory?”

If yes → your design is correct
If no → you’re depending on unsupported incremental behaviour

10. Bottom line

✔ Emby does NOT support true incremental UI updates in a reliable way
✔ Full model refresh is the intended design pattern
✔ Your current approach (RebuildMovieList + RaiseUIViewInfoChanged) is correct
⚠ The risk is not redraws — it’s over-redrawing too frequently
✔ You should optimise by reducing rebuild frequency, not trying to avoid rebuilds

I have no training in development. i am learning by osmosis, the reference docs where they can help, and the forum. I am only a beginner understanding c# (but ai can help with that), i think UI is a few steps beyond that, so be gentle .
Thanks in anticipation.

Sign In