Skip to content

fix(mono): ensure active complex chart paints above overlapping native charts (#295) - #298

Draft
PawelTroka wants to merge 20 commits into
masterfrom
fix/mono-complex-chart-visible-295
Draft

PawelTroka wants to merge 20 commits into
masterfrom
fix/mono-complex-chart-visible-295

Conversation

@PawelTroka

@PawelTroka PawelTroka commented Oct 26, 2026 •

Copy link
Copy Markdown
Owner

Issue

Refs #295. Draft: do not merge or close the issue without owner approval and successful acceptance.

Confirmed diagnosis / limitation

The first Ubuntu 24.04 Mono/X11 test showed that switching to Complex leaves the visible ComplexChart at child z-index 1, behind the hidden 2D plot at index 0. All three charts share DockStyle.Fill. This is an observable stacking error and is capable of causing native sibling occlusion on WinForms/Mono backends. The initial hosted X11 environment nevertheless did render z² successfully after Draw (13,347 sampled colored pixels at quality 25). Thus the user-reported blank screen is not yet reproduced on hosted Ubuntu, and stacking must not be presented as the conclusively proven cause of that screen.

Focused change

  • On __MonoCS__ only, bring the selected chart control to the front on calculation-mode changes; retain the presenter's visibility filtering. Unsubscribe on disposal. No Windows path is changed.
  • Assert the selected complex chart owns z-index 0.
  • Catch and log an exception from current asynchronous complex-chart sampling instead of propagating it through async void Redraw, and display a diagnostic directly in the chart. Reset the diagnostic on Clear/new Draw; retain version checks so superseded render errors cannot pollute a newer plot.
  • Inject a throwing complex function into the visible chart, capture the on-screen diagnostic and prove that a later Draw succeeds without restarting the UI.
  • Drive real X11 pointer/button clicks against the existing desktop Draw button at default quality (five rapid clicks).
  • Capture real desktop on-screen colors and compare expression changes, mode switches, resizing, Clear, cancelled draws and recovery after a compilation error.
  • Extend the actual production executable startup probe to enter Complex mode, Draw z², and capture native before/after X11 screenshots (not GetImage() or DrawToBitmap()).
  • Ensure the Mono workflow installs libxtst6 and cleans stale PNG evidence before each run.

Evidence so far

Initial test-only SHA da10c952 passed 43/43 hosted Mono acceptance checks: on-screen z² pixels changed from 0 to 13,347; chart index was 1. Screenshots: complex-visible-before.png / complex-visible-after.png in the October 26 baseline workflow artifact. Do not confuse these with pre-fix failure/recovery screenshots; the first baseline was already rendering.

Outstanding acceptance

The expanded production startup + XTEST + state-transition CI must pass on this head. The original failing distro/build still needs a comparable run before #295 can be called definitively solved. Retain draft status and do not merge without explicit approval.

Compatibility

Separate from #296's Mono native 3D renderer; its chart is also selected with the same frontmost-control rule. Windows chart visibility/z-order is untouched by the conditional change; the recoverable async-error diagnostic catch is restricted to __MonoCS__, retaining the established Windows Application.ThreadException contract.

October 27 validation follow-up (in progress)

Exact branch head: 82e576d2cd843de6721065a12986487831951dff (commit).

  • Linked tracked build/mono/SmokeTests/ComplexChartUiAcceptance.cs in Computator.NET.slnx (825c5b7), fixing the shared developer-inventory failure that stopped many Windows workflows before testing.
  • Production startup originally used draw.PerformClick() while the passing bootstrapped desktop test drove real XTEST mouse input. Production acceptance now sends one genuine X11 pointer click, verifies button-event delivery, and records whether an actual complex function was attached and whether async rendering failed (cf82022). This was a differential test-harness defect; it is not yet proof that the original Linux graphical issue is completely fixed.
  • Two otherwise independent GSL workflows on the previous head passed 556/557 desktop tests and exposed ComplexChartRenderingTests.FailedRenderingReportsOnlyCurrentErrorsAndAllowsTheNextPlot("current"): Windows must surface current redraw exceptions through Application.ThreadException. Mono-only exception recovery now uses #if __MonoCS__, preserving the Windows contract (7965e05).
  • Cross-PR compatibility: native X11 P/Invoke names in the partial Mono smoke Program collided with PR feat(mono): native interactive f(x,y) 3D surfaces in Linux WinForms #296's native 3D acceptance. The Mono complex probes now use uniquely named P/Invoke declarations with unchanged native entry points (9549148). PR feat(mono): native interactive f(x,y) 3D surfaces in Linux WinForms #296's separate build/mono/validate.sh and X11 package-list changes must be reconciled when integrated; it has not been merged into this branch.

Prior failures reviewed: repeated Windows solution-audit failures share the missing-file issue; the two GSL desktop-test failures are distinct; the production X11 capture had 0 colored pixels although its bootstrapped UI check had 13,347. The production image showed axes but no function colors.

Earlier validation (9549148): The full developer-solution, GSL source and GSL distribution workflows passed after solution and Windows exception-contract fixes. New exact-head validation for that earlier code was superseded: Mono/X11, Windows Cake, developer solution, GSL source and GSL packaged started; check their completed conclusions before treating the new head as accepted. Capture new production-complex-after.png and complex-visible-after.png from that exact-head Mono workflow. The original user environment is not reproduced here. Draft; merge only after owner approval.

Actual production async-render root investigation and fix candidate

The second production X11 acceptance run on 35e8c5cd824422aea0ac64e46516b144d1cdd722 confirmed that a real native click delivers z² to the control but drawing remains stuck after 30 seconds. Reflection observed redraw-active=True, redraw-version=8 (unchanged), sample-quality=1, no sampled grid, the original 1440×1000 empty bitmap and a WinForms synchronization context. The 43 separate GUI smoke tests still passed. This rules out missing Draw delivery, overlaid chart, repeated resize requests, and simple failure to invalidate an already-published colored bitmap; the outstanding defect lies in the asynchronous render-to-publication pipeline.

  • eeb395e: On __MonoCS__ only, dispatch sampling on an explicit long-running default-scheduler background task and poll for completion on a WinForms UI timer instead of relying on an awaited WinForms synchronization-context continuation. Publish or discard results, errors and cached grids on the UI thread; preserve latest-version coalescing, clearing, disposal and retry behavior. The existing Windows async void implementation is unchanged.
  • 82e576d: Instrument the production probe with worker-task and UI-poll state for follow-up diagnosis if necessary.

Exact-head Mono validation: PASS. Native Ubuntu 24.04 Mono/X11 CI completed successfully on 82e576d2cd843de6721065a12986487831951dff. The actual production application delivered one native X11 Draw click and painted 13,347 colored z² pixels instead of the previous 0, completing its startup acceptance in 4.81 seconds. The bootstrapped suite passed 43/43 cases, including expression changes, resize, clear, error recovery and visible X11 screenshots. The workflow artifact contains visually inspected production-complex-before.png, production-complex-after.png, complex-visible-after.png, complex-visible-render-failure.png and recovery captures. Screenshots were captured from X11 screen pixels, not offscreen exports.

Remaining exact-head CI checks: Cake Windows regression, full developer solution, GSL source and GSL distribution. The Mono/X11 workflow is complete and green. The Windows, GSL and developer-solution workflows were still running or queued at this update and are not claimed as complete. Keep draft and require owner approval to merge.

Exact-head Windows and solution results — October 27

@PawelTroka PawelTroka changed the title fix(mono): restore visible complex charts in desktop UI (#295) fix(mono): ensure active complex chart paints above overlapping native charts (#295) Oct 26, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant