PicturePlayer: update debug strings

Change-Id: I64a7dead30b8f484b63ba4d8055d93c626447755

BPicture: add fill rule support

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

BPicture: add gradient support

Fixes #9680.

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

PicturePlayer: use BStackOrHeapArray

Change-Id: I7908d8304276d14782bde5c2b8c089f3ca0138e2
Reviewed-on: https://review.haiku-os.org/c/haiku/+/2894
Reviewed-by: waddlesplash <waddlesplash@gmail.com>

Interface: Add casts to memcpy/memset invocations on BPoint & BRect.

Their copy constructors are exactly what GCC would generate,
but we can't remove them because doing so would make them
trivially copyable, and so they would be passed in registers
on x86_64, an ABI breakage.

So instead we have to add explicit casts to void* here.

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>

try to fix gcc5 build on buildbot.

* I'd only reproduce the kernel build failure locally, weird.

BView: add methods for affine translation/scaling/rotation

* BView::TranslateBy(), BView::ScaleBy() and BView::RotateBy()
allow to conveniently modify the current affine transformation.
This makes it unnecessary to first read the current transform,
modify it, and then set it again.
Uses the new Pre...() methods of BAffineTransform.

* Also, remove setting the transform "through" to the BView even
while recording a BPicture, as this now results in transforms
being applied more than once.

app_server/Interface Kit: add new clipping API

* Add new clipping API for rectangles (ClipToRect, ClipToInverseRect)
and shapes (ClipToShape, ClipToInverseShape)

* Works with affine transforms and automatically switches from fast
region-based clipping to alpha-mask based clipping as necessary.

* Always self-intersecting, i.e. no state push required to further
narrow down the clipping region. All of the 4 new methods can be
mixed in any order.

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 PicturePlayer dummy function table

* With the support for BAffineTransform, it needs to have 49 entries

Implement ClipToPicture inside a BPicture. Not working yet.
BView::ClipToPicture doesn't work anymore, when nested inside a BPicture,
This happened when its implementation was moved server-side.

PicturePlayer: Rework to be more safe against corrupted data.

This introduces a more sane API (currently private) that allows for
safer and possibly more efficient implementations:

* It uses a struct of named and typed function pointers instead of just
a void pointer array. This adds type safety to the callbacks so the
compiler can figure out if things match up before subtle bugs get
introduced.
* It provides bounds for all strings/buffers passed to the callbacks.
* It uses const references instead of implicitly copying arguments.
* It folds stroke_x/fill_x pairs into draw_x functions with a fill
argument to reduce the amount of functions needed.
* It uses unsigned values where negative values make no sense.

The old API has been implemented on top of the new one using adapter
functions. It makes copies of all data passed to the callbacks which
effectively keeps the picture data from being modified. This matches
with the R5 behaviour.

This also reimplements the buffer parsing to be safe against corrupted
data by validating that the types actually fit in the provided sizes
and buffers (using a templated reader).

Since this class is used from the app_server with user provided data,
making it more safe is important even though it comes with a slight
overhead (replicating R5 behaviour, i.e. crashing the app_server when
corrupted data is fed, doesn't seem very appropriate here).

Added WIP support for affine transformations to BViews.

Everything untested, but compiles, so it must work. The idea is to introduce
BAffineTransform additionally to the existing Origin and Scale properties of
BViews. One may use it in parallel or as an alternative. Painter in app_server
is not yet aware of the additional transformation. It is however already used
to transform drawing coordinates. It probably needs to work differently,
perhaps only in Painter and AGGTextRenderer.

Some build fixes for DEBUG=1.

Revert "Fixed type mismatch in picture data."

This reverts commit 81aad168f87486149f6e4ce8acc43e3e7a5de9e1.

Fixed type mismatch in picture data.

The size of an operation block was written as size_t by PictureDataWriter
but read as int32 by PicturePlayer. Fixes an app_server crash.

* fixed build in DEBUG mode

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

Fixed memcpy in case a smaller function table is provided. Improved readability of the SET_CLIPPING_RECT op block.

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

Moved the dummy table local to the PicturePlayer::Play() function since,
as Marcus pointed out, having it outside wasn't thread safe. Moved
PicturePlayer into the BPrivate namespace.


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

fix gcc4 build


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

Debug was enabled by default.


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

Added some debug output to PicturePlayer. Since checking the table size for every op is very slow, now we do that only at the beginning, and use a custom op table if needed. The best case (which is the one used when drawing a picture with BView::DrawPicture()) is very fast since it only requires one check.

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

Implemented SetClipping op, but it's not working yet (looks like it's
never written into the data stream)


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

Removed a no longer true TODO


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21944 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

My last commit broke setting fonts in BPictures. Added a comment in
PicturePlayer to explain what we need to do. Don't write the
B_PIC_ENTER_STATE_CHANGE and B_PIC_ENTER_FONT_STATE ops until we fix the
problem (we don't care about them in our server side
implementation anyway). Font changes and state syncing work again.


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

Implement more bpicture font methods, now PicturePlayer checks the size
of the function table, so if someone passes a smaller table, we avoid

calling invalid pointers.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21939 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

