[haiku-development] Re: app_server compositing

On 3/22/2012 16:55, Axel Dörfler wrote:

On 22.03.2012 01:36, Joseph Groover wrote:
You cannot use realloc() - but you can just use the existing backend for bitmaps. IIRC they are already aligned to some size, so you won't have to switch buffers too often when a window is resized. And even if, resizing is not happening that often.
You have to use a memory backend where it is save for the client to mess with everything, ie. the app_server must remain running even if all the client does is to fill all memory it gets with 'bee4'.
At first I didn't get why I couldn't modify MallocBuffer into a ResizingBuffer, allocate the memory with malloc(BytesPerRow() * fHeight) and realloc on resize. 

So much so that I already created it (completely untested)...
I did realize, of course, that the bitmap data would be worthless after realloc, but the same is true of swapping to a new buffer while resizing - or so I told myself ;-) Until I realized that the client determines what gets redrawn during / after a resize :") I copy out the old buffer to a new one, and redirect the Window's Painter to the new buffer, mark the old buffer for deletion and only delete it once the new buffer is Painted into the back buffer (so that the old buffer is around in case the data is needed before the resize draw completes on the client side). 

Or I am just totally missing something...
As such, I'd think it prudent to expose my current plans for the CompositeEngine to scrutiny:
I've been working on morphing CAFE::RenderEngine into CompositeEngine (the header anyway.. the actual code is by no means compatible - RenderEngine is part of a managed framework with ThreadGroups and timing mechanisms and the like...) so I have a nice starting point...
CompositeEngine will have an explicit constructor, a global gCompositeEngine pointer, and will instantiate itself (no reliance on order). It provides a listener interface and the common stuff of course.. plus:
One thread/core for rendering into the back-buffer (invalidating modified areas and painting the updates into the back-buffer). One master control thread (task assigner, tells which threads to handle which areas, coordinates state). One back-to-front copy thread, looping on a schedule based on performance_mode: 
        STOP_PERFORMANCE_MODE         = 0,    // screen off, low power mode
SLOW_PERFORMANCE_MODE = 5, // <= 5fps, target 5 fps - clock / caret MILD_PERFORMANCE_MODE = 15, // mild motion in multiple locations HIGH_PERFORMANCE_MODE = 30, // moderate motion, video, etc... FULL_PERFORMANCE_MODE = 60, // high motion (window dragging/resizing) SYNC_PERFORMANCE_MODE = 120, // update at refresh rate - up to 120hz WILD_PERFORMANCE_MODE = 1000 // update as fast as possible - up to 1000fps // must be set as an override
As you can see the modes are target frame rates, most of the time updates will only need to happen a few times a second. The thread will schedule an update check based on the performance mode and only copy to front when an update is required (naturally).
Performance modes can be set by request (from ServerWindow based on Invalidate() rate) or in response to certain scenarios (when a resize or move begins, we enter FULL_PERFORMANCE_MODE or SYNC_PERFORMANCE_MODE and drop down in stages towards SLOW_PERFORMANCE_MODE, reducing the dirty region check rate - we escalate upwards quickly, down "slowly" because the update check itself is a very minimal test, but there MAY be a lock contention issue if we check too often which could cause schedule violations).
The purpose of all that is to help have updates batched. The master control thread orchestrates the back-buffer update (via the (hopefully)multiple threads) right after the front buffer is updated and the back-to-front copy thread must wait until the master control threads releases its hold on the back-buffer. The clients, naturally, update at-will as they do now. A client must be complete with their drawing in order for an update to occur for them. To give the best possible chance of that being the case the back-render threads will skip over updates including locked windows, adding them to the end of the update queue the control thread is servicing permitting more tries to gain a lock on the buffer to copy it into the back-buffer before the next scheduled back-to-front copy. The control thread will stop servicing updates as quickly as possible once the back-to-front copy thread has requested read access to the back-buffer, it will begin servicing them again after the back-to-front copy has completed.
Once that is all working, I will investigate the possible need to give certain updates priority (since it will just be a matter of sorting the update queue. I will also look into merging updates and providing a double-buffering facility to the full window (not an individual BView as in Dano)... but that is a low priority. 

Please let me know if I'm messing up somewhere in the theory ;-)
I'm off to give each Window a buffer to pass to their Painter... not sure of the state of test_app_server... if you have any hints, PLEASE let me know ;-) Otherwise I'll be running two instances of VMware - one on each monitor, one for testing, one for developing... both running Haiku of course - will have to try on real hardware later when I build a few test machines. 

--The loon

Other related posts: