Redraw the swing terminal on Canvas.paint().

[ghost]

Fixes #77.

This creates a private Canvas subclass that invokes an onPaint callback.

This also removes canvas.ignoreRepaint = true.
I remember reading somewhere in the Swing docs (can't seem to find it now) that it recommended canvas.setIgnoreRepaint(true), but I believe this is only necessary for real-time rendering.
I'm not sure how zircon handles animations, as this library is still new to me, but it definitely doesn't render in real-time when there are no animations playing, so repainting is needed on some platforms.

Edit: Do you know if there's any other importance to ignoring repaint?

[adam-arold]

Pretty cool PR, thank you for your effort! So this just adds a callback which gets called from Swing? I guess it looks for an onPaint method?

[adam-arold]

You can use lateinit var onPaint: (() -> Unit) here so you don't have to bother with the nulls

[ghost]

Updated to use a lateinit reference to a SwingTerminal instead of a (() -> Unit)?.

[adam-arold]

Great thanks. I'll pull this out today and create a new PREVIEW version from it.

[ghost]

Thanks!

[adam-arold]

So I refactored it to have a default null value (like in your original commit) because it turned out that Swing calls this method before the field is initialized which leads to exceptions. 😆

[adam-arold]

You can find the new snapshot on jitpack.

[ghost]

It's funny how Swing was intended to hide all platform-specific nuances like this, but they're still popping up. On X11, Component.paint wouldn't be called until messages are explicitly processed in the main loop, but Windows uses a callback system where messages can be processed at any time. I didn't think about this when changing to lateinit.

[adam-arold]

Me neither. At least it is now tested on all major platforms. :) I was not able to reproduce the tearing you mentioned on Windows so I would have been completely oblivious to this bug.