How best to optimise BackgroundColors in a hierarchy of Views when the Colors will be the same?

JohnHardmanJohnHardman GBUniversity mod
edited December 2018 in Xamarin.Forms

A ViewModel has a public property that returns the state of some entity.
The View presents that state information in the form of the BackgroundColor (accessibility is taken care of separately).
The ViewModel doesn't know how the View presents the state, so the View uses a ValueConverter to convert the state to the corresponding Color.
All good so far.

The View is made up of a Layout and the Children of that Layout (and any Children or Content of those Children).
The BackgroundColor of the Layout represents the state of the entity.
The BackgroundColor of the Children (and further descendants) of the Layout will also represent the state of the entity, so will be equal to the BackgroundColor of the Layout.

Various implementation methods exist:
(1) The Layout and each of the Children have their BackgroundColor bound to the ViewModel property, each using the ValueConverter. That means lots of repeated conversions.
(2) The Layout has its BackgroundColor bound to the ViewModel property, and each of the Children have their BackgroundColor set to Color.Transparent. So, only one conversion and a lot of Transparent colors.
(3) The Layout has its BackgroundColor bound to the ViewModel property, and each of the Children have their BackgroundColor bound to the Layout's BackgroundColor
(4) Any others?

So, the question is - without breaking MVVM, which would be expected to be the most performant implementation?

