Closed Bug 1411937 Opened 7 years ago Closed 2 years ago

Investigate render only chunk of messages that fits the viewport

Categories

(DevTools :: Console, task, P2)

task

Tracking

(firefox57 wontfix, firefox58 wontfix, firefox59 ?)

RESOLVED DUPLICATE of bug 1753177
Tracking Status
firefox57 --- wontfix
firefox58 --- wontfix
firefox59 --- ?

People

(Reporter: nchevobbe, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(2 obsolete files)

In Bug 1391688, we'll do a first render with only the latest messages that fit the viewport, and then a second one with all the messages.

What can be done is to only render what fits on screen, and then only render additional messages (not the cached ones) *until the user interact with the UI* (e.g., scrolls, click a filter button, enter text in filter output, …). 

When the user start to interact, a flag would be set in the store, and we'll render every messages.


We can even mix that with having a requestIdleCallback to render cached messages as well, by chunks, so we don't lag too much when the user start to interact with the console.

Say we have 1000 messages logged before opening the console.
20 messages fit on screen, so we render the last 20 message.
New logs are added, and we render them after the 20 "cached messages"
In the same time, we register a requestIdleCallback which would render the 20 * 2 last cached messages.
Then we register a requestIdleCallback which would render the 20 * 3 last cached messages.
And so on until all cached messages are rendered, or the user start interacting with the UI.
Priority: -- → P3
Whiteboard: [console-html][triage]
(In reply to Nicolas Chevobbe [:nchevobbe] from comment #0)
> When the user start to interact, a flag would be set in the store, and we'll
> render every messages.
> 
> We can even mix that with having a requestIdleCallback to render cached
> messages as well, by chunks, so we don't lag too much when the user start to
> interact with the console.

IMO we should try to render in chunks rather than waiting for interaction, since there could potentially be plenty of idle time to have rendered messages before any interaction. And if we don't it will pretty much guarantee the first click / scroll will be janky if there are lots of cached messages.
Priority: P3 → P2
Whiteboard: [console-html][triage] → [newconsole-mvp]
Summary: Render only messages that fit the viewport until there is a user interaction. → Investigate render only chunk of messages that fits the viewport
Whiteboard: [newconsole-mvp]
Product: Firefox → DevTools
Blocks: console-perf
Type: enhancement → task

I'll take a look.

Assignee: nobody → bwerth
See Also: → 1308216
See Also: → 1468065

Hmm, although react-window can handle variable-height lists, we have to supply the height of the row in the render function. This is incredibly challenging. Here's a way we could do it:

  1. Cache all the rendered messages.
    Bug 1659773 does this.
  2. When a new message is supplied, render it without specifying a calculated height.
    react-window does not seem to provide a way to do this. We could possibly provide a too-high estimate for this and force a style of height: auto, knowing that it will be fixed up in the next step.
  3. After rendering the new message, capture the rendered size and feed it back into the cached data.
    This invalidates the cached data for that message, but it's a one-time cost. Ideally the re-render that happens would be imperceptible as it would essentially just be setting the height of the row to a fixed value that matches its auto size.
  4. If the console container is ever resized, clear the cache since all the message sizes would be incorrect.
    Probably infrequent.

Huh, so maybe this is doable. I'll mark 1659773 as a blocker.

Depends on: 1659773

This is a very naive attempt. I locally built react-window, and took one of
the dist module files, renamed it to react-window.js and put it in the the
tree. It doesn't load.

Attachment #9170961 - Attachment is obsolete: true
Attachment #9170799 - Attachment is obsolete: true
Assignee: bwerth → nobody
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: