Do not require a BackgroundColor for UI images

[pablo-lua]

What problem does this solve or what need does it fill?

Actually, in order to use an image with Sprite or even UiImage, you are forced to use a BackgroundColor that is different from transparent, and that is misleading, can lead to one to think "well, I don't want an color in my Image, so I'll set it to transparent, right?" and then being confused because the image disappeared

What solution would you like?

The BackgroundColor, when being used with an image would apply an oppacity of determined color above the image. For example Rgb(255, 255, 0, 0.5) would taint the image slightly of yellow
but if one use Rgb(0, 0, 0, 1) the image would be tainted of black and the image itself would disappear (as alpha is 100%), leaving an black square on its place

What alternative(s) have you considered?

For that purpose, probably adding an child or something above the child with the desired color and leaving color in the background as Color::WHITE and leaving it as it is.

Additional context

• A possible problem that would appear from this is if one wants to make a image appear only a little, with alpha set to for example 0.5, that wouldn't be possible for that approach, and a possible solution to this is adding another component that specifies the Image oppacity

[alice-i-cecile]

The current design is quite confusing to me, as it conflates the background color with the tint of the image. IMO the node that stores the UI shouldn't have a background color by default: instead, it should have a distinct component / property that is used for tinting.

[benfrankel]

It would be nice to have a ColorTint component that applies color tint to an entire entity, including its Sprite, TextureAtlasSprite, Text, UiImage, etc. That would make certain animations easy to implement, like a fade away animation by tweening ColorTint's alpha from 1 to 0. The same animation code would automatically work for any visible entity.

The individual components probably still need their own color fields though, because you might want different colors for different aspects of the same entity. On that note, UiImage and UiTextureAtlasImage should probably have their own color fields too, which is what would replace the overloaded use of BackgroundColor in this issue.

[pablo-lua]

the ColorTint idea is good, like you said. would take the old function of BackgroundColor and would give the BackgroundColor another function that I hope would be more intuitive. Like I said in the issue, like applying an oppacity over the Image or something like that. In that case, the Color role in various bundles would change (Sprite would now have ColorTint and use the Color for another purpose)

[benfrankel]

Btw, BackgroundColor doesn't affect Sprites currently, it only tints UiImage and UiTextureAtlasImage (and for other UI nodes, it's the actual background color).

[pablo-lua]

Yeah, in the Sprite case I'm talking about the Color element, In the Sprite case and maybe others, the Color do the role of tint the image, what IMO is a little misleading too.

[benfrankel]

I'm gonna try to make a PR decoupling BackgroundColor from UiImage and UiTextureAtlasImage.

ColorTint can be a separate issue and a separate PR.

[benfrankel]

I guess unrelated to this issue, but I noticed another inconsistency. The Sprite, TextureAtlasSprite, and UiTextureAtlasImage components all rely on a separate component for their image handles (Handle<Image> or Handle<TextureAtlas>). But UiImage for some reason has its own field, UiImage::texture: Handle<Image>.

I'm not sure if there's a reason for this so I'm not gonna touch it.