Answers

  • ClintStLaurentClintStLaurent USUniversity ✭✭✭✭✭

    The BackgroundColor of the Children (and further descendants) of the Layout will also represent the state of the entity, so will be equal to the BackgroundColor of the Layout.

    sounds like

    each of the Children have their BackgroundColor set to Color.Transparent. So, only one conversion and a lot of Transparent colors.

    To me

  • JohnHardmanJohnHardman GBUniversity mod

    @ClintStLaurent said:

    The BackgroundColor of the Children (and further descendants) of the Layout will also represent the state of the entity, so will be equal to the BackgroundColor of the Layout.

    sounds like

    each of the Children have their BackgroundColor set to Color.Transparent. So, only one conversion and a lot of Transparent colors.

    To me

    That's my thinking too, but I recall warnings about Color.Transparent making rendering slow.

  • ClintStLaurentClintStLaurent USUniversity ✭✭✭✭✭
    edited December 2018

    As I recall from the Xamarin folks at the Evolve 2016 conference...
    The big warning was on the Opacity property. That it was more performant to define a color where the alpha channel was set to some level of semi-transparent that it was to use a solid color then set Opacity to 25% etc.

    Thus I have static resource colors such as

                <Color x:Key="WhiteTrans">#55FFFFFF</Color>
                <Color x:Key="BlackTrans">#55000000</Color>
    

    where the alpha channel is preset

  • JohnHardmanJohnHardman GBUniversity mod
    edited December 2018

    The corresponding question for TextColor, where any Labels that are descendants of the Layout have the same Color, similarly resulting from a conversion from a state returned by a View Model property, is how best to optimise those TextColors without breaking MVVM?

    Again, each could do the conversion, resulting in much duplication.

    Alternatively, the View could have a property that returns the Color to use, with that being updated when the View Model state changes. The Labels could then have TextColor bound to the View's Color property. That doesn't reduce the number of bindings, but does reduce the number of conversions.

    Is there a better approach?

  • JohnHardmanJohnHardman GBUniversity mod

    @ClintStLaurent said:
    As I recall from the Xamarin folks at the Evolve 2016 conference...
    The big warning was on the Opacity property.

    Ah, that's interesting. I'll go back and check... :-)

  • ClintStLaurentClintStLaurent USUniversity ✭✭✭✭✭

    @JohnHardman said:
    The corresponding question for TextColor,

    If it helps, I did do an article on theming your app. Maybe it will be an approach you like... or leads you in a direction you like.
    http://redpillxamarin.com/2018/07/19/2018-104-resources-styles-and-themes/

  • JohnHardmanJohnHardman GBUniversity mod

    Thanks @ClintStLaurent . I already use Styles for theming. I just have this one page where I am looking at methods to improve performance. For the BackgroundColor used by descendants of the Layout, I can put Color.Transparent in the Style if Transparent turns out to be the fastest approach. For the TextColor, I could use a dynamic Style, but suspect that in this particular scenario doing so would not be the most performant approach.

  • GaetanFGaetanF USMember ✭✭✭

    If your primary concern is MVVM, I would go for binding the colours between views because it keeps the concern of the UI away from the ViewModel and the decision taking at one place. Depending on the colours changing often or not, I don't think it will be a big deal (not 100% sure, to be measured though).

    I rely on this sometimes which I think close the loop with what @ClintStLaurent said about the Evolve 2016: https://kent-boogaart.com/blog/jason-smith%27s-xamarin-forms-performance-tips

    Hope this helps

  • JohnHardmanJohnHardman GBUniversity mod
    edited December 2018

    @GaetanF said:
    I rely on this sometimes which I think close the loop with what @ClintStLaurent said about the Evolve 2016: https://kent-boogaart.com/blog/jason-smith%27s-xamarin-forms-performance-tips

    Yes, it's the "AVOID transparency. If you can achieve the same (or close enough) effect with full opacity, do so." item that makes me hesitate about using Color.Transparent .

    In the Evolve talk, Jason said "Don't use transparency if you don't need it. Overlaying a black semi-transparent box on top of a white background is a lot slower than overlaying a gray box that's opaque". Very fuzzy language unfortunately. He mentioned transparency, but then talked about what is presumably Opacity.

  • ClintStLaurentClintStLaurent USUniversity ✭✭✭✭✭

    @JohnHardman said:
    Yes, it's the "AVOID transparency. If you can achieve the same (or close enough) effect with full opacity, do so." item that makes me hesitate about using Color.Transparent .

    The problem there is the mixing of terms "transparency" and "opacity". There is an "opacity" property on controls. Versus "transparency" which is the value of the alpha channel of a color.

    You can have a Grid with 100% opacity whose color is set to around half transparency with <Color x:Key="WhiteTrans">#55FFFFFF</Color>

    As I understood it from the conference... The goal is to let the control render at 100% opacity even with a semi-transparent color. As opposed to having a solid color then telling the control to render at 50% opacity.

    So the question is... Is the person writing whichever article using the terms correctly?

  • JohnHardmanJohnHardman GBUniversity mod

    @ClintStLaurent said:
    So the question is... Is the person writing whichever article using the terms correctly?

    Kent Boogaart was summarising what Jason Smith said at the conference. Unfortunately, Jason's language was open to interpretation or misinterpretation, so would be hard for anybody to summarise accurately. Now that Jason has moved on, it's probably a question for the Xamarin support team. @JGoldberger - can you clarify what Jason said about transparency and opacity with regards performance impact please, and confirm whether it is still the case in XF 3.3+ ?

  • JGoldbergerJGoldberger USMember, Forum Administrator, Xamarin Team, University Xamurai

    @JohnHardman said:
    ... can you clarify what Jason said about transparency and opacity with regards performance impact please, and confirm whether it is still the case in XF 3.3+ ?

    I cannot off hand myself, but I have put the question to the Forms team and will respond here when and if I get an answer.

  • JGoldbergerJGoldberger USMember, Forum Administrator, Xamarin Team, University Xamurai

    @JohnHardman @ClintStLaurent

    So the official answer is:

    Opacity and transparency are synonyms, even in this context.

    That an opaque view overlaid onto another view will render more quickly than a view that has some or complete transparency is true on any platform. It is simply because math has to be done to combine the pixels from two views and render a new view that combines both views, as opposed to not having to do that math and just displaying the top, fully opaque view as is, i.e. you do not have to calculate, pixel by pixel, what to display. And it does not matter how you set transparency/opacity, i.e. the same is true whether you set the Opacity property or the alpha channel of a color to less than fully opaque.

  • JohnHardmanJohnHardman GBUniversity mod

    Thanks @JGoldberger

  • ClintStLaurentClintStLaurent USUniversity ✭✭✭✭✭

    @JGoldberger cc: @JohnHardman

    Thanks for tracking down the official take on that. It very much appreciated!

Sign In or Register to comment.