Skip to content
This repository has been archived by the owner on May 1, 2024. It is now read-only.

[Bug] Predefined Brushes fail in a multi-window app #14210

Closed
KPixel opened this issue Apr 23, 2021 · 0 comments · Fixed by #14795
Closed

[Bug] Predefined Brushes fail in a multi-window app #14210

KPixel opened this issue Apr 23, 2021 · 0 comments · Fixed by #14795

Comments

@KPixel
Copy link

KPixel commented Apr 23, 2021

Description

Due to the changes in #12761, Brushes are now tied to a specific Dispatcher.
So, when using the predefined Brushes, all the windows will subscribe to change events on the same brush instance. Then, when that brush uses its Dispatcher to notify these windows, all (but one) will be accessed from the wrong thread, causing exceptions.

Steps to Reproduce

  1. Create a multi-window app like the one in the Controls gallery.
  2. Set layout.Background = Brush.Gray; (here)
  3. Run the app and try to open many secondary windows

Expected Behavior

Each window should be displayed with their gray background.

Actual Behavior

On UWP, trying to open many secondary windows throw the exception:

The application called an interface that was marshalled for a different thread. (Exception from HRESULT: 0x8001010E (RPC_E_WRONG_THREAD))

I haven't tried on other platforms, but any of them that use many dispatchers will have the same issue.

Basic Information

Workaround

There isn't really a workaround (aside for not using the predefined brushes).

Fix

The quick fix is to mark all these predefined brushes as [ThreadStatic].

Although this works, there is still a minor performance penalty because every time a predefined brush is used, its Parent changes, and all the other Views that also use that brush get a notification which (probably) trigger a larger UI update than necessary.

An alternative would be to not set the Parent for these predefined brushes, but I'm not sure if that would have another unexpected impact somewhere else...

@KPixel KPixel added s/unverified New report that has yet to be verified t/bug 🐛 labels Apr 23, 2021
@jsuarezruiz jsuarezruiz added this to New in Triage via automation Apr 28, 2021
@jsuarezruiz jsuarezruiz self-assigned this May 3, 2021
@jsuarezruiz jsuarezruiz moved this from New to Needs Estimate in Triage May 3, 2021
@jsuarezruiz jsuarezruiz removed the s/unverified New report that has yet to be verified label May 3, 2021
Triage automation moved this from Needs Estimate to Closed Oct 27, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
Triage
  
Closed
Development

Successfully merging a pull request may close this issue.

2 participants