Get app_server working on x86_64.

With this commit, app_server now compiles and runs at boot! Nothing
particularly interesting happens, just the blue background and a mouse
pointer. Remote backends are broken and not compiled in, see #8834.
Note that it won't be possible to build this quite yet, need to get
the FreeType package uploaded.

Begun to use structs for the BView<->app_server communication. This makes
the protocoll less prone to errors, reduces possible points of failure and
most importantly, reduces the number of function calls to the link API.
I only know the numbers for StrokeLine(), which I tested via the Benchmark
test app. With this change, drawing random colored and positioned lines
actually doubled in speed. On the BView side, the calls to
ServerLink::Attach() only halfed, while on the app_server side, the number
of calls to ServerLink::Read() is now 1/4th. It will also be worth
investigating why the link stuff is so slow at all. I also optimized
BView::DrawString() a lot in this change, but I don't have any numbers
yet. Some other commands which used multiple Attach()/Read() calls were
also optimized, at least the most important ones. Begin/EndLineArray() was
also pretty bad on the app_server side.


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

Make BView::PopState() (executed at least on every call to Draw()) a lot
cheaper by preventing to rebuild the clipping on the app_server side.
I think this was commented out, because user clipping was broken until
some point and I forgot to reenable it after I fixed it. At least I cannot
spot any regressions when running with this patch now would I expect to
see regressions, since DrawStates do not mess with the screen clipping,
unless they get a clipping region assigned when the (user) clipping changes
during the state's life time.


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

The scale of a state does not influence the origin. Only previous states
and their origin and scale influences the current state's origin, since
they can be regarded as within the parent state's coordinate system.


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

* push the states on the server instead on the client side
* DrawState::SetOrigin needs to take the view scaling into account
* set the orgin in BPrintJob, to be able to print more then one page properly

Note: This would make printing work on HAIKU as on BeOS, but still it does
not because of 1; BPortLink size limit and 2; because we can only print/ draw
the visible region of a view? I had to resize StyledEdit to a i.e 10000
to test and to be able to print the full syslog.



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

A test app revealed some bugs with regards to client provided clipping regions:
* It is necessary to store the local origin and scale of a view state, at
least for the clipping region and especially because the scale affects the
clipping region. Ie origin and scale of one state affect the clipping region,
at the time the clipping is evaluated, ie
SetOrigin(...);
ConstrainClippingRegion(...);
is equivalent to
ConstrainClippingRegion(...);
SetOrigin(...);
The current client provided clipping region at the time of PushState()
always constrains the region of the new state. The previous region
and the current local clipping may have their own individual origin and
scale.
To support all this, I needed to store origin and scale of each state on
the stack, but I do cache the combined origin and scale. Caching only
the combined region is not possible though. So the new implementation
is slower than the previous, but more correct.
* Refactored "copy constructor" from DrawState, which is not really a copy
constructor anyways, made it private. It is only used by PushState().
* Removed some dead code from DrawState.

All this improves Firefox redraw issues a tiny bit, but does not fix them.
Either I am not covering Firefox needs with my test app, or the bug is
somewhere else. At least Haiku behaves like BeOS with regard to client
clipping regions and the state stack now...


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

* get rid of RGBColor usage where it is not needed, this simplified many things,
possibly making them a little faster too
* mess with decorator button size calculation to make the whole layout scale
more agreeable with the font size (no more fixed offsets/insets), but it
is work in progress
* DefaultDecorator no longer allocated the border color array, it is part of
the object now
* small memory footprint optimizations in ViewLayer, Decorator and WindowLayer


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

Bug fixes:
* origin is given in "outer" coordinate system therefore if there is a
previous state it has to be transformed. Please review if this is
required in OffsetOrigin() too.
* in Transform() we have to scale relative to the view origin not (0 /
0).

- optimized SetScale: saved one division


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

* added a way to get the unscaled pensize (ie that of the current draw state
of a view)


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

* implemented "false bold" for text rendering. It is a new property
of BFont. You can BFont::SetFalseBoldWidth(float) a width on a
BFont object, and it will cause the glyph shapes to be run through
an AGG "contour converter" so that they become thicker or thinner.
IIRC, this is commonly referred to as "false bold". The "width" value
is the distance in pixels that the new glyph outline will be offset
from the original outline.

It would be nice if someone could look at my change to View.h with
regards to the B_FONT_ALL flag.


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

minor clean up

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

Quick build fix, Stippi, can you review this?


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

actually add the converted rects to the region

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

* when the client constrained the clipping on a view, the server used to
take an empty region as an indication to remove the clipping, but on R5,
this is actually valid... this patch fixes the problem
* the ViewState::clipping_region is now consistently used to memorize
the user defined clipping of the view state instead of being sometimes
used to cache the current view clipping


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

fixes origin and scale handling, it behaves mostly like R5 now (it is used for drawing only, yes not mouse coords or anything else). Also fixes offscreen layers clipping rebuilding when the user defined clipping is added or changed

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

we write family and style as an uint32, so we should read it as an uint32 too

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

the current clipping is the combined user defined clipping from all previous states

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

* origin in DrawState is now the summed up origin, when setting it,
use the origin from the previous state as a start
* this fixes scrolling again (minus redrawing too much stuff,
this is left for Adi :-)


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

default to B_MITER_JOIN too

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

Fixed scale calculation. The scaling is still ignored for the drawing coordinations.


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

Merged DrawData and LayerData to one class DrawState.
Removed that ambiguous second copy constructor and moved push state functionality
into a separate PushState() method.


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

