This is my local result using the gist suggested in this comment. This is still work in progress.

Codecov Report

Merging #7060 into master will not change coverage by %.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #7060   +/-   ##
=======================================
  Coverage   90.12%   90.12%           
=======================================
  Files         452      452           
  Lines       82885    82885           
  Branches    13100    13100           
=======================================
  Hits        74703    74703           
  Misses       5347     5347           
  Partials     2835     2835           

Better to wait for the merge of #7084, I expect some conflicts to solve.

Meanwhile, these are my results:

Mayavi	PyVista

Note: this "grey tone" is still here. I suspect there is some scaling of the colormap to do. The range of the colorbar is not correct.

Apparently no conflicts after merging #7084, but feel free to rebase anyway @GuillaumeFavelier

I think we don't see the conflicts because Azure is failing or maybe because Travis is not done yet. I see them locally though. I will rebase

The failures don't seem related to depth peeling, I'll have to split this PR to have a better perspective

Killing CIs for now while we wait for #7513

Okay

... actually I'll just bring the optimistic fix here

Checking Azure here then

It seems it's indeed related to AA. And you think it would not work on Azure if we remove:

    if os.getenv('AZURE_CI_WINDOWS', 'false').lower() == 'true':
        return

Now that we check if the figure is active?

It seems it's indeed related to AA. And you think it would not work on Azure if we remove:

The old check was just to see if ren_win existed. All the PyVista code does is set some ren_win things and call modified. So it should have errored out if ren_win did not exist.

So I think is_active might not be checking that things are sufficiently activated (e.g., OpenGL context actually created) to set the necessary properties.

... oh I guess it does not actually check ren_win (the depth peeling code does). So maybe it would be sufficient. I guess you could try it, but it might be better to put effort into getting this PR merged with green CIs, then undo some of the workarounds if possible in later PRs.

getting this PR merged with green CIs, then undo some of the workarounds if possible in later PRs.

+100, this PR is up for too long

This looks like code dup that should be refactored with plot_source_estimates

Sorry for being paranoid but I'll push my latest changes once the CIs come back green.

Awesome that time_viewer='auto' is now working!

@GuillaumeFavelier another fix that I think was in the reverted PR that I just noticed was that smoothing_steps now gets overridden by the slider value instead of the slider being set to whatever value was passed in smoothing_steps. You can replicate by passing for example smoothing_steps=1 which very clearly have gaps, it shows up then gets "snapped" up to 7 steps.

Also this suggests that the steps are being computed twice during init, which will slow things down.

If you fix this, please also check that smoothing_steps='nearest' works properly, because we have to be careful about converting that to 0 when setting the slider value.

Then I think we're ready for merge, right?

I fixed the bugs with smoothing_steps and updated the tests. I also removed the duplicated calls to set_data_smoothing and set_time_point in _TimeViewer.

Looking at the todo list and assuming the CIs come back green, I think we're ready now.

still works great for me !

Very reassuring @agramfort 😅

Works great! Thanks for the awesome work @GuillaumeFavelier