I quickly want to write down my current thinkings about the next update of MonoGame.Forms.
I experienced that more and more people coming to MonoGame.Forms are struggeling to choose the right forms control to start with or rather how they are technically working or rather what I originally thought about the usage of such controls.
Basically you have two different controls you can inherit from. They are the DrawWindow and UpdateWindow.
The naming of these controls is unprecisely today, because originally MonoGame.Forms worked differently. I overhauled the whole work flow / editing experience of this library, but never changed the naming of classes like them.
So, I plan to rename them to "InvalidationControl" (DrawWindow) and "MonoGameControl" (UpdateWindow) in the next update.
Simply because it's exactly like that: it's a control meant to do your own custom invalidations as soon as you have changes to commit.
This special control is very performant, because it only needs your CPU power this single time it gets invalidated by YOU (after the output is drawn to the surface, it consumes 0% CPU).
You would typically use it like that (example TileMap editing):
- Move MouseCursor to InvalidationControl
- Place a tile in the control view
- Call Invalidate(); on this control
- Output gets rendered to the surface
- Job is done - no CPU usage
This is exactly like the DrawWindow works today, but with the difference that the property AutomaticInvalidation is turned on by default. This leeds to slow downs and not reacting user interfaces anymore, because of the massive (automatic) invalidations taking place.
However it turned out that most of the people just want to "jump start" into the editing experience MonoGame.Forms has to offer without worring about the invalidations or even CPU usage.
Simply because it has the complete "Initialize / Update / Draw"-concept instead of the InvalidationControl, which becomes updated through invalidations. This control is bit like "shoot and forget". You just inherit from this control in your custom class, override the corresponding functions, don't need to worry about invalidations or performance and just be a happy editor!
That's why I will rename the controls in question. The user will surly take the MonoGameControl instead of the InvalidationControl, because if in doubt what the InvalidationControl should be, he would take a look at the GitHub wiki how this control works. On top of it I will also change the xml commentary of this class to make this information clearly available in code.
In the demo project I showed how to use AutomaticInvalidation togehter with a DrawWindow, but i'm thinking of making this option unavailable for a DrawWindow. At least it will be turned off by default in the next update.
Hope this will make using this library more easy and innovative.
Thanks for reading!