Major graphical overhaul time

[TheMonsterFromTheDeep]

Welp! Looks like I screwed up.

Essentially, I need to reimplement all of my Module classes to use dirty rectangles when drawing so that everything is a lot faster.

This, of course, is going to require a major overhaul in the Module system.

Essentially, my plan is to make a way for Modules to essentially start drawing, and then those changes will be reflected in the parent, and everything will be re-drawn through dirty rectangles.

Actually -- Maybe all Modules just need a handle to an object where they can obtain a Graphics object with a particular dirty rectangle.

This, of course, will also prevent Container modules from needing to be re-drawn when their child Modules are drawn.

So I guess I'll do something simillarish to the Android API's lockCanvas() and unlockCanvasAndPost(). Each Module will have a handle to an object that is a handle to the Window sort of, and they will simply call a method to obtain a reference to the rectangle'd Graphics object. I'm not sure if I need to worry about thread safety yet.

[TheMonsterFromTheDeep]

OK - overhaul begun! I have come up with a rough plan of action. The entire Module system will be mostly moved to a new package called "module", which will simply be a full-fledged modular graphical framework. This framework contains a class called Window, which is the hook in to the Java window interface for the Module system. The vague class called Window right now will be renamed and will extend the new Module window.

The Module window will provide the necessary methods for Modules to perform graphical callbacks. I'm not quite sure what the retrieval method should be.

There is no clear path for a requested graphical object to be quickly returned, so a callback object will be used instead that contains a handle to the requested Graphics object and will be passed to the Window (or other graphical hook) when graphical interactions are required.

Hopefully I can create a nice-looking Java interface that graphically runs much better than the current mess so that I can easily join the new system with the old code while also creating a really nice interface for any future developments.

[TheMonsterFromTheDeep]

When building a new system, you never really realize how horribly awful it is until you have to implement it.

This new system is incredibly bad - it is almost impossible to use graphical callbacks for any serious graphical application.

Of course, when I was designing it, I had a nagging feeling in the back of my head that the code was rotten. And it turns out it is.

First, there is no guarantee that when a graphical callback is requested, it will actually do anything. It is in fact very likely that it will be overwritten - only one callback is tracked by the Window at a time.

It is also incredibly cumbersome to write graphical callbacks for every single little graphical function.

Thankfully, I regained my sanity and have come up with a new system that hopefully shouldn't take too long to build: Rather than having a buffer image for every single item, I will have one main buffer in the Window that is drawn to by every child Module. This will reduce memory usage of the program and should significantly speed it up.

[TheMonsterFromTheDeep]

Exciting! I haven't gotten everything to work yet, but I at least have the main system ideas down:

When a Module wants to redraw only a bit of stuff, it can request a handle with beginDraw() or beginDraw(rectangle coords). This method returns a GraphicsHandle [this may be renamed in the future] and the GraphicsHandle is used to draw all the things. The Module then calls then endDraw(GraphicsHandle g) method, passing back the original handle.

Hopefully this should be faster.

[TheMonsterFromTheDeep]

I am going to say that this is good enough.

I have plans to re-build the Editor class from the ground up as it is, because I feel like I have a better way to do something with the UI.