Would making it run at double speed solve the vblank issues? Or does it already do that anyway?
I don't remember if it does it by default (if it did the sound would be messed up), but no, this doesn't solve the issues. The problem isn't that the length of vblank was neglected by colorizer, but that the way colorizer tries to handle it is too naive - it just has a certain number of tiles that it updates each vblank, and you can adjust that number if it appears glitchy. However, the amount of time you have in vblank is often variable, depending on the amount of objects on the screen, where on the map you are, etc. The first way I tried to fix this was by just making it run until vblank ended, and do as many tiles as possible. This still didn't fix everything because an entirely different colorizer function was trying to read
from VRAM in order to update the color the tile will be set to in the next vblank. The problem with this is that you can only read from VRAM in vblank, so you have to apply a fix so this only happens in vblank, further slowing down the vblank handler. At this point I realized that a custom solution would be better, because colorizer just naively updates the map as often as it can, instead of only setting the color when the map has been scrolled for example. Similar problems exist with the sprites, but they are not as severe.
Anyway, I have a ton of notes on this that I might as well post, but I'm not on my computer that I have them on right now, so I'll have to post them later. I was considering making a successor to colorizer, but I'm thinking it'd be better to just have some assembly functions that can be copy pasted into the proper spots and modified to fit the game, along with a tutorial explaining how to do it. For any method to be truly universal (like colorizer tried to do), it would have to take a naive approach like colorizer did, and would run into similar problems with slowdown.