Added "const" to many parameters.
Removed most data allocations/copying from PicturePlayer, ServerPicture now has to do this when converting coordinates.
Added additional functions to ViewLayer to copy&convert multiple BPoint, BRect, BRegion to Screen coordinates, those should be further optimized.
Removed some function call overhead.
Note: some functions of PicturePlayer don't appear to be implented by PictureDataWriter,


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

forgot this file



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19380 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

and there it goes, the usual untested last minute change which breaks
the build...


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

our BPicture stream format wasn't compatible with R5 one.
Hopefully fixed all the problems. Reported by
Marc Flerackers.


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

patch by Lucasz Zemczak which adds BShape drawing support to BPicture. Actually we should use a ShapeIterator subclass (like Lucasz did here) in Painter too instead of having duplicating code.

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

delete -> delete[]

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

updated headers


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

renamed TPicture.cpp to PicturePlayer.cpp


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

Implement ClipToPicture inside a BPicture. Not working yet.
BView::ClipToPicture doesn't work anymore, when nested inside a BPicture,
This happened when its implementation was moved server-side.

PicturePlayer: Rework to be more safe against corrupted data.

This introduces a more sane API (currently private) that allows for
safer and possibly more efficient implementations:

* It uses a struct of named and typed function pointers instead of just
a void pointer array. This adds type safety to the callbacks so the
compiler can figure out if things match up before subtle bugs get
introduced.
* It provides bounds for all strings/buffers passed to the callbacks.
* It uses const references instead of implicitly copying arguments.
* It folds stroke_x/fill_x pairs into draw_x functions with a fill
argument to reduce the amount of functions needed.
* It uses unsigned values where negative values make no sense.

The old API has been implemented on top of the new one using adapter
functions. It makes copies of all data passed to the callbacks which
effectively keeps the picture data from being modified. This matches
with the R5 behaviour.

This also reimplements the buffer parsing to be safe against corrupted
data by validating that the types actually fit in the provided sizes
and buffers (using a templated reader).

Since this class is used from the app_server with user provided data,
making it more safe is important even though it comes with a slight
overhead (replicating R5 behaviour, i.e. crashing the app_server when
corrupted data is fed, doesn't seem very appropriate here).

Added WIP support for affine transformations to BViews.

Everything untested, but compiles, so it must work. The idea is to introduce
BAffineTransform additionally to the existing Origin and Scale properties of
BViews. One may use it in parallel or as an alternative. Painter in app_server
is not yet aware of the additional transformation. It is however already used
to transform drawing coordinates. It probably needs to work differently,
perhaps only in Painter and AGGTextRenderer.

Some build fixes for DEBUG=1.

Revert "Fixed type mismatch in picture data."

This reverts commit 81aad168f87486149f6e4ce8acc43e3e7a5de9e1.

Fixed type mismatch in picture data.

The size of an operation block was written as size_t by PictureDataWriter
but read as int32 by PicturePlayer. Fixes an app_server crash.

* fixed build in DEBUG mode

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

Fixed memcpy in case a smaller function table is provided. Improved readability of the SET_CLIPPING_RECT op block.

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

Moved the dummy table local to the PicturePlayer::Play() function since,
as Marcus pointed out, having it outside wasn't thread safe. Moved
PicturePlayer into the BPrivate namespace.


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

fix gcc4 build


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

Debug was enabled by default.


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

Added some debug output to PicturePlayer. Since checking the table size for every op is very slow, now we do that only at the beginning, and use a custom op table if needed. The best case (which is the one used when drawing a picture with BView::DrawPicture()) is very fast since it only requires one check.

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

Implemented SetClipping op, but it's not working yet (looks like it's
never written into the data stream)


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

Removed a no longer true TODO


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21944 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

My last commit broke setting fonts in BPictures. Added a comment in
PicturePlayer to explain what we need to do. Don't write the
B_PIC_ENTER_STATE_CHANGE and B_PIC_ENTER_FONT_STATE ops until we fix the
problem (we don't care about them in our server side
implementation anyway). Font changes and state syncing work again.


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

Implement more bpicture font methods, now PicturePlayer checks the size
of the function table, so if someone passes a smaller table, we avoid

calling invalid pointers.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21939 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

Added "const" to many parameters.
Removed most data allocations/copying from PicturePlayer, ServerPicture now has to do this when converting coordinates.
Added additional functions to ViewLayer to copy&convert multiple BPoint, BRect, BRegion to Screen coordinates, those should be further optimized.
Removed some function call overhead.
Note: some functions of PicturePlayer don't appear to be implented by PictureDataWriter,


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

forgot this file



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19380 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

and there it goes, the usual untested last minute change which breaks
the build...


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

our BPicture stream format wasn't compatible with R5 one.
Hopefully fixed all the problems. Reported by
Marc Flerackers.


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

patch by Lucasz Zemczak which adds BShape drawing support to BPicture. Actually we should use a ShapeIterator subclass (like Lucasz did here) in Painter too instead of having duplicating code.

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

delete -> delete[]

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

updated headers


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

renamed TPicture.cpp to PicturePlayer.cpp


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