[glass] Canvas2D Support

[ohowe1]

Very in-progress PR. Currently only have lines in Java done and there are currently a few hacks.

If someone would be able to look over the structure of everything before I work on the other drawing types and C++, that would be much appreciated.

myRobot stuff will be removed once dev for this is done.

[ohowe1]

@PeterJohnson Before starting to implement C++, do you have any other types you'd like included?

[PeterJohnson]

Text and image are the main things that's missing that were discussed in the issue. Unfortunately, with the struct based approach, strings are challenging to support unless you have an arbitrary maximum string length (e.g. 16-20 characters).

[ohowe1]

A possible workaround for the elements with non-constant set sizes is to maybe have another topic serve as a database that the Canvas2DText/Image struct references. What do you think about this?

[PeterJohnson]

How do you reference it? You can't do something like a string array with numeric indicies because of slicing (out of order updates). I actually don't think a fixed string limitation is that limiting--it might need a bit more work on the dashboard side to e.g. map short font names to system fonts (which we probably want anyway). The actual string limit to the user for text might be more of a constraint, but even there, you can only fit so much text in one line on the screen anyway--if it's something like 32 or 64 characters that should meet almost all use cases.

[ohowe1]

Ok, if it isn't two limiting, a set max length sounds good for the string. For images, though, what do you think about this as having a set size would likely be a bit more limiting (and possibly resource-wasteful):

Canvas2DTexture myCoolImage = new Canvas2DTexture("myCoolImage", textureData);

void draw() {
    canvas2d.drawTexture(myCoolImage, x, y, ...);
    canvas2d.finishFrame();
}

The texture struct that also holds the drawn position would hold an identifier given to the myCoolImage. The data for myCoolImage would be held in NT similar to how a FieldObject2d is with its own topic as it would not change much (and likely have the lifetime of the entire robot program).

[PeterJohnson]

My original thought for images is a relatively short image name (8-16 characters?). The source for that image would be either a folder on the dashboard side or (potentially) a separate topic in NT if we want to enable it to be sourced from the robot code (or the dashboard could even fetch it via FTP from the Rio's deploy folder, rather than it being via NT).

[ohowe1]

Ok, I'll probably just start off with on dashboard side, then.

[ohowe1]

/format

[ohowe1]

@PeterJohnson
Currently what's left for this is

• 2D Texture, I'll try to work on this but the amount of time I have has been pretty dwindled by college apps which will likely continue till kickoff :(
• Warning on large text passed to CanvasText2D, should this throw something? or silently truncate? or warn somehow?
• Struct Database access in the sim GUI. The NT provider lives in the HALSimGUI, which is initialized before the NetworkTablesSimGui where the model is and the current place for the struct DB. How do you think this should be addressed?