app_server: fix order of initialization

GCC 13 warns that the a pointer is taken from a member that according to the
rules is not yet initialized. Fix the declaration and order of initialization
to prevent us depending on undefined behavior.

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

Painter: change to a solid pattern for gradients

Gradients don't use patterns, but then some common drawing code makes
decisions based on them. Let's set the pattern to B_SOLID_HIGH so that
we get the expected result, in particular one that does not depend on
the last pattern used by a previous operation.

Fixes #18370.

Change-Id: I9d71c6d334d77be8fe4783a072b8df519486d74e
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6416
Reviewed-by: John Scipione <jscipione@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
Reviewed-by: Stephan Aßmus <superstippi@gmx.de>

PatternHandler: remove unused code

hrev17117 implemented B_OP_COPY with a special treatment for text.
hrev21929 introduced the color cache to speed up that text drawing.
hrev52753 removed the special treatment of text in B_OP_COPY, but left the
color cache and the text flag behind.

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

app_server: fix transformations in BPicture

Fixes #16122, #16147.

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

Revert "app_server: fix transformations in BPicture"

This reverts commit b8e5671d5318e59ad4e36f047940521d18d1f5ed.

Reason for revert: Broke all builds.

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

app_server: fix transformations in BPicture

Fixes #16122, #16147.

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

app_server Painter: refactoring, extract bitmap drawing

* Extract bitmap drawing from Painter into separate class
Painter::BitmapPainter. This will allow to add new optimized
drawing modes without making Painter larger.

* BitmapPainter itself is further decomposed into separate
(method object) structs per drawing mode (currently, those are:
generic, no scale, nearest neighbor, bilinear). New optimized
implementations can be added by writing additional method objects
and calling them from BitmapPainter.

* DrawBitmapNoScale and DrawBitmapBilinear are implemented using
CRTP. This removes the function pointer in the 'no scale' version,
which was previously used to select the row copy type. In the
bilinear version it untangles the three variants (default,
low filter ratio, SIMD) into separate methods.

* While BitmapPainter is a nested class in Painter, the specialized
method objects are not. Instead, the AGG-specific data fields from
Painter are moved into a new struct PainterAggInterface. This
struct is passed to the method objects and allows them to access
the Painter's AGG renderer/rasterizer/scanline containers/etc.

Alternatives would be to make all the involved structs friends
of Painter, or nesting them all, or exposing all of Painter's
internals via getter methods -- all of these would be quite messy.

The details of the bitmap painting implementations are
intentionally hidden from Painter: there is no need for it to
know about their internals -- it does not even know their type
names. (Nesting or making them friend would expose their type
names to Painter.)

Furthermore, there is another level of information hiding between
BitmapPainter and the DrawBitmap[...] method objects.
BitmapPainter itself only needs to decide that it uses e.g. the
bilinear version. It has no knowledge that DrawBitmapBilinear is
internally made out of several structs implementing specially
optimized versions.

* Refactoring only, no functional change intended. Performance
should be unaffected.

app_server: optional coordinate shifting in renderer_region

* agg::renderer_region gets an extra feature which allows to
optionally shift the coordinates by a specified offset.

* This allows to shift coordinates at the lowest level, even below
the transformations done by BAffineTransform (which happen in the
painter, right before rasterization).

Needed for layers support: shifts the origin of the layer bitmaps
to their position in the view while keeping all transformations
(BView origin/scale transforms as well as BAffineTransforms)
intact. The offset for the layer bitmaps within their parent view
is determined by the bounding box and is then fixed, it must not
be altered while the layer's BPicture is played into the bitmap.

If this offset were added to the BView origin or as translation in
the BAffineTransform, it would be further transformed by the BView
scale or the other affine transform parameters. Thus, we need
another low-level offset mechanism which is even below
BAffineTransform's transformations.

Draw radial gradients using the proper radius.

Follow-up fixes for FillRect+transforms

* Factor out AlignRect to avoid code duplication
* Give the right rectangle to the OverlayHider.

app_server: Update and use the fill rule in all cases.

* It was previously not used for gradient rendering.
* It was not updated when the DrawState was set.
* Not actually tested, yet.

app_server & interface kit: support fill rules.

* BView gets SetFillRule/FillRule methods. The fill rule is part of the
view state.
* The B_NONZERO rule is the default. This is what we implemented before.
* The B_EVEN_ODD rule is the other common possibility for this, and
we need to support it to help WebKit to render properly.

app_server: Fixed issues in Painter.

* DrawPolygon was offsetting coords to pixel centers
regardless of whether the polygon was stroked or
filled, leading to wrong results for filling. Now
it offsets for stroking only and even takes pen-size
into acount. The bug was visible in Gobe Productive's
selection rendering.
* Renamed _Transform() methods to _Align(), which fits
better with what they do: Align coordinates with the
pixel grid.
* Changed rounding behavior for StrokeLine. Offsetting
to pixel centers depending on pen-size happens regardless
of sub-pixel mode. This means a stroked line on integer
coordinates looks the same in both modes. It breaks
some drawing in WonderBrush (brush cursor), which was
exploiting the previous behavior, but unbreaks Gobe
Productive caret rendering at zoom levels below 150%.

Both changes bring Gobe Productive text editing to a useable
level.

app_server: Fix computing bounding boxes for transformed stuff.

* In DrawingEngine, clipping is computed before drawing happens. This did not
take into account when drawing primitives can now be transformed. Fixes
drawing glitches in the Transformation test when the round rect is scrolled
into view and it was previously prevented to draw.
* Fixed clipping rect computation for the sanitized StrokeRoundRect()
implementation which centers the stroke on the rect.

Painter: Support transformation in gradient code paths.

Clipping paths (or rather alpha masks) and affine view transformations
seem to be generally supported for all drawing operations now. There might
still be bugs that have not yet been exposed by the current set of tests.
These could be related to scrolling, origin and scale as well as stacked
view states.

Implemented using the transformation in Painter (incomplete)

* Also removed wonky BeOS rendering of stroked round rects and ellipses.
Nobody would expect it to work like this. This affects stroked round rects
and ellipsis with a pensize greater than 1.
* Refactored common code from _StrokePath() and _FillPath().
* _StrokePath() returned a curious bounding box that didn't take into
acount the miter width. Now the bounding box is computed from the actual
stroke conversion of the path.

app_server: Move AlphaMask management into DrawState.

