[Question] Accessing Window Root Visual

[csnazell]

Resizing a dark themed UWP application results in "jank" as the root frame cannot resize quickly enough to cover the window's white background. This is present on all dark-themed apps including Microsoft's (try Photos or Groove Music). UWP APIs don't provide access to the window fill colour and unlike WinForms there's no cunning work-around.

I was hoping that I'd be able to use the Composition APIs to work around this but it doesn't appear that this is possible as one cannot access the root visual that should in theory be underlying all the content. Even if one could, since the Visual class doesn't have a background fill property, I'd still have to create a SpriteVisual to fill the window and then resize it when the window changed size.

Is this a correct description of the situation?

[robmikh]

The way things are now, you're correct. Even if you got direct access to the window messages and resize the visual it wouldn't be guaranteed to be in sync (in the sense that it wouldn't be technically "perfect", although it wouldn't be too bad).

As an educational exercise, you can try this out for yourself by writing a frameworkless app that is pure composition. The basic CompositionVisual sample is one such application.

TL;DR: Yes, it is a correct description of the current situation.

[tomzorz]

Until then I've found that if you throttle the size changes that makes it a little bit better: https://shoreparty.org/throttling-window-size-changes-in-uwp-apps-dab8160f856c#.u5faq177y

[csnazell]

@robmikh I thought I'd ask before poking around as I have about 96 issues with UWP APIs & tooling currently under discussion with PMs in Redmond and I'm trying to minimise the amount of unpaid QA work for I'm doing for Microsoft. ; )

My expectations of .Composition are obviously channelling too much Core Animation. On iOS every visual element is backed by a "layer" so I would have been able to pull out the layer for the root visual and zap the background colour in a couple of lines of code if I couldn't do it directly.

@tomzorz Thanks for the link. I had a play around with throttling when I first encountered the issue last year. I dislike the appearance of the throttled window resize more than the unthrottled situation. Throttling changes the "jank" from a flicker at the edge of the window to being a really obvious "kerchunk" as it step changes between sizes. It's frustrating that no one working on Photos or Groove bothered to report the issue back to the API team, assuming of course they noticed the problem.

[tomzorz]

Basically all UWP apps experience this - the recording in my post is from the mail app.

[JustinXinLiu]

@robmikh I have actually noticed that this issue is a lot less noticeable in a frameworkless app than in a xaml app.

So I am wondering if it's possible to access the "CompositionTarget" object (if it's even existed) from the main CoreWindow in a xaml project?

[robmikh]

No, there isn't a way to get access to XAML's root visual at the moment (or their target for that matter). At the end of the day, it is probably more of an event timing issue. Listening to a UIElement's size changed events tie you to when XAML recomputes the size. Thus if your app is complex, this may impact when you get the event relative to the resize of the window. However, if you want to independently resize a background visual you could get the backing visual of a grid that is as far back as possible and then directly hook into the CoreWindow's size changed event:

Window.Current.CoreWindow.SizeChanged += (o, a) =>
{
    _visual.Size = new Vector2((float)a.Size.Width, (float)a.Size.Height);
};

[sernaj]

robmikh's recommendation is solid. Wanted to explain a bit about why you can't currently get the root visual for a XAML object directly, this comes back to where we are currently in our interop implementation with the API. Right now when you use ElementCompositionPreview you're getting what we call a "hand-off" visual from the framework that represents the UIElement. But it's not "the" visual or even a root visual tied to the rest of the UIEement. It created when you do interop. We totally get this isn't ideal and it isn't our end state for interop, we want to get to a much more closely matched world where the parts of UIElement and Visuals are a more natural mix. But that's going to take some work on our API and on the XAML framework side, and we are planning a lot of that right now. The cool thing is that you will get see some of the thinking on this in insider flights in the future are we try things out. Folks coming to //build should feel free to grab us to chat about this.

[JustinXinLiu]

Thanks @robmikh and @sernaj for the explanation. I am not going to Build but I will be watching it live. :)

Can't wait for it!

[tomzorz]

Sounds awesome, thanks for the explanations - I'm really eager to see the expanded interop functionality :) Too bad that I won't be at build either... but maybe we'll talk at the mvp summit.

[csnazell]

Thanks for the explanation. It's frustrating that this API is so far behind the curve compared with what's available on iOS but it's great that you're working on it.

I'm based in Scotland so attending //build's just not cost-effective for what I'd get out of it.

[sernaj]

Thanks again for all the interest and feedback. No worries about not being at //build. Everything we show at //build will be recorded so I'll make sure we're updating the GitHub with links to talks and new samples and of course we'll be sending the info out on the Twitter feed as well. Going to close this particular question but keep the new questions and feedback coming.