app_server memory management fixes: use BReference

Use BReference for more automated reference counting in app_server,
fixing some use-after-free and other problems.

Extracted from https://review.haiku-os.org/c/haiku/+/2695

Change-Id: I141bb248229405896b29feff3338447f7257b0b4
Reviewed-on: https://review.haiku-os.org/c/haiku/+/3175
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>

ServerPicture:SyncState(): sync with Canvas instead of View
When the canvas api was introduced, ServerPicture was changed to work with Canvas,but this was not updated.

Change-Id: I37c68111f4a60408768656260bfc73a27f1f65f4
Reviewed-on: https://review.haiku-os.org/c/501
Reviewed-by: Stephan Aßmus <superstippi@gmx.de>

Fix some cases of updating draw state while recording a BPicture

* Also implemented recording DrawString(string, length,
BPoint[] locations), which was previously not recorded at all.
* Also implemented playing back recently added drawing commands
in PicturePlayer.cpp. I don't quite understand what this is
actually used for, but it seemed it was forgotten. I just followed
the pattern already established in the code.
* The other important bit in this change is to update the pen
location when it is needed while recording a BPicture. Often
the BView will use PenLocation() in order to transmit drawing
commands to the app_server which use absolute coordinates only.
This isn't actually so nice, since it means the client has to
wait for the server to transmit the current pen location. If there
were dedicated link-commands for pen-relative drawing commands,
the client could just keep sending without waiting for the server.
In any case, the app_server needs to update the pen location in
the current DrawState and even the DrawingEngine even while
recording a picture, because some next command may need up-2-date
state information, such as the font state and the pen location.
* I have not yet tried to find /all/ instances where the DrawState
needs to be updated while recording. This change should repair
/all/ font state changes, all versions of drawing a string, and
all versions of StrokeLine().

Change-Id: Ia0f23e7b1cd058f70f76a5849acb2d02e0f0da09
Reviewed-on: https://review.haiku-os.org/c/817
Reviewed-by: Stephan Aßmus <superstippi@gmx.de>

app_server: add new BView layers API

* Add new methods
BView::BeginLayer(uint8 opacity)
BView::EndLayer()

* All drawing between begin and end of a layer is redirected onto an
intermediate bitmap. When ending the layer, this bitmap is
composited onto the view with the opacity given when the layer was
started.

* Layers can be nested arbitrarily and will be blended onto each
other in order. There can also be any arbitrary interleaving of
layer begin/end and drawing operations.

* Internally, drawing commands are redirected into a BPicture between
BeginLayer and EndLayer (but client code need not know or care
about this). Client code can also start/end other BPictures while
inside a layer.

* Uses the PictureBoundingBoxPlayer to determine the size of the
layer bitmap before allocating and drawing into it, so it does not
allocate more memory than necessary and -- more importantly -- it
will not alpha-composite more pixels than necessary.

* Drawing mode is always set to B_OP_ALPHA, blend mode to
(B_PIXEL_ALPHA, B_ALPHA_COMPOSITE) while inside layers. This is
necessary for (a) correct compositing output and (b) for
redirection of drawing into the intermediate bitmap, which uses the
renderer_region offset (in B_OP_COPY, the Painter does not use the
AGG renderer methods, it directly accesses the pixel data. This
would access out-of-bounds without the offset, so B_OP_COPY cannot
be allowed.)
To ensure these modes aren't changed, BView::SetDrawingMode()
and BView::SetBlendingMode() are ignored while inside a layer.

* The main motivation behind this new API is WebKit, which internally
expects such a layers functionality to be present. A performant and
reusable implementation of this functionality can only be done
server-side in app_server.

app_server: fix ServerPicture::SyncState pen size

* Should use the unscaled pen size here because we also write down
the current scale, and we don't want to scale the pen twice.

app_server: rename DrawingContext to Canvas

* Better reflects the purpose of the class: an interface for things
in which we can draw (e.g. a View)

* Accordingly rename OffscreenContext to OffscreenCanvas

Introduce DrawingContext View superclass

In order to properly implement ClipToPicture in BView, we need to render
a Picture to a Bitmap. This is currently done client-side, but the
overhead for this (creating a BBitmap that accepts views, including a
window thread, adding a view to it, and rendering the picture to the
view, then sending the result to app_server) isn't acceptable. Moreover,
the bitmap drawn this way is clipped to the view size, and the clipping
won't work when the view is scaled or translated. So, we need to move
the Bitmap creation server-side.