* Give DrawState a real copy constructor, handle deriving in PushState().
(Although clipping region and alpha mask are not cloned, which is on the
other hand just what's needed for now.)
* Combining alpha masks from previous states is not yet handled.
* Remove SetAlphaMask() from DrawingEngine and Painter. It is now done in
SetDrawState().

Add Alpha Masking support in ClipToPicture

Use AGG to implement ClipToPicture in a faster and better way.
There are things missing in this initial implementation:
* No support for PushState/PopState saving and restoring the picture.
* No support for nested clipping through PushState
* The clipping doesn't happen where you expect it when using SetScale()
* There are artifacts when scrolling and resizing clipped views
* The implementation uses more memory than it needs, as the clipping
bitmap is stored as RGBA32, yet only the alpha channel is used
* The clipping bitmap is rendered more times than it needs to. We need
some caching here.

* Moved the SIMD code from AppServer.cpp to Painter.cpp where it is actually
needed. It might be best to put it into its own file, though.
* This is required in order to let our test environment work with the stricter
runtime_loader we have now.


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

Basically, this changeset implements BShape::ArcTo(). In more detail:
* Added BShape::ArcTo() and BShapeIterator::IterateArcTo(), using a previously
unused virtual slot. (Added the symbols for binary compatibility for GCC2
and GCC4.)
* Added operator=(), operator==() and operator!=() to BShape.
* Added BShape::BezierTo() version taking three points, which is sometimes
more convenient.
* Added the four new shape data ops OP_LARGE_ARC_TO_CW, OP_LARGE_ARC_TO_CCW,
OP_SMALL_ARC_TO_CW and OP_SMALL_ARC_TO_CCW. For a single arc, provided the
radius is large enough, there are four possibilities to draw the arc, these
are controlled by the two boolean flags to ArcTo() and mapped to the new
commands accordingly.
* Some style cleanup in Shape.cpp (sorry for mixing it up, but it gets
worse below...)
* Added ShapeTest to src/tests/servers/app.
* Changed the way BShapes are transformed from view to screen space in the
app_server. For arcs, it would be nontrivial to apply a proper transformation,
it's much easier to let AGG take care of it. This affects ServerPicture as
well.
* Wrapped iterating the BShape into try/catch blocks in ShapeIterator. But
I really don't understand the purpose of the class in the first place.
Maybe it can now be dropped, since coordinates don't have to be transformed
in place anymore.
* Refactored copy&paste shape iteration code in Painter. The transformation
to screen space happens there.
* Since RemoteDrawingEngine needed to be adopted anyway, I also updated
it for the new DrawString() with offsets version. But the client still needs
to be adapted.
* Style cleanup in Painter.h


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

* Extended the BView drawing API by a DrawString() version that takes an array
of locations, one for each glyph.
* Added a test for the new functionality.


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

Patch by Christian Packmann:
* Implemented a CPU feature detection function in AppServer.cpp.
The results are put into the global variable gAppServerSIMDFlags.
* Implemented an SIMD accelerated version of the bilinear bitmap
scaling code that is the backend of BView::DrawBitmap(...,
uint32 options) used by the MediaPlayer to smoothly upscale
movies when no video overlay is available. The speed up is very
noticable and a Core 2 Duo @ 1.8 GHz can play at 1920x1200 now
without breaking a sweat. There is currently one SIMD version
implemented which uses MMX and plain SSE.

Very cool! Thanks a lot!


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

Finished the optimization for vertical gradients. This code is about
8.3 times faster than using the AGG pipeline, but about 3 times slower
than drawing a solid color square. It can probably still be improved.
The second version of _MakeGradient() is more powerful than the old one
and should replace it. It handles some corner cases, which the other
one does not.


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

* Cleanup in the Gradient department. No fuctional change.
Renamed BGradient::color_step to BGradient::ColorStop
as it's called everywhere else. Also renamed BGradient::gradient_type
to just BGradient::Type. Renamed BGradient::Type() to GetType().
* Simplification of method names in Painter.cpp. Some not yet
complete and yet inactive code to accelerate vertical gradients
(bypassing AGG for this special case).


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

Patch by Artur Wyszynski:
* Implemented BGradient, BGradientLinear, BGradientRadial,
BGradientDiamond, BGradientConic and BGradientRadialFocus
new Interface Kit classes.
* Implemented all the (AGG-based) backend necessary in
the app_server to render gradients (Painter, DrawingEngine)
* app_server/View can convert a BGradient layout to screen
coordinates.
* Added BGradient methods of the Fill* methods in BView.
* Implemented a test app and added it to the image as a
demo.
* Adopted Icon-O-Matic and libs/icon in order to avoid
clashing with the new BGradient class. Re-use some
parts where possible.

Awesome work, Artur! Thanks a lot. Now a more modern
looking GUI has just become much easier to implement! :-)

TODO:
* Remove the need to have gradient type twice in the
app_server protocol.
* Refactor some parts of the patch to remove duplicated
code (Painter, DrawingEngine).
* Adopt the BPicture protocol to know about BGradients.
* Review some parts of the BArchivable implementation.


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

* When playing with the MediaPlayer and toggling bilinear versus
nearest neighbor scaling, I noticed that the bilinear version
actually used less CPU than the generic AGG code path with nn
scaling. So I wrote an optimized nn scaling routine for nn
based on the bilinear scaling code. So the indices into the
source bitmap are cached. I don't know if this is the optimal
nn scaling routine, but the CPU usage dropped significantly.
Only B_OP_COPY is optimized as of yet.
* Optimized the bilinear scaling. When more filtered pixels than
unfiltered pixels are anticipated, the loops are unrolled to
special case the very last row/column and bottom right pixel.
This eliminates the branches in the loops.
* Fixed a bug with partial scaled drawing of bitmaps when it
used the bilinear scaling, the bitmapShift was in the wrong
direction.


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

Patch by Andrej Spielmann (GSoC):
* Simplified the subpixel related methods for the AGG "pixel format" template
interface, the ones for the solid cover simply pass through the existing
methods, so only one subpixel blending function is left which does the actual
work (this removes a lot of the previously added code)
* Implemented a new rasterizer based on the original AGG rasterizer which
implements subpixel anti-aliasing for any generic AGG vector pipelines. It
is now optionally used in Painter and AGGTextRenderer (for vector fonts, ie
rotated, sheared or big enough fonts) depending on the global subpixel
setting.
* Put all subpixel variables into the new GlobalSubpixelSettings.h|cpp
* Simplified DesktopSettings related classes a bit and renamed previous
FontSubpixelAntialiasing to just SubpixelAntialiasing.
* The private libbe functions for subpixel related settings moved from Font.cpp
to InterfaceDefs.cpp where other such functions live. They are not related
to fonts only anymore.
* Removed the subpixel related settings again from the Fonts preflet and added
them to the Appearance preflet instead.

All of the above implements subpixel anti-aliasing on a global scale, which
to my knowledge no other OS is doing at the moment. Any vector rendering
can optionally use subpixel anti-aliasing in Haiku now. The bitmap cached fonts
are still affected by the Freetype complile time #define to enable the patented
subpixel rasterization (three times wide glyphs). Vector fonts and shapes are
not affected though at the moment.



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

* Implemented new BView drawing functions DrawBitmap[Async](
const BBitmap* bitmap, BRect bitmapRect, BRect viewRect, uint32 options).
Only option so far is B_FILTER_BITMAP_BILINEAR.
* BView::DrawBitmap[Async](const BBitmap* bitmap, BRect viewRect) was accessing
the bitmap pointer without checking it. Would therefore crash when passing
NULL, unlike the other methods.
* The BPicture code already reserved room for the BBitmap flags, but did not
store the actual flags and neiter use them for anything. Since the bitmap
data is stored anyways, the bitmap creation flags do not matter. So I reused
this for the new bitmap drawing options.
* Rewrote Bitmap.h and removed the B_BITMAP_SCALE_BILINEAR flag again.
* Tried to optimize Painter::_DrawBitmapBilinearCopy32() a little by giving
the compiler better hints. There seems to be a marginal, possibly imagined
speed increase < 0.05 ms. ;-)


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

