Doing thing right - I hope

Brought CompositeEngine.h more inline with app_server and fixed numerous little errors (I hate USB keyboards...).

Changed UpdateQueue into HWUpdateQueue and created a new UpdateQueue as, basically, an interface class.
Created CompositeUpdateQueue to act as a final-gathering place for areas in the back-buffer which need to be copied to the front buffer.

Begin fleshing out CompositingPerfmon.

Verified clean build status, have not verified run-time sanity, though there should be no effects at this point other than a slightly larger binary.
Finally a working man's commit...

Much future planning (immediate future...), app_server communication protocol setup started, fixed a few things, changed some more, yadda yadda.

All compiles, but will not link.  That is intentional (lets me know where I am going next in case I forget to add a note to my TODO).
Major commit

Re-oriented ComositeEngine scrap pieces from CAFE::RenderEngine, namely removing performance modes - as these aren't likely needed int the limited role in the app_server.
If anything, the app_server will only need three modes: slow(5hz), 60hz, @refresh, which is better handled with SetSlowMode() and SetUpdateEveryRefresh().

Moved special accessors to CompositingPrivate.  Prepared app_server port communication, implemented some BWindow changes (SetDrawingMode()), prepare for special
full-screen modes to prevent unneeded updates from the back coming forward.

Created WindowBuffer, which will be atttached to a Painter with a new method to render the buffer directly, which is attached to a standard RenderEngine, which will be generated by
the CompsiteHWInterface.  WindowBuffer will collect updated rects and the CompositeEngine will prioritize updates front-to-back, ceasing updates when a new frame is to be renderred
- but not before completing updates for any active WindowBuffer.

While WindowBuffer is active with the CompositeEngine, the client will be unable to make drawing changes, so we will push as many threads to each WindowBuffer as possible, with each
dirty rect possibly being handled by a separate thread/core and unlock that WindowBuffer as quickly as possible.
Adding needed funcitonality to Window:

Ability to use WindowBuffer (for compositing OR caching).

Bring numerous other objects in line with changes.

Take into account requirements for hardware acceleration.

CompositeHWInterface is now an AccelerantHWInterface.

Trying to limit requirements in the future for acceleration.

NOTE:  the build will not link at this point, still on purpose...
Implement some missing functions.

Found some lacking areas, and implemented missing WindowBuffer functions.

CompositeEngine is only hold-up until link success.
Various tidbits.
Message Handling

Setup message handling for compositing.

The CompositeEngine will handle all of its own requests.

This is merely a prelude before setting up a route around ServerApp to expediate communications.

Purpose being that some messages will undoubtedly be very time sensitive... and having all handling code in one place is quite nice.

Began changes and made first runs of modified app_server (without incident, but no regression testing-yet).

app_server now builds.

Modified binaries thus far: libbe.so, app_server
Bug fixes

Test run with compositing enabled to trace down bugs.  Found several - as expected.
Adapt view to local buffer coordinates for drawing.

Hoping this way works - it did eliminate all segment violations up to the Desktop bitmap draw, so we are no longer overunning the buffers it would seem...

This is being kept as its own commit so it can be easily undone later, or referenced.
Working out the kinks...

As we are now much more sensitive to writing outside of a View's bounds, we have to make adjustments...

I believe I will be making Painter more aware of it's buffer's limitations, and to act accordingly to prevent segment violations.

At this point, app_server can run in compositing mode, though nothing is painted on the screen.  However, with very little effort (just clicking around) we find
ourselves with a segment violation in Window SeetDrawingBuffer(), IIRC...  next commit ;-)
Re-orienting to mixed-compositing (temporarily)

Removed Window::SetDrawingMode in preference to the original B_RENDER_COMPOSITE window flag.
The app_server internals make so many assumptions that drawing is occuring directly in the screen coordinate space that I am having surprising difficulty getting even a single
Window to draw into its own WindowBuffer without some code blasting past the boundaries (and thus crashing).

Decorators now draw directly into the screen buffer, but will soon be rewritten to draw into the  over-provisioned WindowBuffers of their 'owning' windows.

Currently, using the app_server without compositing enabled is going to be fruitless, and compositing still defaults to disabled, so don't expect to build a usable app_server -
though it does build without issue.

Modified View to use ConvertForDrawing instead of ConvertToScreenForDrawing.  The functions are still very rudimentary, will be cloned in WindowBuffer, and the View functions will
call into WindowBuffer to ascertain the proper drawing area.

Further, the disconnect of DrawingEngine and its owner must be dissolved.  And Painter with its buffer...

Both must be made aware of their drawing space so they do no attempt to write outside of it, but intelligently clip their drawing.  Each with their own degree of agressiveness and
reaction.
Assorted tidbits

