[haiku-appserver] current app_server tasks, new region format

  • From: Stephan Assmus <superstippi@xxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Thu, 30 Nov 2006 12:42:37 +1300

Hi,

in reply to myself, I just want to make sure no one works on the same stuff 
in parallel...

> --------------------------------------------------------------------
> 
> * 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.

I have currently done this locally, and it seems to work fine, except for 
some concurrency problems with the cursor overlay.... which is the reason 
why I started...

> ----------------------------------------------------------------
> 
> * 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)
[8<]

...working on the above thing, starting with extracting the software cursor 
handling into its own class.

> ------------------------------------------------------------------
> 
> * 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.

This is mostly done now for ViewLayer. I have not looked into WindowLayer 
yet.

---

Overall, the speed ups caused by parallel frame buffer access and integer 
view layout are not as I would have hoped. The only bottle neck now (with 
regards to locking) is the global font lock. I don't want to tackle this one 
just yet.

But since a little while, I'm rolling a new idea in my head, for a different 
way to represent update regions. I'm quickly going to outline my ideas, 
maybe some one has some insights:

I think the region calculations for update region tracking (intersecting, 
adding, removing rects...) are too expensive for what we want to do. This 
might be because they are way too precise. Maybe a different representation 
of a region would be good: For example a bitfield (on/off) with one bit per 
8x8 pixel area. Think of it like a low resolution clipping region. Of 
course, operations like "intersection", "adding", "removing" rectangles are 
extremely fast (built into the CPU actually), and don't depend on the 
complexity of the region at all. This representation of an update region 
could be used for as long as the app_server is still tracking the dirty 
region of a window. When an update session begins, the region could be 
converted back to a normal BRegion, which probably isn't even that slow, 
provided we feed the rectangles to trigger the special cases inside the 
BRegion implementation (like extending the last rect if possible). What do 
you think?

Best regards,
-Stephan

Other related posts:

  • » [haiku-appserver] current app_server tasks, new region format