Implemented an optimized version of bilinear scaled bitmap drawing for
B_OP_COPY which is about 2.4 times faster than the AGG version (but of
course less generic). The speed up is even better for smaller and even
scales.


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

* Introduced new BBitmap flag B_BITMAP_SCALE_BILINEAR.
* When drawing BBitmaps with scaling in the app_server, use a bilinear
filter when a bitmap has this flag set. (Hope nobody objects, otherwise
I can revert or improve this. Performance can certainly be improved, since
the AGG implementation is too generic. But that goes for the nearest
neighbor implementation as well.)
* Flags are uint32, fix app_server side code to declare them correctly. Use
appropriate link methods in BBitmap and ServerApp.
* Enable the BeOS compatibility mode for B_RGB32 (works just like B_RGBA32
in B_OP_ALPHA mode).


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

Patch by Andrej Spielmann (GSOC):
* Integrate the subpixel rendering with the existing drawing backend and
the font rendering.
* The font cache has got an additional rendering type for extracting and
caching glyph bitmaps that store subpixel coverage values.


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

When drawing bitmaps with B_OP_OVER with a color space that does not provide
an alpha channel of itself, we have to respect B_TRANSPARENT_MAGIC_* pixels
and properly make them transparent. We achive that now by just setting the
alpha to 0 in our converted B_RGBA32 bitmap for each pixel where there is a
B_TRANSPARENT_MAGIC_* pixel in the source. This is not really efficient, but
fixes missing images for example in NetPositive. They were treated as B_RGBA32
while they in fact were B_RGB32 and happened to have all alpha bits set to 0.

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

* track the fact if Painter is attached to a frame buffer, incorporate
this information in the fValidClipping flag... which should prevent
any drawing code to run if Painter is not attached properly


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

* fixed the crashing result of bug #634, check if the supplied region
falls within the frame buffer bounds. This should not happen, and
I am going to search for the cause next, but at least app_server
dosn't crash anymore in this context. Left a comment on my findings
so far.


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

* fractional rects need to be aligned if not drawing in subpixel precise mode,
by now, I feel there is too much code involved in this... I guess I should
really move this to stuff to ViewLayer::ConvertToScreenForDrawing()...


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

* this fixes the second part of #1426, unfortunately, the clipping checks
have become more expensive, so maybe it is better to do what I proposed
in the ticket comments, and move the rounding of drawing command coordinates
into ViewLayer::ConvertToTopForDrawing() instead of handling it in
DrawingEngine and Painter


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

* added a version of SetFont() that takes a DrawState* to DrawingEngine and
Painter, that is needed to be able to tell if anti-aliasing is to be used,
since the flags in the font can be overruled by the flags in the view...
* fixes aliased fonts reliably, tested with FontDemo


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

* after my last changes to font rendering, it was about 15% slower than
before (although there should be much less lock contention)
* with this change, there is quite a bit of cleanup, text drawing is now
about 20% faster than before the original changes to font caching,
mostly due to turning off the kerning feature, which at the moment
gives absolutely no benefit. The correct way of doing it might be to
use kerning depending on the provided glyph spacing mode
* removed fPenLocation from Painter, the usage should be more correct now,
since it is now consistently applied before the coordinate transformation
from view to screen (also for DrawShape() now, before any view scaling
and origin offset)
* Painter no longer has it's own instance of a ServerFont, instead it uses
its AGGTextRenderer instance, which was per Painter again after the
last change, and not global anymore, made _UpdateFont() useless
* When using GlyphLayoutEngine, it supports a second pass with the same
FontCacheEntry through the introduction of a FontCacheReference. This
speeds up DrawString a little, since it needs to calculate the bounding
box for the string, and then draw the string in a second pass. This is
now done with only one FontCacheEntry lookup
* I also tried to optimize the on-the-fly conversion of UTF8->CharCode away,
since it was done four times per DrawString, but surprisingly, it proofed
to be a slight slowdown.
* introduced a shortcut in DrawingEngine::DrawString() which avoids
calculating the bounding box, we are now a tiny bit faster to figure
out that we don't need to draw any string than Dano

In the test environment (drawing to offscreen bitmap and blitting to
screen eventually), text rendering is now about 3.7 times _faster_ than Dano
text rendering (directly to screen), for untransformed text. Unfortunately
I cannot test on the same machine in accelerant using version of the test
environment.


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

* complete overhaul of the font/glyph caching
* the previous AGG implementation is superfluous
* the new implementation is based on that one, but in a way that allows
read/write locking to the list of cache entries (fonts) as well as
read/write locking to the cached glyphs per individual font cache entry
* new GlyphLayoutEngine.h, which is to be the central place for layouting
glyphs along the baseline.
It handles the locking for getting the font cache entries.
It works by giving it a template class GlyphConsumer which does the
actual work.
* changed AGGTextRenderer to use the new font cache
* changed ServerFont::StringWidth(), and the bounding box stuff to use it
* changed DrawingEngine, it doesn't need the global font lock anymore
* our BFont thought that GetBoundingBoxesAsGlyphs and GetBoundingBoxesAsString
is the same, which of course it isn't, hence the two separate functions...
AsGlyphs just gets the bounding box of each glyph in a string, not treating
the string as an actual word
AsString adds the offset of the glyph in the word to the bounding box
* changed ServerProtocol.h accordingly for the different bounding box meaning


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

* completed my changes to DrawState handling, the current DrawingState
of the active ViewLayer is now always mirrored in the Painter instance
of a ServerWindow, so that it doesn't need to be synced on every drawing
command, this was previously incomplete for font handling
* removed the DrawState parameter from all the DrawingEngine functions
* adjusted ServerWindow and ServerPicture accordingly
* made sure that string related functions used by non-drawing related
parts (ServerApp, Decorator) don't interfere with the current drawing
state
* moved AS_SYNC handling from _DispatchViewMessage to _DispatchMessage,
it is actually a window message and doesn't require fCurrentLayer to
be valid
* fixed bug #1300, fCurrentLayer was not updated when a ViewLayer was
deleted by client request which happened to be fCurrentLayer (I am now
handling it so that the parent becomes the current layer, could be
wrong)
* AGGTextRenderer is no longer using it's own scanline, which should save
a few bytes RAM, the Painter already had such an object
* StringWidth() in AGGTextRenderer is now taking the escapement_delta into
account
* Painter::StrokeLine() doesn't need to check the clipping as much, since
that is already done in DrawingEngine
* if a ServerWindow message is not handled because fCurrentLayer is NULL,
a reply is sent in case the messages needs it (client window could
freeze otherwise, waiting for the reply for ever)
* removed unused AS_SET_FONT and AS_SET_FONT_SIZE
* added automatic RGBColor -> rgb_color conversion to RGBColor.h
* minor cleanup for 80 char/line limit



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

* cleanup, removed use of pointers and allocations


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

* since every window has it's own Painter instance, the drawing state does
not need to be "set" (transfered from the "current" view to the painter)
for each singly drawing command. Now, painter is synchronized whenever
the client changes the drawing state of the current view, or when the
current view changes.
* the screen offset of the current view has become part of the Painter state,
in the PatternHandler. This fixes a bug in which moving or scrolling a view
which used patterns for drawing, resulted in visual glitches (seams in the
pattern).

