The ImageView contains an opaque bitmap (the rendered score) using RGB 565 which dramatically reduces memory usage versus using ARGB8888. Most scores don't actually have transparent backgrounds though - they have solid white. So rendering the path under the ImageView would result in no blending occurring at all. It's a good thought though, but I think the real issue here is the Android framework. If you use the PorterDuffXferMode with MULTIPLY, and you render to a hardware accelerated canvas using a path, it's going to generate that black background. This seems to be a known issue, and the answer is always to use a non-hardware accelerated canvas backed by a bitmap to draw the stuff you want to blend.
Due to the way the Windows 10 rendering framework works (where every thing you want to render has to be an individual framework element unless you use directX to render the 2D stuff yourself), I do not have a solution for how to blend highlights with the rendered score to put the highlight behind. Either I'd have to implement some very crazy code to modify the rendered bitmap itself and blend the pixels (essentially duplicating the rendering code used by frameworks like skia/cairo), or I'd have to switch my entire rendering engine to DirectX, which would probably be a nightmare and would take endless months to get everything working properly again.
Mike
Due to the way the Windows 10 rendering framework works (where every thing you want to render has to be an individual framework element unless you use directX to render the 2D stuff yourself), I do not have a solution for how to blend highlights with the rendered score to put the highlight behind. Either I'd have to implement some very crazy code to modify the rendered bitmap itself and blend the pixels (essentially duplicating the rendering code used by frameworks like skia/cairo), or I'd have to switch my entire rendering engine to DirectX, which would probably be a nightmare and would take endless months to get everything working properly again.
Mike