Solid Color Textures Window and Color32ToInt #31
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Purpose of this PR
Add a utility window for finding textures which are only a single solid color.
Testing status
Tested while doing Quest optimization
Technical risk
Low -- adds functionality
Comments to reviewers
This was kind of a fun one! I often find myself in an optimization loop, identifying large textures in builds and trying to figure out which ones can be shrunk and by how much. Whenever I come across a solid color, I think:
It comes up often enough that I decided to build a tool! The Solid Color Texture window scans the project for solid color textures, lists them for you just like Missing Project References along with a list of unique colors with the textures grouped by color. It also includes a handy button to apply import settings to shrink the texture down to 32x32.
I still need to update the readme but I'll probably include the following image:

There are one or two future improvements to be made
AssetPreview.GetAssetPreview
to get a readable texture. Unfortunately, this texture will be 128x128 at a maximum, so it's possible that we would count a subtle enough texture as a solid color. It's a nice optimization, thoughThere's a cool trick that I use here which I'll try to call out in the readme as well. The
Color32ToInt
class gives us a "free" conversion fromColor32
toint
. The only performance cost of the conversion is writing to a struct field, which is very fast. This makes it much faster to compare two colors, which we do a lot here. I'm not sure whyColor32
doesn't just expose thisint
value because it does the same thing internally, but doesn't provide an equality comparer. Just that class on its own is a pretty powerful lesson to share in this repo.In case it's not clear what's going on from the comments and context: we define a struct which has two fields of a different type in the same location. Thus, setting either of these fields will write to the same memory location, so it will in practice "overwrite" the other field. If you write to the
int
field, you can read that value back as aColor32
, splitting theint
into the 4 'byte' values. Conversely, if you write to theColor32
field, you can read back a singleint
which is equivalent to the 4byte
s concatenated together. You can do this for arrays, too. So if I wanted to just get the result ofGetPixels32
as anint[]
, I could use a similar class with anint[]
field and aColor32[]
field which both have theFieldOffset(0)
attribute. Note that you can't do this withColor
, as it uses 4 floats which are 32 bits each.