On Mon, 13 Jul 2026 15:57:38 GMT, Martin Fox <[email protected]> wrote:
> I don't see anything mutable in an `ImagePattern` that references an animated > `Image`. It's not mutable from an API perspective, but it is mutable in its implementation. The change is triggered by a timer, not by user code. However, I think the question of mutability is a bit tangential, maybe I shouldn't even have brought it up. It's also not my main point. My main point is that `StageBackdrop` is quite closely related to `Paint`, which are shareable configuration objects created by users, and should therefore have a similar API. > I was making a cost/benefit case and arguing that the benefit was zero. You > haven't said anything to change my mind on the benefit = zero part. And I > don't see prior art here; JavaFX avoids sharing mutable objects whenever > possible. You're again trying to ground the API shape in terms of implementation concerns: that by allowing backdrops to be shared across stages we'll increase the cost (which cost?) without adding benefit. But a backdrop is essentially an observable map, where is the cost in allowing it to be shared? It shouldn't matter too much whether we have a single listener or multiple listeners. So you take the cost argument, and use it to explain why a backdrop needs to have a separate API element next to the backdrop style, and why it shouldn't be created by users of the API. I hope that I've made it clear that I consider two entangled API elements for what could be a single API element to be highly unusual, which comes with an appropriately high bar of justification. > If an application wants to create a UI with reduced transparency wouldn't > they just avoid using backdrops in the first place? I'm not that familiar > with the preferences API but I thought it was the app developer's job to > respond to these settings. > > This preference can change on the fly but I'm not sure we can respond by > making the OS backdrop come and go (that's why it's an init call). We can do > this on Mac and Win11 using D3D9 but I'm doubtful about the D3D12 backend and > Linux is a big unknown. If a client wants reduced transparency outside the OS > setting they could just not use backdrops or cover the backdrop with an > opaque fill. I don't think the JavaFX core code can do much better than that. Preferences are the user's choice (compared to the developer's choice when building the app), and should ideally be respected out of the box, without requiring developers to "opt in" by branching over preferences (setting a backdrop when reducedTransparency=false, and not setting a backdrop otherwise). I don't think that we should be automagically and permanently "downgrade" a backdrop to no backdrop when reducedTransparency is enabled, as if by ignoring the argument of the init call, and setting it to null. Because if we did, then what would happen if reducedTransparency is later disabled? We'd expect the backdrop to reappear, but since we've permanently downgraded to "no backdrop", nothing happens. That leaves us with two other options: make it a best-effort operation, or don't respect the reducedTransparency preference at all. In the first case, we could dynamically remove the backdrop on platforms where this is possible, and don't do anything on platforms where this isn't possible. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2048#issuecomment-4963723060