However, app_server currently have no means of doing this. Factor out the
relevant parts of View: a DrawingState stack with PushState/PopState, a
DrawingEngine, and a ConvertToScreen transformation. Another implementation
of the DrawingContext will allow us to also draw a picture directly using
a Painter and low-level pixel buffer, in a format suitable for use as an
AGG alpha mask.

* AppendPicture() and RemovePicture() are weird, since
the ServerPicture calls those itself from SetOwner().
Since there are asserts in ServerPicture about fOwner,
it was easiest to fix the code by using *only* SetOwner()
from within ServerApp to add or remove pictures.
* SetOwner() was broken, since it called a method which
potentially removed the last reference and then still
accessed memory of the now free'd ServerPicture instance.
The easiest fix is to just increase the reference count
temporarily.
* SetOwner() wrongly returned false when the new owner was NULL.
* NestPicture() should simply add it's own reference. There
are two places where it is called, and only one of them
added the extra reference. The other one only acquired the
implicit reference that the ServerApp owns, but pictures
that remove nested children remove a reference from them.
This could leave stale pointers around of course.
* Added more asserts about fOwner.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38484 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Fixed race conditions in the server's bitmap/picture handling: the objects
are now removed from the maps as soon as the client deletes them. This also
makes the "client reference" mechanism superfluous I introduced earlier.
* ServerApp::SetCurrentCursor() must always call Desktop::SetCursor(), since it
is also called whenever the current application changes. This fixes the cursor
almost never changing.
* Renamed ServerPicture::Usurp()/StepDown() to PushPicture(), and PopPicture().
* Also, they now acquire a reference to the picture in question (ie. the picture
you get from PopPicture() also owns a reference you need to free).
* ServerApp::CreatePicture() may fail, too. This case is now handled in the code
that calls it.
* Previously, the ServerWindow tried to process up to 70 messages in one go.
That obviously caused bug #4709. Now, we have the additional requirement to
not hold the desktop lock for longer than 25 ms. I haven't tested it with
Kaleidoscope yet, though.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35472 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Bitmaps and pictures now maintain their client reference independently;
clients can no longer release more references than they own.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34130 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Use BReferenceable instead of Referenceable. Didn't notice there was a
BReferenceable in the first place, thanks Ingo!


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33880 a95241bf-73f2-0310-859d-f6bbb57e9c96

* ServerApp's bitmap and picture handling was completely broken, as it ignored
concurrency as well as reference counting, causing occasional crashes and
memory corruption.
* ServerPicture now subclasses Referenceable, and will notify its owner when
it's going to be deleted. This might bring some regressions, although I
couldn't spot anything wrong yet.
* ServerBitmap will now also notify its owner when it's going to be deleted as
well.
* Switched from the former picture/bitmap lists to a std::map. This also solves
the issue of not checking whether or not the bitmap/picture actually belongs
to the ServerApp (before, all apps could access and delete all
pictures/bitmaps)
* Introduced a new fMapLocker that guards the new maps.
* ServerWindow now uses GetBitmap()/GetPicture(), and gives up its reference
after use.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33876 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Coding style cleanup.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33871 a95241bf-73f2-0310-859d-f6bbb57e9c96

* CID 1012: Fix leaking the OffsetFile in case it fails to initialize.
* Use std::nothrow (the rest of the file already used it).
* We also have to keep the source file around and properly dispose it, as
OffsetFile doesn't take ownership of it.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27486 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Got rid of the "Layer" part of WindowLayer, ViewLayer, WorkspacesLayer
(now WorkspacesView), OffscreenWindowLayer.
* Renamed ServerScreen.cpp/h to Screen.cpp/h (the class was already called
Screen).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24303 a95241bf-73f2-0310-859d-f6bbb57e9c96

Implement calling the exit_xxx hooks. Thanks to Marc Flerackers for the
help.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21943 a95241bf-73f2-0310-859d-f6bbb57e9c96

Also set the font properties for BPictures. Some of them, at least.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21938 a95241bf-73f2-0310-859d-f6bbb57e9c96

