Common: Write PNGs in two steps to allow Unicode target paths.

[AdmiralCurtiss]

Fixes writes to paths with non-ASCII characters, as discussed after the merge in #9289.

[iwubcode]

So, writing to memory and then to a file seems slower. Is it? If so, I wonder if it'd make sense to somehow determine if we are using a unicode pathes and then take this slower approach (but if ascii write directly to file?).

[AdmiralCurtiss]

In theory yes, in practice who really cares, fileio is slow enough as-is. I doubt it makes a noticeable difference.

[JosJuice]

If we want something that's more similar speed-wise to what master does, we could use png_set_write_fn to set a callback with which libpng can write directly to an IOFile. I don't know if it would be more or less complicated than what this PR does, but at least I prefer it over maintaining two different code paths.

[AdmiralCurtiss]

I don't think you can use png_set_write_fn in combination with the simplified API. We could use png_image_write_to_stdio but that requires a raw FILE* which I would also like to avoid. Meh.

[smurf3tte]

I'm curious. What is your reasoning for avoiding png_image_write_to_stdio? I believe it would collapse this PR down to just 4 new lines and 1 changed line:

  File::IOFile file;
  file.Open(path, "wb");
  if (!file)
    return false;
  png_image_write_to_stdio(&png, file.GetHandle(), 0, input, stride, nullptr);

[AdmiralCurtiss]

It's the file.GetHandle() part. I have a long-term plan of switching the internals of IOFile to use the Win32 API instead of C-style file handles on Windows, see eg. #9023, so we can gain the advantages of that without having two separate file handling classes.

Though I suppose it might really be better to just use png_image_write_to_stdio here and then think about the other part when we get to that...

[lioncash]

I agree that it likely Just Doesn't Matter That Much and that this is fine to avoid the usage of GetHandle() on IOFile. This can always be revisited if it becomes an issue/hotspot

[smurf3tte]

It's the file.GetHandle() part. I have a long-term plan of switching the internals of IOFile to use the Win32 API instead of C-style file handles on Windows, see eg. #9023, so we can gain the advantages of that without having two separate file handling classes.

Though I suppose it might really be better to just use png_image_write_to_stdio here and then think about the other part when we get to that...

I think there are other ways to accomplish what #9023 is doing. It's possible to get the Win32 HANDLE from a file descriptor (FILE*) and it's also possible to construct a file descriptor around a HANDLE (which is what fopen() does). I agree that maintaining parallel file wrappers is something to be avoided.

[smurf3tte]

This... doesn't have anything to do with ASCII, as I understand it. It's about the active Windows code page not being UTF-8, which is what Dolphin operates in exclusively. libpng is just calling fopen on the string that is passed in.

Edit: perhaps this was a bit of an overstatement on my part. ASCII is related, in that it contains the subset of UTF-8 encoded characters that will work without this fix.