NOTE: this patch is a bit work in progress, most importantly, it is not
complete with regards to text rendering. More specifically, the server
applications and other parts of the appserver might set a font on the Painter
and this might mess up the synchronization. But this happens on the Desktop's
Painter instance (only?), and so it is not a problem. I did observe some
drawing bugs with this patch though, so bug reports are welcome, particularily
how to reproduce these bugs reliably.


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

* renamed HWInterface locking to LockParallelAccess() and
LockExclusiveAccess() (meaning more or less access to the
frame buffer)
* extracted the AGGTextRenderer to be a global instance used
by each Painter instance (currently, it is thread safe because
of the global font lock, so there is some work left in this
regard)
* gave every ServerWindow it's own DrawingEngine instance, this
is work in progress. So far, there doesn't seem to be a regression,
but less fighting over the exclusive access to the frame buffer, now
each ServerWindow thread can draw in parallel. There is room for
improvement, plus I think I'm leaking the DrawingEngine...
* changed the locking for the software cursor. ShowSoftwareCursor()
can only be called if HideSoftwareCursor(BRect) returned true, or
if you called the generic HideSoftwareCursor(), since it needs
to keep the cursor lock and unlocks in Show...!
* some clean up and renaming in Decorator and friends
* moved PatternHandler.h to live along with the .cpp


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

Merge from layout management branch.


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

* long overdue update to AGG 2.4
* removed the useless parts of AGG (which are only needed for the
interactive examples)
* make sure to jam -a libagg.a to solve any linking issues


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

* Painter switches back correctly from using B_OP_COPY for text to
using the "normal" B_OP_COPY for lines and such that works more
like B_OP_OVER actually (for example, the slider in VLC will look
much better, but also other stuff)
* combined Stroke and FillEllipse() into DrawEllipse() and fixed
some longstanding issues, ellipses are now correctly placed
(aligned) and of the correct size
* removed locking in the DrawingEngine drawing functions, since
you need to have the DrawingEngine locked anyways for the
clipping to stay what it is (and that's already the case elsewhere
in the code)
* simplified ConstrainClippingRegion, the NULL version was never
useful and also locking is removed, see above

summary: slight speed improvements, cleanup and bugfixes...


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

simplified polygon and bezier drawing methods, made them more efficient

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

* removed the special font renderer which was actually
the same as the normal one (one less renderer to update
the color of)
* added a special B_OP_COPY implementation for text, which
is in fact what the implementation was until now, so
just like on R5, you have to specify the correct low color
or you will see artifacts for the anti-aliased pixels
* implemented B_OP_COPY just like B_OP_OVER (only it draws
the low color too like it should). So all apps that
used B_OP_COPY to draw anything can continue to do so
without having to worry about the low color, it will
be anti-aliased against the actual background instead of
the low color (which made especially no sense when drawing
with the low color). Although this change makes it a bit
slower to use B_OP_COPY, Haiku is now much more compatible.


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

* Removed headers/private/servers/app - everything is in src/servers/app now.
* Removed DisplaySupport.h, wasn't needed anymore.
* Removed private color set functions from InterfaceDefs.cpp - we might want
something similar, but definitely not like that.
* Minor cleanup, added some missing licenses.


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

* round of baseline position for DrawString()
-> fixes some clipping problems (because of
hinting, the text was displayed at a rounded
position anyways, but the clipping calculation
was screwed up)
* take the drawing_mode and low color from the
current state for drawing line arrays


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

cleaned up the code using templates and added optimized version for CMAP8 bitmaps and B_OP_OVER (to benefit Tracker)

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

The first stab at optimizing bitmap drawing,
with quite good results I might add. Drawing B_RGB32
bitmaps is more than 1.2 times faster than on R5, while
B_CMAP8 bitmaps are slightly slower. The optimization
is only for B_OP_COPY and unscaled bitmaps
(B_RGB32 and B_CMAP8). Drawing only parts of the bitmap
is supported. Adding optimization for scaled bitmaps
should be beneficial, since the generic version is 2 two
4 times slower. I think it gets even worse for partial
bitmaps.


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

* removed superflous LockSingleWindow() from WindowLayer::MoveBy()
and ResizeBy()
* WindowLayer::SetSizeLimits() needs to be called with the
AllWindows lock held
* I was observing weird behaviour with "unclickable" windows
that I might have fixed by explicitly excluding invisible
windows from Desktop::WindowAt(), there might be something
wrong with the "current" window list though, Axel would know
* finally found the problem with "delayed background clearing"
* enabled delayed background clearing and removed unnecessary
code. It should be more efficient, since it clears larger
areas at once, and it solves the problem of views unable to
draw into regions that are pending for another update - among
other things, updates in resizing windows are more fluent,
especially for B_FULL_UPDATE_ON_RESIZE views. "Cut off" scroll
bars should no longer appear when the view being scrolled takes
too long to redraw.


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

* extracted the frame buffer memcpy routine from HWInterface.cpp
into a new frame_buffer_support.h
* added blend32 routine for blending a certain color with
a scanline in the frame buffer
* added "solid" versions of B_OP_ALPHA drawing with
B_ALPHA_OVERLAY alha function (blending on top of
a non-transparent background such as the frame buffer)
* implemented an optimized shortcut for alpha blended
FillRect() in Painter
* used the "packed" version of scanlines for shapes with
an outline thicker than 4 pixels (and filled shapes anyways),
this improves drawing speed when there are a few anti-aliased
pixels at the beginning of a scanline, then a solid fill and
some anti-aliased pixels at the end of the scanline. Such as
large letters.

To summarize: The alpha blending in Painter seems to be about
1.45 times faster than on BeOS R5 which benefits drawing large
shapes. For example, drawing a large alpha blended rounded rect
is 1.28 times faster on the Haiku app_server. On the other hand,
B_OP_COPY is quite tough to beat. It is currently 10 times faster
on R5. But a great deal seems to be caused by the Painter
rasterization algorithm itself, since commenting out the actual
drawing doesn't gain any speed.
The other useful experience I collected was that reading and
writing and over the PCI bus in the same loop really hurts
performance. It is actually faster (like 1.8 times!!) to allocate
a second buffer, read from frame buffer into that, doing the
blending at the same time, then writing the buffer back to the
screen.



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

small efficiency improvements - overall, the drawing speed of a usual BView, especially controls, is pretty much equal to R5 now (Drawing straight text, using StringWidth(), tons of AddLine()s, FillRect() etc) :-)

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

removed unused stuff from Painter and DrawingEngine, fixed the deadlock when trying to use the (20 times faster) DrawingEngine version of StringWidth, the font is now usually ignored when taking on a DrawState in Painter... should add a little speed overall

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

complete rework of the drawing_modes implementation... I achieved a speedup of 8 to 9 times, tested with text rendering. Believe it or not, but the Haiku text rendering is now faster than R5 for B_OP_COPY at least. And there is quite some room for improvement yet. (faster text bounding box calculation, avoiding the double UTF8 conversion, etc)

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

now updates BView::PenLocation() correctly after DrawString(), stuff like DrawChar('a') is working nicely now, for rotated text much better then in BeOS in fact because of subpixel precision in pen location

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

