Control Panel: LiveCharts 2.0.5 renders the dashboard charts white over the dark theme

[chrisholloway5]

Summary

The Control Panel is pinned to LiveChartsCore.SkiaSharpView.WPF 2.0.0-rc2. Upgrading to 2.0.5 (proposed by Dependabot in #9) builds and runs, but regresses the Dashboard:

• the chart plot area is painted opaque white while the rest of the application is on the dark theme;
• the empty-state overlays ("No delivery activity yet", "No active sessions") are no longer visible — they sit in the same grid cell as the chart and are declared after it, so they should render on top.

Both charts on Dashboard are affected (ThroughputChart and SessionsChart in Views/DashboardView.xaml).

Likely cause

2.0.5 pulls in SkiaSharp.Views.WPF 3.119.0, which in turn brings OpenTK 3.3.1 and OpenTK.GLWpfControl 3.3.0. That points at a GL-hosted rendering surface rather than the software SKElement used by rc2, which would explain both symptoms at once — an opaque backing surface and WPF airspace hiding anything layered over it.

Side effect on CI

SkiaSharp.Views.WPF ships only .NET Framework assets, so restoring it against net8.0-windows raises NU1701 three times (SkiaSharp.Views.WPF, OpenTK, OpenTK.GLWpfControl). The Control Panel CI job builds with -warnaserror, so the upgrade fails the build. Suppressing NU1701 clears CI but does not address the white chart, so it was not applied.

What to investigate

• Whether 2.0.x exposes a way to force software rendering / keep the SKElement host, or a chart-level background that defeats the opaque surface.
• Whether the empty-state overlays need to move out of the chart's airspace regardless (e.g. rendered as a chart element rather than a sibling TextBlock).
• If it is genuinely a GL airspace limitation, whether the placeholders should be redesigned rather than layered.

Reproducing

1. Set LiveChartsCore.SkiaSharpView.WPF to 2.0.5 in hmailserver/source/Tools/ControlPanel/ControlPanel.csproj.
2. Add <NoWarn>$(NoWarn);NU1701</NoWarn> so the build passes.
3. Build and open the Control Panel on Dashboard, and compare against 6.2.8.

Context

Deferred out of 6.2.8; see #9 for the rest of that dependency group, which was taken.

[chrisholloway5]

Fixed on master in 7d716d0 — LiveCharts is now on 2.0.5.

The cause was neither of the things it looked like. CartesianChart derives from Control, and 2.0.x gives that Control a solid default Background where the release candidate left it unset — so the chart painted a white rectangle across the dark card. The overlays were never actually hidden either: they are light-grey TextBlocks that happened to be sitting on top of that white. Setting Background explicitly on the two charts fixes both symptoms at once.

Worth recording what it was not, because the dependency graph points the other way. 2.0.5 pulls SkiaSharp.Views.WPF, OpenTK and OpenTK.GLWpfControl, which looks exactly like a GL-hosted surface and the usual WPF airspace problem. It isn't — LiveCharts.RenderingSettings.UseGPU defaults to false, so rendering stays on the software path and ordinary WPF layering applies. Chasing the airspace theory would have been wasted effort.

Those .NET Framework-only assets are still what makes NuGet raise NU1701 three times, and the Control Panel builds with -warnaserror in CI, so NU1701 is suppressed for that project with a comment recording why and how far it reaches.

Verified against a live server in both light and dark themes, plus the full Control Panel suite — unit assertions, the offline CollectionEditorView harness, the live DomainDialog/ServerSession harness and the UI-automation pass.

Queued for the next release rather than shipped, since 6.2.8 is already out.

Chris
Progressive Robot