FreeLists / haiku-appserver / [haiku-appserver] Re: (new) Haiku coder?

[Stephan Assmus <superstippi@xxxxxx>]

Hi Adi,

sorry for being so quite after your initial welcome... :-)

IMHO, the task list for app_server is something like this:

* create B_CMAP8 & B_CMAP16 versions of the "pixel formats"
  implementing the different blending modes in the AGG backend

see src/servers/app/drawing/painter/drawing_modes. The easiest will be to 
have a switch statement in Painter to use the correct pipeline for the 
pixel format of the current buffer. (and have all three pipelines ready)

--------------------------------------------------------------------

* give every WindowLayer it's own DrawingEngine/Painter instance

Currently, every (onscreen) window uses the same default Painter instance, 
and the concurrency is handled by the HWInterface read/write lock (used as 
write lock only when accessed through DrawingEngine)

It also means that HWInterface needs a listener interface, to which any 
number of DrawingEngines can be attached, and they all get informed when 
the buffer changes (SetDisplayMode()) and such stuff.

----------------------------------------------------------------

* introduce a "caching" implementation for the display buffer when
  there are transparent overlays:

 - have a bitmap ready in the size of the display buffer
 - maintain a region where transparent overlays are visible on screen
        (mouse cursor, transparent drag bitmap, drag rect)
 - make sure that this region in the bitmap contains the same contents
   as the display buffer (but as seen without the overlays!)
 - maintain a "valid" region (which region of the bitmap contains the
   same data as the display buffer, ie is up to date)

and here it comes: when drawing something to the display buffer:

 - split the current clipping region for the display buffer:
   a) substract the region with transparent overlays -> draw the
      remaining part to the display region directly
     - substract this region from the clean region of the cache
   b) draw the remaining part of the drawing command into the
      cache bitmap (temporarily attach the Painter to the cache):
     - overlay_region & remaining_clipping_region - clean_region
       = region that needs to be transfered from display buffer to
         cache bitmap before drawing
     - drawing in the cache bitmap
     - add that area to the clean region
     - transfer to the display buffer with *on the fly* merging
       of any transparent overlays (use a temporary buffer if necessary)

The result will be ficker free rendering of transparent overlays. Drawing 
something underneath a transparent overlay will not mean the overlay has to 
be removed first (because the real drawing happens in a buffer in which the 
overlay is not visible). It also means that the "dirty" region of the cache 
bitmap will never intersect the region with transparent overlays. (Because 
befor such an overlay is created, the cache will be updated, and from there 
on, all actual drawing happens in the cache, so it stays always valid). 

What it will also make possible:

BView::SetDoubleBuffering(uint32 flags);

... like what Dano already has. A double buffered view simply draws to the 
cache bitmap first. When Draw() is done, the cached area is flushed to the 
display area.

------------------------------------------------------------------

* look over the entire app_server code base and see where floating point 
coords don't make sense. The floating point stuff makes sense only for 
drawing commands, nothing else.


---------------------------------------------------------------------

Well. That's pretty much my personal TODO/wish list for our app_server. :-) 
Is there anything among these items that interests you?

Best regards,
-Stephan