Write a console that does not flush gfx buffers

[ian-h-chamberlain]

@Meziu @AzureMarker

The default libctru console calls gfxFlushBuffers whenever it prints a \n or \r character, which is normally useful since its output will be visible immediately.

However, I have a use case where I'd like to print concurrently from multiple threads, and manage flushing of the graphics buffer myself at the end of the frame. I noticed that the gfxFlushBuffers seemed to cause a deadlock when run concurrently from multiple threads – perhaps a bug in the underlying implementation?

In any case, this PR hacks together a variation on Console that works basically the same as the default one, but does not flush the buffers. Even without fully understanding the deadlock issue I mentioned, I think this could be useful as most programs should probably only flush once per frame anyway: https://libctru.devkitpro.org/gfx_8h.html#aea1808bd74fe0c00f9794e455fc8499b
I'm hoping this will make the console usable as a debug tool on one screen while rendering / doing other stuff with the other one.

The implementation does feel a bit hacky, though, so if you have suggestions or think we shouldn't merge this, please let me know. I thought this seemed a bit easier than writing a full-blown console from scratch, anyway.

[Meziu]

I would avoid this approach. What we could do instead is actually re-write the console, as it looks like a buggy mess of a thing and doesn’t support functionality important to our environment (comes to mind the UTF-8 support missing and the scroll effect). I wonder how hard it would be, though it’d also make switching Consoles and such much easier and safe via Rust.

[AzureMarker]

In terms of rewriting Console, we should at least keep the libctru console available and have our own version in addition to it. Or, make it a separate library, since this crate is supposed to just be a nice wrapper around libctru.

[Meziu]

In terms of rewriting Console, we should at least keep the libctru console available and have our own version in addition to it. Or, make it a separate library, since this crate is supposed to just be a nice wrapper around libctru.

It depends on how good of a job we do 😜.
Still, I haven’t yet looked at how the console renders the text, is it CPU or GPU based

Edit: CPU based, as expected. Weird no one tried making it with the GPU (faster, better) but it’s such an old artifact I don’t believe anyone would try touching it.

[ian-h-chamberlain]

I'm not entirely opposed to writing a new console implementation in Rust (lifetime stuff might still be tricky, as we found with ctru::console). It seems there are a handful of libraries we might be able to use for font rendering and stuff, which might make it easier to implement and give some nice features (and maybe GPU rendering).

My thinking though is that any decent-sized graphical project probably needs to implement font rendering anyway, at which point you might as well implement the console (or similar) in-app?

I basically wrote this (hack) just to unblock myself and get a non-blocking debug console, so I don't think we need to merge it, but just thought I'd pose it as a possibility in case others ran into this same problem.

---

Edit: CPU based, as expected. Weird no one tried making it with the GPU (faster, better) but it’s such an old artifact I don’t believe anyone would try touching it.

I have seen some old forum posts basically saying "don't use the console for anything other than basic prototyping etc" because it's broken and/or not very robust. The devkitPro devs seem to suggest using proper font rendering for anything more serious e.g. https://libctru.devkitpro.org/graphics_2printing_2system-font_2source_2main_8c-example.html

[Meziu]

Yeah citro2d has built-in GPU font-rendering, so I guess that would be the best choice. It is still weird that such a useful part of libctru isn't recommended, but aight.

[ian-h-chamberlain]

Guess I'll close this since I have started work on a completely custom console instead, and this is kind of a hack anyway.