* Painter uses the line_cap and join_mode settings of DrawState
* Painter implements DrawShape for stroking and filling BShape data
* Painter uses clipping to avoid problems with huge coordinates, the R5 app_server can be crashed by this.
-> this should be added to more places as well like text rendering
* DrawingEngine uses the Painter to draw BShape data


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

Renamed the FontServer class to FontManager.


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

added escapement_delta to AGGTextRenderer::RenderString and Painter


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

offscreen bitmaps work, tested on Haiku as well, supports all colorspaces that BBitmap::ImportBits() supports. It uses a fallback for non-B_RGB(A)32 bitmaps. Added support for B_SUB_PIXEL_PRECISION view flags, though it is a bit hacky, since I had to add it to LayerData, even though it is not a true part of stack data. Added Layer::SetFlags() to enforce code path and update fLayerData. Cleaned up DisplayDriverPainter and DisplayDriver API (changed some const BRect& rect to simply BRect rect in order to be able to reuse it in the code), moved Painter.h, the test environment only draws the changed part of the frame buffer again - this causes a lot less CPU overhead, Painter special cases stroke width of 1.0 to use square caps, which is similar to R5 implementation and removes a lot of problems with non-straight line drawing, ServerWindow uses the DisplayDriver from it's WinBorder instead of the one from the Desktop (needed for offscreen windows, which have their own DisplayDriverPainter), it also checks for GetRootLayer() == NULL, because offscreen layers are not attached to a RootLayer, there was a fix for scrolling which worked at least in the test environment, it is now defunced, because Adi moved _CopyBits to Layer... I need to reenable it later, LayerData has no more fEscapementDelta, also fixed fFontAliasing (which was thought to overriding the font flags, and now works as such again), Desktop initialises the menu_info and scroll_bar_info stuff, which makes ScrollBars work actually... hope I didn't forget something.

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

Draw radial gradients using the proper radius.

Follow-up fixes for FillRect+transforms

* Factor out AlignRect to avoid code duplication
* Give the right rectangle to the OverlayHider.

app_server: Update and use the fill rule in all cases.

* It was previously not used for gradient rendering.
* It was not updated when the DrawState was set.
* Not actually tested, yet.

app_server & interface kit: support fill rules.

* BView gets SetFillRule/FillRule methods. The fill rule is part of the
view state.
* The B_NONZERO rule is the default. This is what we implemented before.
* The B_EVEN_ODD rule is the other common possibility for this, and
we need to support it to help WebKit to render properly.

app_server: Fixed issues in Painter.

* DrawPolygon was offsetting coords to pixel centers
regardless of whether the polygon was stroked or
filled, leading to wrong results for filling. Now
it offsets for stroking only and even takes pen-size
into acount. The bug was visible in Gobe Productive's
selection rendering.
* Renamed _Transform() methods to _Align(), which fits
better with what they do: Align coordinates with the
pixel grid.
* Changed rounding behavior for StrokeLine. Offsetting
to pixel centers depending on pen-size happens regardless
of sub-pixel mode. This means a stroked line on integer
coordinates looks the same in both modes. It breaks
some drawing in WonderBrush (brush cursor), which was
exploiting the previous behavior, but unbreaks Gobe
Productive caret rendering at zoom levels below 150%.

Both changes bring Gobe Productive text editing to a useable
level.

app_server: Fix computing bounding boxes for transformed stuff.

* In DrawingEngine, clipping is computed before drawing happens. This did not
take into account when drawing primitives can now be transformed. Fixes
drawing glitches in the Transformation test when the round rect is scrolled
into view and it was previously prevented to draw.
* Fixed clipping rect computation for the sanitized StrokeRoundRect()
implementation which centers the stroke on the rect.

Painter: Support transformation in gradient code paths.

Clipping paths (or rather alpha masks) and affine view transformations
seem to be generally supported for all drawing operations now. There might
still be bugs that have not yet been exposed by the current set of tests.
These could be related to scrolling, origin and scale as well as stacked
view states.

Implemented using the transformation in Painter (incomplete)

* Also removed wonky BeOS rendering of stroked round rects and ellipses.
Nobody would expect it to work like this. This affects stroked round rects
and ellipsis with a pensize greater than 1.
* Refactored common code from _StrokePath() and _FillPath().
* _StrokePath() returned a curious bounding box that didn't take into
acount the miter width. Now the bounding box is computed from the actual
stroke conversion of the path.

app_server: Move AlphaMask management into DrawState.

* Give DrawState a real copy constructor, handle deriving in PushState().
(Although clipping region and alpha mask are not cloned, which is on the
other hand just what's needed for now.)
* Combining alpha masks from previous states is not yet handled.
* Remove SetAlphaMask() from DrawingEngine and Painter. It is now done in
SetDrawState().

Add Alpha Masking support in ClipToPicture

Use AGG to implement ClipToPicture in a faster and better way.
There are things missing in this initial implementation:
* No support for PushState/PopState saving and restoring the picture.
* No support for nested clipping through PushState
* The clipping doesn't happen where you expect it when using SetScale()
* There are artifacts when scrolling and resizing clipped views
* The implementation uses more memory than it needs, as the clipping
bitmap is stored as RGBA32, yet only the alpha channel is used
* The clipping bitmap is rendered more times than it needs to. We need
some caching here.

* Moved the SIMD code from AppServer.cpp to Painter.cpp where it is actually
needed. It might be best to put it into its own file, though.
* This is required in order to let our test environment work with the stricter
runtime_loader we have now.


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

Basically, this changeset implements BShape::ArcTo(). In more detail:
* Added BShape::ArcTo() and BShapeIterator::IterateArcTo(), using a previously
unused virtual slot. (Added the symbols for binary compatibility for GCC2
and GCC4.)
* Added operator=(), operator==() and operator!=() to BShape.
* Added BShape::BezierTo() version taking three points, which is sometimes
more convenient.
* Added the four new shape data ops OP_LARGE_ARC_TO_CW, OP_LARGE_ARC_TO_CCW,
OP_SMALL_ARC_TO_CW and OP_SMALL_ARC_TO_CCW. For a single arc, provided the
radius is large enough, there are four possibilities to draw the arc, these
are controlled by the two boolean flags to ArcTo() and mapped to the new
commands accordingly.
* Some style cleanup in Shape.cpp (sorry for mixing it up, but it gets
worse below...)
* Added ShapeTest to src/tests/servers/app.
* Changed the way BShapes are transformed from view to screen space in the
app_server. For arcs, it would be nontrivial to apply a proper transformation,
it's much easier to let AGG take care of it. This affects ServerPicture as
well.
* Wrapped iterating the BShape into try/catch blocks in ShapeIterator. But
I really don't understand the purpose of the class in the first place.
Maybe it can now be dropped, since coordinates don't have to be transformed
in place anymore.
* Refactored copy&paste shape iteration code in Painter. The transformation
to screen space happens there.
* Since RemoteDrawingEngine needed to be adopted anyway, I also updated
it for the new DrawString() with offsets version. But the client still needs
to be adapted.
* Style cleanup in Painter.h


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

* Extended the BView drawing API by a DrawString() version that takes an array
of locations, one for each glyph.
* Added a test for the new functionality.


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

Patch by Christian Packmann:
* Implemented a CPU feature detection function in AppServer.cpp.
The results are put into the global variable gAppServerSIMDFlags.
* Implemented an SIMD accelerated version of the bilinear bitmap
scaling code that is the backend of BView::DrawBitmap(...,
uint32 options) used by the MediaPlayer to smoothly upscale
movies when no video overlay is available. The speed up is very
noticable and a Core 2 Duo @ 1.8 GHz can play at 1920x1200 now
without breaking a sweat. There is currently one SIMD version
implemented which uses MMX and plain SSE.

Very cool! Thanks a lot!


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

Finished the optimization for vertical gradients. This code is about
8.3 times faster than using the AGG pipeline, but about 3 times slower
than drawing a solid color square. It can probably still be improved.
The second version of _MakeGradient() is more powerful than the old one
and should replace it. It handles some corner cases, which the other
one does not.


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

* Cleanup in the Gradient department. No fuctional change.
Renamed BGradient::color_step to BGradient::ColorStop
as it's called everywhere else. Also renamed BGradient::gradient_type
to just BGradient::Type. Renamed BGradient::Type() to GetType().
* Simplification of method names in Painter.cpp. Some not yet
complete and yet inactive code to accelerate vertical gradients
(bypassing AGG for this special case).


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

Patch by Artur Wyszynski:
* Implemented BGradient, BGradientLinear, BGradientRadial,
BGradientDiamond, BGradientConic and BGradientRadialFocus
new Interface Kit classes.
* Implemented all the (AGG-based) backend necessary in
the app_server to render gradients (Painter, DrawingEngine)
* app_server/View can convert a BGradient layout to screen
coordinates.
* Added BGradient methods of the Fill* methods in BView.
* Implemented a test app and added it to the image as a
demo.
* Adopted Icon-O-Matic and libs/icon in order to avoid
clashing with the new BGradient class. Re-use some
parts where possible.

Awesome work, Artur! Thanks a lot. Now a more modern
looking GUI has just become much easier to implement! :-)