Implemented the following BPicture ops: fill region, stroke/fill arc,
stroke/fill polygon, stroke/fill bezier. some work towards drawing of
nested pictures.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21918 a95241bf-73f2-0310-859d-f6bbb57e9c96

ServerPicture now uses a BPositionIO object as internal storage instead
of BMallocIO. Added an additional constructor to handle a file. This is
in preparation of implementing BView::SetDiskMode().


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20996 a95241bf-73f2-0310-859d-f6bbb57e9c96

When creating a picture with data, the app_server was writing beyond the
allocated memory, without telling anyone. That was causing bad things to
happen. Flattening and unflattening BPictures now works, and
consequently, printing works too. Bug #1014 is fixed.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20285 a95241bf-73f2-0310-859d-f6bbb57e9c96

Moved picture data writing to its own class, thus simplifying code in
various places. Implemented SetLineMode op for BPicture, fixed shape
drawing (I accidentally broke it in the previous commit).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19264 a95241bf-73f2-0310-859d-f6bbb57e9c96

Added a copy constructor to ServerPicture. ServerPicture's constructors are private now, and can be called only from ServerApp (friend). Changed BList to a stl::stack which is better suited as a stack... Changed ServerApp::CreatePicture() to accept a picture to clone, instead of passing back a token which was never used anyway.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15840 a95241bf-73f2-0310-859d-f6bbb57e9c96

Replace our current ServerPicture implementation with the one from Marc Flerackers. Currently it doesn't do anything as I commented out or removed most code, but it shows what we need to do

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15807 a95241bf-73f2-0310-859d-f6bbb57e9c96

* the app_server now uses a global token space - this should later be changed to
have different token spaces depending on the scope of its objects.
* removed TokenHandler - we're now using BTokenSpace instead.
* removed unused IPoint.cpp - if we ever need it again, it can still easily be
resurrected from the dead.
* some cleanup.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14925 a95241bf-73f2-0310-859d-f6bbb57e9c96

Moved app_server files to app/.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@11972 a95241bf-73f2-0310-859d-f6bbb57e9c96

Introduce DrawingContext View superclass

In order to properly implement ClipToPicture in BView, we need to render
a Picture to a Bitmap. This is currently done client-side, but the
overhead for this (creating a BBitmap that accepts views, including a
window thread, adding a view to it, and rendering the picture to the
view, then sending the result to app_server) isn't acceptable. Moreover,
the bitmap drawn this way is clipped to the view size, and the clipping
won't work when the view is scaled or translated. So, we need to move
the Bitmap creation server-side.

However, app_server currently have no means of doing this. Factor out the
relevant parts of View: a DrawingState stack with PushState/PopState, a
DrawingEngine, and a ConvertToScreen transformation. Another implementation
of the DrawingContext will allow us to also draw a picture directly using
a Painter and low-level pixel buffer, in a format suitable for use as an
AGG alpha mask.

* AppendPicture() and RemovePicture() are weird, since
the ServerPicture calls those itself from SetOwner().
Since there are asserts in ServerPicture about fOwner,
it was easiest to fix the code by using *only* SetOwner()
from within ServerApp to add or remove pictures.
* SetOwner() was broken, since it called a method which
potentially removed the last reference and then still
accessed memory of the now free'd ServerPicture instance.
The easiest fix is to just increase the reference count
temporarily.
* SetOwner() wrongly returned false when the new owner was NULL.
* NestPicture() should simply add it's own reference. There
are two places where it is called, and only one of them
added the extra reference. The other one only acquired the
implicit reference that the ServerApp owns, but pictures
that remove nested children remove a reference from them.
This could leave stale pointers around of course.
* Added more asserts about fOwner.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38484 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Fixed race conditions in the server's bitmap/picture handling: the objects
are now removed from the maps as soon as the client deletes them. This also
makes the "client reference" mechanism superfluous I introduced earlier.
* ServerApp::SetCurrentCursor() must always call Desktop::SetCursor(), since it
is also called whenever the current application changes. This fixes the cursor
almost never changing.
* Renamed ServerPicture::Usurp()/StepDown() to PushPicture(), and PopPicture().
* Also, they now acquire a reference to the picture in question (ie. the picture
you get from PopPicture() also owns a reference you need to free).
* ServerApp::CreatePicture() may fail, too. This case is now handled in the code
that calls it.
* Previously, the ServerWindow tried to process up to 70 messages in one go.
That obviously caused bug #4709. Now, we have the additional requirement to
not hold the desktop lock for longer than 25 ms. I haven't tested it with
Kaleidoscope yet, though.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35472 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Bitmaps and pictures now maintain their client reference independently;
clients can no longer release more references than they own.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34130 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Use BReferenceable instead of Referenceable. Didn't notice there was a
BReferenceable in the first place, thanks Ingo!


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33880 a95241bf-73f2-0310-859d-f6bbb57e9c96

