Acknowledged
8 months ago

Red Shift Mode is not playing well with red colors

I see following on my watch (Fenix 8) when I switch on red shift on:

  • the location icon in the circle style menu (long press the top left button) where you can turn on the red shift mode is displayed in full red no matter if red shift is on or off
  • when a watchface is using a red color though, the red gets somehow "faded" like in following picture

Also, it would be very nice to know if the red shift is on or not - example use cases are described here: https://forums.garmin.com/developer/connect-iq/f/discussion/354812/any-way-to-know-watch-is-supporting-red-shift-mode - it may be necessary to use different colors in red shift mode or to use a single color only e.g. to get a good result...

In my case the red color does become hardly readable in red shift mode - I think red should stay full red or all colors should become the same red - the garmin cirlce menu does handle it like that...

Michael
Parents
  • 8 months ago in reply to Travis.ConnectIQ

    I know there are different algorithms and the implementation is probably doing everything right considering the name "red shift", BUT I mean that there is following problem:

    The red shift mode is not implemented in a way that a custom watchface does not have to react to it in any circumstance - I think you have written once it is (like "the developer does not need to do anything differently if the red shift mode is active"). Currently if the developer wants to provide a usable, readable and beautiful result in red shift mode he can't... personally, I would be very happy if I could simple check if red shift mode is active or not.

    Regarding algorithms, e.g. on android there is a wide spread thing inside google's UI elements called tinting - heavily used for icons e.g.. There the implementation is "switching" the base color with the tint color and alpha/luminance is kept as is. Solid blue would become solid red, solid red would stay red, semi transparent blue would become semi transparent red, semi transparent red would stay semi transparent red and so on...

    My wish is following actually:

    Nevertheless I would be happy with the most simple solution - I don't see anything speaking against exposing a flag to access the current state of the red shift mode (and the current shift color) and this would solve all issues because then everyone can adjust their code to achieve whatever someone wants to achieve.

    Alternatively using a tinting algorithm may be a good alternative solution as well but I don't know if garmin is open to changing something at that level and I even don't know what that would mean for garmins code so I assume that's something that won't happen - but this would go more in the direction "the system does everything and the developer does not need to know anything about it".

Comment
  • 8 months ago in reply to Travis.ConnectIQ

    I know there are different algorithms and the implementation is probably doing everything right considering the name "red shift", BUT I mean that there is following problem:

    The red shift mode is not implemented in a way that a custom watchface does not have to react to it in any circumstance - I think you have written once it is (like "the developer does not need to do anything differently if the red shift mode is active"). Currently if the developer wants to provide a usable, readable and beautiful result in red shift mode he can't... personally, I would be very happy if I could simple check if red shift mode is active or not.

    Regarding algorithms, e.g. on android there is a wide spread thing inside google's UI elements called tinting - heavily used for icons e.g.. There the implementation is "switching" the base color with the tint color and alpha/luminance is kept as is. Solid blue would become solid red, solid red would stay red, semi transparent blue would become semi transparent red, semi transparent red would stay semi transparent red and so on...

    My wish is following actually:

    Nevertheless I would be happy with the most simple solution - I don't see anything speaking against exposing a flag to access the current state of the red shift mode (and the current shift color) and this would solve all issues because then everyone can adjust their code to achieve whatever someone wants to achieve.

    Alternatively using a tinting algorithm may be a good alternative solution as well but I don't know if garmin is open to changing something at that level and I even don't know what that would mean for garmins code so I assume that's something that won't happen - but this would go more in the direction "the system does everything and the developer does not need to know anything about it".

Children
No Data