TODO:
* Remove the need to have gradient type twice in the
app_server protocol.
* Refactor some parts of the patch to remove duplicated
code (Painter, DrawingEngine).
* Adopt the BPicture protocol to know about BGradients.
* Review some parts of the BArchivable implementation.


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

* When playing with the MediaPlayer and toggling bilinear versus
nearest neighbor scaling, I noticed that the bilinear version
actually used less CPU than the generic AGG code path with nn
scaling. So I wrote an optimized nn scaling routine for nn
based on the bilinear scaling code. So the indices into the
source bitmap are cached. I don't know if this is the optimal
nn scaling routine, but the CPU usage dropped significantly.
Only B_OP_COPY is optimized as of yet.
* Optimized the bilinear scaling. When more filtered pixels than
unfiltered pixels are anticipated, the loops are unrolled to
special case the very last row/column and bottom right pixel.
This eliminates the branches in the loops.
* Fixed a bug with partial scaled drawing of bitmaps when it
used the bilinear scaling, the bitmapShift was in the wrong
direction.


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

Patch by Andrej Spielmann (GSoC):
* Simplified the subpixel related methods for the AGG "pixel format" template
interface, the ones for the solid cover simply pass through the existing
methods, so only one subpixel blending function is left which does the actual
work (this removes a lot of the previously added code)
* Implemented a new rasterizer based on the original AGG rasterizer which
implements subpixel anti-aliasing for any generic AGG vector pipelines. It
is now optionally used in Painter and AGGTextRenderer (for vector fonts, ie
rotated, sheared or big enough fonts) depending on the global subpixel
setting.
* Put all subpixel variables into the new GlobalSubpixelSettings.h|cpp
* Simplified DesktopSettings related classes a bit and renamed previous
FontSubpixelAntialiasing to just SubpixelAntialiasing.
* The private libbe functions for subpixel related settings moved from Font.cpp
to InterfaceDefs.cpp where other such functions live. They are not related
to fonts only anymore.
* Removed the subpixel related settings again from the Fonts preflet and added
them to the Appearance preflet instead.

All of the above implements subpixel anti-aliasing on a global scale, which
to my knowledge no other OS is doing at the moment. Any vector rendering
can optionally use subpixel anti-aliasing in Haiku now. The bitmap cached fonts
are still affected by the Freetype complile time #define to enable the patented
subpixel rasterization (three times wide glyphs). Vector fonts and shapes are
not affected though at the moment.



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

* Implemented new BView drawing functions DrawBitmap[Async](
const BBitmap* bitmap, BRect bitmapRect, BRect viewRect, uint32 options).
Only option so far is B_FILTER_BITMAP_BILINEAR.
* BView::DrawBitmap[Async](const BBitmap* bitmap, BRect viewRect) was accessing
the bitmap pointer without checking it. Would therefore crash when passing
NULL, unlike the other methods.
* The BPicture code already reserved room for the BBitmap flags, but did not
store the actual flags and neiter use them for anything. Since the bitmap
data is stored anyways, the bitmap creation flags do not matter. So I reused
this for the new bitmap drawing options.
* Rewrote Bitmap.h and removed the B_BITMAP_SCALE_BILINEAR flag again.
* Tried to optimize Painter::_DrawBitmapBilinearCopy32() a little by giving
the compiler better hints. There seems to be a marginal, possibly imagined
speed increase < 0.05 ms. ;-)


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

Implemented an optimized version of bilinear scaled bitmap drawing for
B_OP_COPY which is about 2.4 times faster than the AGG version (but of
course less generic). The speed up is even better for smaller and even
scales.


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

* Introduced new BBitmap flag B_BITMAP_SCALE_BILINEAR.
* When drawing BBitmaps with scaling in the app_server, use a bilinear
filter when a bitmap has this flag set. (Hope nobody objects, otherwise
I can revert or improve this. Performance can certainly be improved, since
the AGG implementation is too generic. But that goes for the nearest
neighbor implementation as well.)
* Flags are uint32, fix app_server side code to declare them correctly. Use
appropriate link methods in BBitmap and ServerApp.
* Enable the BeOS compatibility mode for B_RGB32 (works just like B_RGBA32
in B_OP_ALPHA mode).


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

Patch by Andrej Spielmann (GSOC):
* Integrate the subpixel rendering with the existing drawing backend and
the font rendering.
* The font cache has got an additional rendering type for extracting and
caching glyph bitmaps that store subpixel coverage values.


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

When drawing bitmaps with B_OP_OVER with a color space that does not provide
an alpha channel of itself, we have to respect B_TRANSPARENT_MAGIC_* pixels
and properly make them transparent. We achive that now by just setting the
alpha to 0 in our converted B_RGBA32 bitmap for each pixel where there is a
B_TRANSPARENT_MAGIC_* pixel in the source. This is not really efficient, but
fixes missing images for example in NetPositive. They were treated as B_RGBA32
while they in fact were B_RGB32 and happened to have all alpha bits set to 0.

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

* track the fact if Painter is attached to a frame buffer, incorporate
this information in the fValidClipping flag... which should prevent
any drawing code to run if Painter is not attached properly


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