* ServerApp's bitmap and picture handling was completely broken, as it ignored
concurrency as well as reference counting, causing occasional crashes and
memory corruption.
* ServerPicture now subclasses Referenceable, and will notify its owner when
it's going to be deleted. This might bring some regressions, although I
couldn't spot anything wrong yet.
* ServerBitmap will now also notify its owner when it's going to be deleted as
well.
* Switched from the former picture/bitmap lists to a std::map. This also solves
the issue of not checking whether or not the bitmap/picture actually belongs
to the ServerApp (before, all apps could access and delete all
pictures/bitmaps)
* Introduced a new fMapLocker that guards the new maps.
* ServerWindow now uses GetBitmap()/GetPicture(), and gives up its reference
after use.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33876 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Coding style cleanup.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33871 a95241bf-73f2-0310-859d-f6bbb57e9c96

* CID 1012: Fix leaking the OffsetFile in case it fails to initialize.
* Use std::nothrow (the rest of the file already used it).
* We also have to keep the source file around and properly dispose it, as
OffsetFile doesn't take ownership of it.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27486 a95241bf-73f2-0310-859d-f6bbb57e9c96

* Got rid of the "Layer" part of WindowLayer, ViewLayer, WorkspacesLayer
(now WorkspacesView), OffscreenWindowLayer.
* Renamed ServerScreen.cpp/h to Screen.cpp/h (the class was already called
Screen).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24303 a95241bf-73f2-0310-859d-f6bbb57e9c96

Implement calling the exit_xxx hooks. Thanks to Marc Flerackers for the
help.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21943 a95241bf-73f2-0310-859d-f6bbb57e9c96

Also set the font properties for BPictures. Some of them, at least.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21938 a95241bf-73f2-0310-859d-f6bbb57e9c96

Implemented the following BPicture ops: fill region, stroke/fill arc,
stroke/fill polygon, stroke/fill bezier. some work towards drawing of
nested pictures.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21918 a95241bf-73f2-0310-859d-f6bbb57e9c96

ServerPicture now uses a BPositionIO object as internal storage instead
of BMallocIO. Added an additional constructor to handle a file. This is
in preparation of implementing BView::SetDiskMode().


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20996 a95241bf-73f2-0310-859d-f6bbb57e9c96

When creating a picture with data, the app_server was writing beyond the
allocated memory, without telling anyone. That was causing bad things to
happen. Flattening and unflattening BPictures now works, and
consequently, printing works too. Bug #1014 is fixed.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20285 a95241bf-73f2-0310-859d-f6bbb57e9c96

Moved picture data writing to its own class, thus simplifying code in
various places. Implemented SetLineMode op for BPicture, fixed shape
drawing (I accidentally broke it in the previous commit).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19264 a95241bf-73f2-0310-859d-f6bbb57e9c96

Added a copy constructor to ServerPicture. ServerPicture's constructors are private now, and can be called only from ServerApp (friend). Changed BList to a stl::stack which is better suited as a stack... Changed ServerApp::CreatePicture() to accept a picture to clone, instead of passing back a token which was never used anyway.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15840 a95241bf-73f2-0310-859d-f6bbb57e9c96

Replace our current ServerPicture implementation with the one from Marc Flerackers. Currently it doesn't do anything as I commented out or removed most code, but it shows what we need to do

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15807 a95241bf-73f2-0310-859d-f6bbb57e9c96

* the app_server now uses a global token space - this should later be changed to
have different token spaces depending on the scope of its objects.
* removed TokenHandler - we're now using BTokenSpace instead.
* removed unused IPoint.cpp - if we ever need it again, it can still easily be
resurrected from the dead.
* some cleanup.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14925 a95241bf-73f2-0310-859d-f6bbb57e9c96

Moved app_server files to app/.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@11972 a95241bf-73f2-0310-859d-f6bbb57e9c96