Get app_server working on x86_64.

With this commit, app_server now compiles and runs at boot! Nothing
particularly interesting happens, just the blue background and a mouse
pointer. Remote backends are broken and not compiled in, see #8834.
Note that it won't be possible to build this quite yet, need to get
the FreeType package uploaded.

Begun to use structs for the BView<->app_server communication. This makes
the protocoll less prone to errors, reduces possible points of failure and
most importantly, reduces the number of function calls to the link API.
I only know the numbers for StrokeLine(), which I tested via the Benchmark
test app. With this change, drawing random colored and positioned lines
actually doubled in speed. On the BView side, the calls to
ServerLink::Attach() only halfed, while on the app_server side, the number
of calls to ServerLink::Read() is now 1/4th. It will also be worth
investigating why the link stuff is so slow at all. I also optimized
BView::DrawString() a lot in this change, but I don't have any numbers
yet. Some other commands which used multiple Attach()/Read() calls were
also optimized, at least the most important ones. Begin/EndLineArray() was
also pretty bad on the app_server side.


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

Make BView::PopState() (executed at least on every call to Draw()) a lot
cheaper by preventing to rebuild the clipping on the app_server side.
I think this was commented out, because user clipping was broken until
some point and I forgot to reenable it after I fixed it. At least I cannot
spot any regressions when running with this patch now would I expect to
see regressions, since DrawStates do not mess with the screen clipping,
unless they get a clipping region assigned when the (user) clipping changes
during the state's life time.


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

The scale of a state does not influence the origin. Only previous states
and their origin and scale influences the current state's origin, since
they can be regarded as within the parent state's coordinate system.


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

* push the states on the server instead on the client side
* DrawState::SetOrigin needs to take the view scaling into account
* set the orgin in BPrintJob, to be able to print more then one page properly

Note: This would make printing work on HAIKU as on BeOS, but still it does
not because of 1; BPortLink size limit and 2; because we can only print/ draw
the visible region of a view? I had to resize StyledEdit to a i.e 10000
to test and to be able to print the full syslog.



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

A test app revealed some bugs with regards to client provided clipping regions:
* It is necessary to store the local origin and scale of a view state, at
least for the clipping region and especially because the scale affects the
clipping region. Ie origin and scale of one state affect the clipping region,
at the time the clipping is evaluated, ie
SetOrigin(...);
ConstrainClippingRegion(...);
is equivalent to
ConstrainClippingRegion(...);
SetOrigin(...);
The current client provided clipping region at the time of PushState()
always constrains the region of the new state. The previous region
and the current local clipping may have their own individual origin and
scale.
To support all this, I needed to store origin and scale of each state on
the stack, but I do cache the combined origin and scale. Caching only
the combined region is not possible though. So the new implementation
is slower than the previous, but more correct.
* Refactored "copy constructor" from DrawState, which is not really a copy
constructor anyways, made it private. It is only used by PushState().
* Removed some dead code from DrawState.

All this improves Firefox redraw issues a tiny bit, but does not fix them.
Either I am not covering Firefox needs with my test app, or the bug is
somewhere else. At least Haiku behaves like BeOS with regard to client
clipping regions and the state stack now...


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

* get rid of RGBColor usage where it is not needed, this simplified many things,
possibly making them a little faster too
* mess with decorator button size calculation to make the whole layout scale
more agreeable with the font size (no more fixed offsets/insets), but it
is work in progress
* DefaultDecorator no longer allocated the border color array, it is part of
the object now
* small memory footprint optimizations in ViewLayer, Decorator and WindowLayer


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

Bug fixes:
* origin is given in "outer" coordinate system therefore if there is a
previous state it has to be transformed. Please review if this is
required in OffsetOrigin() too.
* in Transform() we have to scale relative to the view origin not (0 /
0).

- optimized SetScale: saved one division


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

* added a way to get the unscaled pensize (ie that of the current draw state
of a view)


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

* implemented "false bold" for text rendering. It is a new property
of BFont. You can BFont::SetFalseBoldWidth(float) a width on a
BFont object, and it will cause the glyph shapes to be run through
an AGG "contour converter" so that they become thicker or thinner.
IIRC, this is commonly referred to as "false bold". The "width" value
is the distance in pixels that the new glyph outline will be offset
from the original outline.

It would be nice if someone could look at my change to View.h with
regards to the B_FONT_ALL flag.


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

minor clean up

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

Quick build fix, Stippi, can you review this?


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

actually add the converted rects to the region

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

* when the client constrained the clipping on a view, the server used to
take an empty region as an indication to remove the clipping, but on R5,
this is actually valid... this patch fixes the problem
* the ViewState::clipping_region is now consistently used to memorize
the user defined clipping of the view state instead of being sometimes
used to cache the current view clipping


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

fixes origin and scale handling, it behaves mostly like R5 now (it is used for drawing only, yes not mouse coords or anything else). Also fixes offscreen layers clipping rebuilding when the user defined clipping is added or changed

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

we write family and style as an uint32, so we should read it as an uint32 too

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

the current clipping is the combined user defined clipping from all previous states

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

* origin in DrawState is now the summed up origin, when setting it,
use the origin from the previous state as a start
* this fixes scrolling again (minus redrawing too much stuff,
this is left for Adi :-)


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

default to B_MITER_JOIN too

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

Fixed scale calculation. The scaling is still ignored for the drawing coordinations.


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

Merged DrawData and LayerData to one class DrawState.
Removed that ambiguous second copy constructor and moved push state functionality
into a separate PushState() method.


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