* fixed the crashing result of bug #634, check if the supplied region
falls within the frame buffer bounds. This should not happen, and
I am going to search for the cause next, but at least app_server
dosn't crash anymore in this context. Left a comment on my findings
so far.


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

* fractional rects need to be aligned if not drawing in subpixel precise mode,
by now, I feel there is too much code involved in this... I guess I should
really move this to stuff to ViewLayer::ConvertToScreenForDrawing()...


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

* this fixes the second part of #1426, unfortunately, the clipping checks
have become more expensive, so maybe it is better to do what I proposed
in the ticket comments, and move the rounding of drawing command coordinates
into ViewLayer::ConvertToTopForDrawing() instead of handling it in
DrawingEngine and Painter


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

* added a version of SetFont() that takes a DrawState* to DrawingEngine and
Painter, that is needed to be able to tell if anti-aliasing is to be used,
since the flags in the font can be overruled by the flags in the view...
* fixes aliased fonts reliably, tested with FontDemo


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

* after my last changes to font rendering, it was about 15% slower than
before (although there should be much less lock contention)
* with this change, there is quite a bit of cleanup, text drawing is now
about 20% faster than before the original changes to font caching,
mostly due to turning off the kerning feature, which at the moment
gives absolutely no benefit. The correct way of doing it might be to
use kerning depending on the provided glyph spacing mode
* removed fPenLocation from Painter, the usage should be more correct now,
since it is now consistently applied before the coordinate transformation
from view to screen (also for DrawShape() now, before any view scaling
and origin offset)
* Painter no longer has it's own instance of a ServerFont, instead it uses
its AGGTextRenderer instance, which was per Painter again after the
last change, and not global anymore, made _UpdateFont() useless
* When using GlyphLayoutEngine, it supports a second pass with the same
FontCacheEntry through the introduction of a FontCacheReference. This
speeds up DrawString a little, since it needs to calculate the bounding
box for the string, and then draw the string in a second pass. This is
now done with only one FontCacheEntry lookup
* I also tried to optimize the on-the-fly conversion of UTF8->CharCode away,
since it was done four times per DrawString, but surprisingly, it proofed
to be a slight slowdown.
* introduced a shortcut in DrawingEngine::DrawString() which avoids
calculating the bounding box, we are now a tiny bit faster to figure
out that we don't need to draw any string than Dano

In the test environment (drawing to offscreen bitmap and blitting to
screen eventually), text rendering is now about 3.7 times _faster_ than Dano
text rendering (directly to screen), for untransformed text. Unfortunately
I cannot test on the same machine in accelerant using version of the test
environment.


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

* complete overhaul of the font/glyph caching
* the previous AGG implementation is superfluous
* the new implementation is based on that one, but in a way that allows
read/write locking to the list of cache entries (fonts) as well as
read/write locking to the cached glyphs per individual font cache entry
* new GlyphLayoutEngine.h, which is to be the central place for layouting
glyphs along the baseline.
It handles the locking for getting the font cache entries.
It works by giving it a template class GlyphConsumer which does the
actual work.
* changed AGGTextRenderer to use the new font cache
* changed ServerFont::StringWidth(), and the bounding box stuff to use it
* changed DrawingEngine, it doesn't need the global font lock anymore
* our BFont thought that GetBoundingBoxesAsGlyphs and GetBoundingBoxesAsString
is the same, which of course it isn't, hence the two separate functions...
AsGlyphs just gets the bounding box of each glyph in a string, not treating
the string as an actual word
AsString adds the offset of the glyph in the word to the bounding box
* changed ServerProtocol.h accordingly for the different bounding box meaning


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

* completed my changes to DrawState handling, the current DrawingState
of the active ViewLayer is now always mirrored in the Painter instance
of a ServerWindow, so that it doesn't need to be synced on every drawing
command, this was previously incomplete for font handling
* removed the DrawState parameter from all the DrawingEngine functions
* adjusted ServerWindow and ServerPicture accordingly
* made sure that string related functions used by non-drawing related
parts (ServerApp, Decorator) don't interfere with the current drawing
state
* moved AS_SYNC handling from _DispatchViewMessage to _DispatchMessage,
it is actually a window message and doesn't require fCurrentLayer to
be valid
* fixed bug #1300, fCurrentLayer was not updated when a ViewLayer was
deleted by client request which happened to be fCurrentLayer (I am now
handling it so that the parent becomes the current layer, could be
wrong)
* AGGTextRenderer is no longer using it's own scanline, which should save
a few bytes RAM, the Painter already had such an object
* StringWidth() in AGGTextRenderer is now taking the escapement_delta into
account
* Painter::StrokeLine() doesn't need to check the clipping as much, since
that is already done in DrawingEngine
* if a ServerWindow message is not handled because fCurrentLayer is NULL,
a reply is sent in case the messages needs it (client window could
freeze otherwise, waiting for the reply for ever)
* removed unused AS_SET_FONT and AS_SET_FONT_SIZE
* added automatic RGBColor -> rgb_color conversion to RGBColor.h
* minor cleanup for 80 char/line limit



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

* cleanup, removed use of pointers and allocations


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

* since every window has it's own Painter instance, the drawing state does
not need to be "set" (transfered from the "current" view to the painter)
for each singly drawing command. Now, painter is synchronized whenever
the client changes the drawing state of the current view, or when the
current view changes.
* the screen offset of the current view has become part of the Painter state,
in the PatternHandler. This fixes a bug in which moving or scrolling a view
which used patterns for drawing, resulted in visual glitches (seams in the
pattern).

NOTE: this patch is a bit work in progress, most importantly, it is not
complete with regards to text rendering. More specifically, the server
applications and other parts of the appserver might set a font on the Painter
and this might mess up the synchronization. But this happens on the Desktop's
Painter instance (only?), and so it is not a problem. I did observe some
drawing bugs with this patch though, so bug reports are welcome, particularily
how to reproduce these bugs reliably.


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

* renamed HWInterface locking to LockParallelAccess() and
LockExclusiveAccess() (meaning more or less access to the
frame buffer)
* extracted the AGGTextRenderer to be a global instance used
by each Painter instance (currently, it is thread safe because
of the global font lock, so there is some work left in this
regard)
* gave every ServerWindow it's own DrawingEngine instance, this
is work in progress. So far, there doesn't seem to be a regression,
but less fighting over the exclusive access to the frame buffer, now
each ServerWindow thread can draw in parallel. There is room for
improvement, plus I think I'm leaking the DrawingEngine...
* changed the locking for the software cursor. ShowSoftwareCursor()
can only be called if HideSoftwareCursor(BRect) returned true, or
if you called the generic HideSoftwareCursor(), since it needs
to keep the cursor lock and unlocks in Show...!
* some clean up and renaming in Decorator and friends
* moved PatternHandler.h to live along with the .cpp


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

Merge from layout management branch.


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

* long overdue update to AGG 2.4
* removed the useless parts of AGG (which are only needed for the
interactive examples)
* make sure to jam -a libagg.a to solve any linking issues


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