Found chicken/egg problem in Window constructor which was causing problems.  Things are much better now.

Decided against using UpdateQueue in preference to dual BRegion for the WindowBuffer.  Window's UpdateSession may be used instead when I get further along.

Decorators are very confused as to dirty regions, but I am preparing to over-provision WindowBuffer to optimize resize performance and to permit room to draw the decorator directly
into the WindowBuffer.

Clipping will prevent window content spill-over, but decorators will be able to draw over the window (but should avoid it, naturally).

Decorator changes are coming soon - the order of initialization may change radically - but it may not...
Re-orientation to new model...

-Decided to change the methodology for View's ConvertForDrawing() to convert up through the parents all of the way to the window.  The window then does the final conversion based
upon its type:

	Window: converts drawing to screen coordinate space
	OffscreenWindow: does no further conversion
	CompositeWindow: converts to WindowBuffer coordinate space

	(Others will inherit the behavior from Window, but I will investigate the need to override such behavior.)

-Virtualized many functions in Window to facilitate a functional CompositeWindow typee so as to keep the code paths separate.

-Making first steps to have WindowBuffer stay alive even after a Window's Quit() or destruction until all referencing objects have adapted or been destroyed.
	WindowBuffer is now a BReferenceable & only BReference<WindowBuffer> will be passed around.
	TODO: DrawingEngine will manually call AcquireReference() and ReleaseReference() if casting to WindowBuffer succeeds.
		Why: this greatly simplifies locking, and also permits lazy-recycling of allocated buffer spaces in the future.

I believe all other changes are in-ine with the abovee.

This will not build.  Will probably spout out many many errors.

Will certainly not link ;-)
Moving Along

Further implementing CompositeWindow.

Re-wrote WindowBuffer's _ResizeTo() function with tested & working code.

Compiles, will not link.  Much work to go.
Bug fix, misc...
Fixes

Non-compositing mode now mostly works properly again.

There are probably a few bugs here and there, but they should be minor(or obvious).

Ran into an interesting situation where View::ConvertToWindow() somehow converts all of the way to the screen, which makes no sense... somewhere the drawing instructions are being
converted from window coordinates to screen coordinates - and I can't find it...

I checked in both View.cpp files (src/kits, and src/servers/app), ServerWindow (which receives the drawing messages from BView), and the ConvertToParent() code to try and solve this
dilemma.  I even had ever single view spout out its frame to make sure the view attached to the window had an origin of (0,0) - and they all did...

Next commit will hopefully solve this...
Bug fix

Figured out the problem with View::ConvertForDrawing(*) - ConvertToParent when there is no parent results in an undesired result (though it seems like it shouldn't do anything.. the
frame should be (0,0,rt, bt).
Continuing progress.

CompositeHWInterface taking over for AccelratedHWInterface.

CompositeWindow taking over for Window (for non-offscren windows only).

Temporary B_RENDER_COMPOSITE flag being utilized to force a single window into compositing for testing.

Logging levels reduced to eliminate tested code-paths.  Further reductions forth-coming.

DrawingEngine now capable of having a RenderingBuffer manually set via its public API. RenderingBuffer now capable of being aware of such changes to augment lazy-allocation
techniques - or other uses (such as knowing when we are no longer being modified...).

Builds.  Runs.  Works.  Drawing doesn't seem to be re-routed to set RenderingBuffer, so there is some logging in place to trace that issue...
Bug fixes & more prep-work

WindowBuffer:
	fWindowFrame was not being updated.
	Over-provisioning was being added at the wrong time - thereby not bein applied at all.
	Cleaned up the code and removed interim window frame as the window frame must change for each and every resize event.

CompositeWindow
	Setup to use a new method to temporarily mark a test window as compositing.

Decorator:
	Preparing to drastically change how drawing is handled in Decorator.
	Will implement BView-style drawing interfaces, and hide much of the tedium.
	This is important as a Decorator may draw in foreign coordinate systems - such as WindowBuffer's.
	All frames and drawing will be relative to the window frame.
	Move events will need to be blocked entirely from a custom decorator's awareness.

app_server builds & runs.  An odd memory leak is still occuring in relation, I believe, to WindowBuffer... which is an odd situation... after WindowBuffer is destroyed, some RAM
seems to not be returned to the system.  Will need to chase this down.
Correct oversight.

WindowBuffer was meant to hold its largest size in both dimensions, but any time a new max was achieved in either dimension it'd lose the other dimension's previous setting.

This commit resolves this.

On a side note:  verified performance increase of other commits in non-compositing mode.  Slightly faster than anticipated.