Optimising Screen Updates and User Experience in the GenericEdit Framework

[ginjaninja 618]

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.

[Luke 42623]

@softworkz

[softworkz 5239]

@ginjaninja

Holy cow - how can I get this incredible bunch of nonsense out of your head...?

Should I dissect all the false statements or start fresh - I'm not sure. Almost every sentence is wrong.

First of all, terms disambiguation - and why there are so many different terms:

• GenericEdit
  This provides the definition of an editable component which gets presented on some surface in an interactive way
  (we have cases where GenericEdit is used all alone, without GenericUI - for example in the Win,Xbox and Linux apps)
• GenericUI
  Provides the framing around a GenericEdit component as a page, dialog or wizard and the APIs for communicating with the server (and back)
  (we have built-in cases where GenericUI is used but without PluginUI)
• PluginUI
  Is a layer - or primarily a set of base classes intended to make it easy to use GenericUI + GenericEdit from a plugin

Here are some general points which are crucial to understand:

• GenericEdit/UI is agnostic of UI platform and technology
  It has nothing to do with HTML or DOM in the first place. It's possible (for us) at any time, to to create a client-side implementation for a different technology, like for example Android or iOS native UI. At some point, I had started an implementation for WinForms (just for fun - I didn't get very far due to time constraints) - thats absolutely doable without any changes on the side of plugin developers 
• State
  State is global. Each plugin UI view has exactly one state: The values at the server
• Refresh
  Is up to you. You can raise the UI view change event from the server and then, all clients currently viewing that UI view will see the updated view.
  Sometimes, this is desired and sometimes not: for example, when the user is supposed to set multiple parameters and finally save them via button click. In that case, it can happen that two clients are showing different values - when at least one of them hasn't submitted their pending changes
  You can decide whether you either want to have a "last one wins" behavior, or send a changed event when one client submits an update. This will throw away potential changes which somebody else (or the same user) might have made - but not submitted

For the issues you mentioned:

• 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
•  

...we'd need to look at the specific cases.

 

[TMCsw 277]

1 hour ago, softworkz said:

Holy cow - how can I get this incredible bunch of nonsense out of your head...?

Kinda pointless to argue with an AI-generated Post?

[softworkz 5239]

4 minutes ago, TMCsw said:

Kinda pointless to argue with an AI-generated Post?

The post is not AI generated - I know he is working with these things and his questions are very legitimate.

He just - then - quoted what an AI model thinks about it, and the one thing I would argue is that this specific model is not among the brightest candles on the tree..