* Painter switches back correctly from using B_OP_COPY for text to
using the "normal" B_OP_COPY for lines and such that works more
like B_OP_OVER actually (for example, the slider in VLC will look
much better, but also other stuff)
* combined Stroke and FillEllipse() into DrawEllipse() and fixed
some longstanding issues, ellipses are now correctly placed
(aligned) and of the correct size
* removed locking in the DrawingEngine drawing functions, since
you need to have the DrawingEngine locked anyways for the
clipping to stay what it is (and that's already the case elsewhere
in the code)
* simplified ConstrainClippingRegion, the NULL version was never
useful and also locking is removed, see above

summary: slight speed improvements, cleanup and bugfixes...


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

simplified polygon and bezier drawing methods, made them more efficient

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

* removed the special font renderer which was actually
the same as the normal one (one less renderer to update
the color of)
* added a special B_OP_COPY implementation for text, which
is in fact what the implementation was until now, so
just like on R5, you have to specify the correct low color
or you will see artifacts for the anti-aliased pixels
* implemented B_OP_COPY just like B_OP_OVER (only it draws
the low color too like it should). So all apps that
used B_OP_COPY to draw anything can continue to do so
without having to worry about the low color, it will
be anti-aliased against the actual background instead of
the low color (which made especially no sense when drawing
with the low color). Although this change makes it a bit
slower to use B_OP_COPY, Haiku is now much more compatible.


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

* Removed headers/private/servers/app - everything is in src/servers/app now.
* Removed DisplaySupport.h, wasn't needed anymore.
* Removed private color set functions from InterfaceDefs.cpp - we might want
something similar, but definitely not like that.
* Minor cleanup, added some missing licenses.


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

* round of baseline position for DrawString()
-> fixes some clipping problems (because of
hinting, the text was displayed at a rounded
position anyways, but the clipping calculation
was screwed up)
* take the drawing_mode and low color from the
current state for drawing line arrays


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

cleaned up the code using templates and added optimized version for CMAP8 bitmaps and B_OP_OVER (to benefit Tracker)

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

The first stab at optimizing bitmap drawing,
with quite good results I might add. Drawing B_RGB32
bitmaps is more than 1.2 times faster than on R5, while
B_CMAP8 bitmaps are slightly slower. The optimization
is only for B_OP_COPY and unscaled bitmaps
(B_RGB32 and B_CMAP8). Drawing only parts of the bitmap
is supported. Adding optimization for scaled bitmaps
should be beneficial, since the generic version is 2 two
4 times slower. I think it gets even worse for partial
bitmaps.


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

* removed superflous LockSingleWindow() from WindowLayer::MoveBy()
and ResizeBy()
* WindowLayer::SetSizeLimits() needs to be called with the
AllWindows lock held
* I was observing weird behaviour with "unclickable" windows
that I might have fixed by explicitly excluding invisible
windows from Desktop::WindowAt(), there might be something
wrong with the "current" window list though, Axel would know
* finally found the problem with "delayed background clearing"
* enabled delayed background clearing and removed unnecessary
code. It should be more efficient, since it clears larger
areas at once, and it solves the problem of views unable to
draw into regions that are pending for another update - among
other things, updates in resizing windows are more fluent,
especially for B_FULL_UPDATE_ON_RESIZE views. "Cut off" scroll
bars should no longer appear when the view being scrolled takes
too long to redraw.


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

* extracted the frame buffer memcpy routine from HWInterface.cpp
into a new frame_buffer_support.h
* added blend32 routine for blending a certain color with
a scanline in the frame buffer
* added "solid" versions of B_OP_ALPHA drawing with
B_ALPHA_OVERLAY alha function (blending on top of
a non-transparent background such as the frame buffer)
* implemented an optimized shortcut for alpha blended
FillRect() in Painter
* used the "packed" version of scanlines for shapes with
an outline thicker than 4 pixels (and filled shapes anyways),
this improves drawing speed when there are a few anti-aliased
pixels at the beginning of a scanline, then a solid fill and
some anti-aliased pixels at the end of the scanline. Such as
large letters.

To summarize: The alpha blending in Painter seems to be about
1.45 times faster than on BeOS R5 which benefits drawing large
shapes. For example, drawing a large alpha blended rounded rect
is 1.28 times faster on the Haiku app_server. On the other hand,
B_OP_COPY is quite tough to beat. It is currently 10 times faster
on R5. But a great deal seems to be caused by the Painter
rasterization algorithm itself, since commenting out the actual
drawing doesn't gain any speed.
The other useful experience I collected was that reading and
writing and over the PCI bus in the same loop really hurts
performance. It is actually faster (like 1.8 times!!) to allocate
a second buffer, read from frame buffer into that, doing the
blending at the same time, then writing the buffer back to the
screen.



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

small efficiency improvements - overall, the drawing speed of a usual BView, especially controls, is pretty much equal to R5 now (Drawing straight text, using StringWidth(), tons of AddLine()s, FillRect() etc) :-)

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

removed unused stuff from Painter and DrawingEngine, fixed the deadlock when trying to use the (20 times faster) DrawingEngine version of StringWidth, the font is now usually ignored when taking on a DrawState in Painter... should add a little speed overall

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

complete rework of the drawing_modes implementation... I achieved a speedup of 8 to 9 times, tested with text rendering. Believe it or not, but the Haiku text rendering is now faster than R5 for B_OP_COPY at least. And there is quite some room for improvement yet. (faster text bounding box calculation, avoiding the double UTF8 conversion, etc)

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

now updates BView::PenLocation() correctly after DrawString(), stuff like DrawChar('a') is working nicely now, for rotated text much better then in BeOS in fact because of subpixel precision in pen location

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

* Painter uses the line_cap and join_mode settings of DrawState
* Painter implements DrawShape for stroking and filling BShape data
* Painter uses clipping to avoid problems with huge coordinates, the R5 app_server can be crashed by this.
-> this should be added to more places as well like text rendering
* DrawingEngine uses the Painter to draw BShape data


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

Renamed the FontServer class to FontManager.


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

added escapement_delta to AGGTextRenderer::RenderString and Painter


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

offscreen bitmaps work, tested on Haiku as well, supports all colorspaces that BBitmap::ImportBits() supports. It uses a fallback for non-B_RGB(A)32 bitmaps. Added support for B_SUB_PIXEL_PRECISION view flags, though it is a bit hacky, since I had to add it to LayerData, even though it is not a true part of stack data. Added Layer::SetFlags() to enforce code path and update fLayerData. Cleaned up DisplayDriverPainter and DisplayDriver API (changed some const BRect& rect to simply BRect rect in order to be able to reuse it in the code), moved Painter.h, the test environment only draws the changed part of the frame buffer again - this causes a lot less CPU overhead, Painter special cases stroke width of 1.0 to use square caps, which is similar to R5 implementation and removes a lot of problems with non-straight line drawing, ServerWindow uses the DisplayDriver from it's WinBorder instead of the one from the Desktop (needed for offscreen windows, which have their own DisplayDriverPainter), it also checks for GetRootLayer() == NULL, because offscreen layers are not attached to a RootLayer, there was a fix for scrolling which worked at least in the test environment, it is now defunced, because Adi moved _CopyBits to Layer... I need to reenable it later, LayerData has no more fEscapementDelta, also fixed fFontAliasing (which was thought to overriding the font flags, and now works as such again), Desktop initialises the menu_info and scroll_bar_info stuff, which makes ScrollBars work actually... hope I didn't forget something.

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