Update web UI

[nyanpasu64]

Fixes most of #412.

• Update package-lock.json to a newer format version (performed automatically by npm, is this OK?)
• Rename web UI items for clarity, improve descriptions
  • I've removed the text that says motion-adaptive deinterlacing adds 1 frame of latency, since all evidence I've seen so far indicates it doesn't. If I'm wrong, this text can be restored.
• Split the Filters help text into two groups, move it below the buttons for consistency with Settings tab
• Make Presets buttons not overflow off-screen when showing help
  • I rewrote the whole <section name="presets"> tab using vertical flexbox. Are my CSS selectors too verbose, since I specify the full path from .gbs-scroll to the .gbs-presets element?
• Make help visible across page reloads (using GBSStorage)

I'm not sure which changes you want to keep or not; I think you should test the changes yourself.

Initially I committed webui_html.h along with each change to the HTML source. But that made it difficult to remove or fixup individual commits, since the header file would be completely different after adding or removing each change, resulting in merge conflicts (unless you ran npm run build to regenerate the header, for every subsequent commit).

I decided to skip committing that header file at each step, and regenerate it in its own commit at the very end. This avoids merge conflicts and avoids bloating up the repository, but introduces the possibility that I forget to regenerate the file. (Scarily, even if I already rebuilt and committed the header from the current sources, npm run build alters webui_html.h anyway, because gzip includes a 4-byte timestamp in the header at bytes 4..=7.)

Testing:

• [x] Presets buttons fill screen, with and without developer settings and console visible, on wide and narrow screens.
• [x] After clearing cookies, help is hidden and no new errors are seen in browser console.
• [x] Clearing cookies and refreshing twice does not expand help.
• [x] Expanding or contracting help is saved across page reloads, both after clearing cookies and reloading, and on subsequent page loads.

Unresolved issues:

• [x] There's still no description for Auto Gain. I don't know what it does.
  • It makes the image coming from my Wii brighter, and gets turned off when I pick a fixed resolution. Is the brighter image more accurate or too bright?
  • It increases image brightness, then randomly samples the image's green/luma channel using TEST_BUS_2F and reduces brightness when it sees clipping (does not reliably stop clipping on 240p Test Suite's color bars, since it usually sees black).
    • Personally I'd decrease gain, sample for the brightest seen color, then increase gain based on how far that is from white, before decreasing gain if clipping is found. But that requires effort to rewrite.
    • And ideally I'd check for the brightest color anywhere on the screen, but this may not be possible with the TV5725.
  • Deferred to a later PR.
• [ ] I don't turn on Line Filter after a factory reset. Is it okay to turn this on, changing default behavior?
  • Deferred to a later PR.
• The HTML inconsistently includes <!-- prettier-ignore --> or not, in the Filters page.
  • Don't care.

[nyanpasu64]

Proposed description (for a later PR):

Auto Gain increases gain so bright areas are displayed as white, then decreases it when clipping is detected. Calibrate for a few seconds on a white screen.

My concern is that if you leave auto gain on, it resets its initial value when the GBS-C is rebooted, requiring the user to again bring up an all-white screen, or else highlights will be clipped (unfortunately auto gain will not reliably identify small white highlights, since it only samples individual points in the image to look for clipping). And if you turn off auto gain after calibration, switching resolutions will reset the current gain to default.

Saving presets triggers bug #401 for 480p inputs (which has a workaround). On the plus side, it saves the current gain (though separately for 15 and 31 KHz inputs), and restores it when you load the preset.

[ramapcsx2]

Auto gain: It does what you deducted :p So the ADC has gain controls on the 3 color channels. Each gain should be set to match the incoming voltage from the source, after cables and passive component and all that. It's clear that most sources will not be a perfect 0.7Vpp on all 3 colors. So auto gain first increases gain to deliberately cause clipping conditions, then it reduces it whenever clipping occurs. So far so good. There is a problem with this, as the debug bus where the ADC values are reported is a) not documented (nothing of the debug stuff is) b) not updating quickly enough c) possibly not sampled (via I2C) often enough So clipping events get missed, and the adjust phase has to run longer. Also, the source video could simply be displaying a lot of dark content at the time.

The tuning of the algorithm tries to work with the constraints, and worked really well for me. I typically left it enabled.

[ramapcsx2]

Line filter is a preference. Sometimes it's also required for ie Motion Adaptive or the Scanlines.. iirc.

[ramapcsx2]

Auto gain kinda has to always run, whenever the source changes or power is cycled. Nothing guarantees that the source has not changed, the cables got worse, or any other real world difference that no one told the GBS about ;p

[nyanpasu64]

Added the Auto Gain description. Personally I think it reads fine.

After testing for a few days, I like the change that makes help remain expanded across page reloads, and don't plan to revert it before merging.

[ramapcsx2]

Sounds good! The explanation for auto gain can be either complete, but span 3 paragraphs, or a short version like yours. I prefer yours for the UI ;p