Remove all invocations of SetSubDirSupportedPlatformsBeOSCompatible.

app_server: declare jam dependency for BitmapPainter to freetype

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.

Update freetype package

Also use the new build feature rules

Add FreeType headers dependencies, #8716.

freetype: builds against the 2.4.6 optional package.

* added optional feature package for freetype 2.4.6 gcc4/gcc2 x86 and gcc4 ppc.
* FT_CONFIG_OPTION_SUBPIXEL_RENDERING is disabled, --include-patented-code doesn't
change this setting anymore. This would require different packages.
* drop freetype sources and headers from the tree.
* fix decorators, test app server and appearance to use feature package headers.
* hybrid build untested.

Cleanup app server directory a bit by creating a font and a decorator sub folder.



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

bonefish + stippi:
Reworked the glyph caching:
* It is now glyph index based (a font file has an internal glyph code to
index mapping, so that for example the same fallback glyph is used for
all unsupported codes).
* We do not truncate to uint16 anymore at various places, but support
the full 32 bit char codes.
* This made it necessary to switch to an OpenHashTable based cache lookup.
* In CharacterMap, you can now see that the second Unicode plane does not
wrap around anymore.
TODO: Remove old entries from the hash table after a while to free up memory.


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

* This should fix the app_server build under other architectures than x86.
* Fixed wrong operator precedence case in Painter::SetFont().
* Fixed dozens of style violations.


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

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

* moved AGGTextRenderer alongside it's pal, Painter, it felt lonely,
removed font_support folder
* ServerApp can use ServerFont::StringWidth() directly again
* more ServerFont functions implemented via GlyphLayoutEngine and
custom consumer
* extended GlyphCache data structure to hole the left/right insets
of the glyph shape between its advance width, took it from the earlier
ServerFont implementation, have not tested if that gives same result
as R5
* TODO: implement GetGylphShapes via GlyphCache, although it might not
look as clean as it does now


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

Implemented some more overlay support - the overlay bitmap is now allocated
via the graphics driver (but not yet shown on screen).
I probably got the meaning of the "overlay count" wrong - I guess that you
can allocate any number of overlay bitmaps, but can only see "overlay count"
on screen at a time (right now, I only allow to create "overlay count" bitmaps).
Stephan?


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

* 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

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

* Reintroduced third LinkAgainst parameter <mapLibs>, defaulting to true.
Library names are now mapped for all targets but "host" (not only for
"haiku") -- added one more level of indirection to achieve that.
(TARGET_LIBRARY_NAME_MAP -> *_LIBRARY_NAME_MAP_*).
* Renamed build/HaikuBuildCompatibility.h to BeOSBuildCompatibility.h
(auto-included when compiling something that uses the Be API for platform
"host" on anon-BeOS platform), and introduced build/HaikuBuildCompatibility.h,
which can be included when compiling something that can be built for both,
Haiku and BeOS compatible platforms.
* Introduced libhaikucompat.a, a library that adds a few functions existing
under Haiku, but not under BeOS.
* New rule AddSubDirSupportedPlatforms.
* Renamed libopenbeos.so to libbe_haiku.so.
* Introduced new target platform "libbe_test", which is basically equivalent
to a BeOS compatible host platform target, with the exception, that instead
of the host platform's libbe.so a special build of Haiku's libbe.so
(libbe_haiku.so (formerly known as libopenbeos.so)) is used. Furthermore
Haiku's public app, interface, storage, and support kit headers are used
when compiling. This replaces the less nice way in which the test app server
and applications for this test environment were built.
When building for platform "libbe_test", the library name "be" is
autotranslated to "libbe_haiku.so". Thus most applications don't need
special fiddling when them building them for the app server test environment;
usually an "AddSubDirSupportedPlatforms libbe_test ;" will suffice.
* Reduced the dependencies of <syscalls.h> and fixed problems caused by this
(e.g. source files not including the needed headers directly).



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

sorry, forgotten in previous commit

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

Fixed a bunch of bugs in the font sub-system:
* BFont::Face() was almost always wrong - also on the server side,
_TranslateStyleToFace() was broken.
* a clean font was not correctly initialized to be_plain_font
* BFont::GetFamilyAndStyle() did not work correctly if either family
or style was NULL - which is allowed, and shouldn't have let it abort
its task.
* FontServer::GetStyle() by ID did not work reliably under certain
circumstances (but those were not reached with the current server)
* BFont::SetFamilyAndStyle() did not work when family was NULL, and
it also never set fFace correctly.
* Introduced a FontFamily::GetStyleWithFace()
* Renamed some FontFamily/FontStyle methods from ie. GetID() to ID()
to match the style used everywhere else in BeOS.
* Removed AS_SET_FAMILY_NAME as its no longer in use.
* Lots of cleanup and simplification.


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

Merged changes from branch build_system_redesign at revision 14573.


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

Work in progress... improvements on font stuff, reverted to using Painter to get the string width. Since it actually uses glyph caching, it is about 20 times faster than the implementation in ServerFont (and a about twice the time as R5). I added a StringWidth method to Painter and AGGTextRenderer which works as correct as ServerFont::StringWidth, which btw was broken, because I mixed up glyph count and byte count...

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

The Painter now uses a special version of the agg_font_engine that uses the FontServer ftlib and the already loaded FT_Facees from ServerFont/FontStyle instead of doing it all again.

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

disable the build of agg_font_freetype.cpp for now

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

Add Jamfile for libpainter.a to fix the build of app_server.


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

Update freetype package

Also use the new build feature rules

Add FreeType headers dependencies, #8716.

freetype: builds against the 2.4.6 optional package.

* added optional feature package for freetype 2.4.6 gcc4/gcc2 x86 and gcc4 ppc.
* FT_CONFIG_OPTION_SUBPIXEL_RENDERING is disabled, --include-patented-code doesn't
change this setting anymore. This would require different packages.
* drop freetype sources and headers from the tree.
* fix decorators, test app server and appearance to use feature package headers.
* hybrid build untested.

Cleanup app server directory a bit by creating a font and a decorator sub folder.



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

bonefish + stippi:
Reworked the glyph caching:
* It is now glyph index based (a font file has an internal glyph code to
index mapping, so that for example the same fallback glyph is used for
all unsupported codes).
* We do not truncate to uint16 anymore at various places, but support
the full 32 bit char codes.
* This made it necessary to switch to an OpenHashTable based cache lookup.
* In CharacterMap, you can now see that the second Unicode plane does not
wrap around anymore.
TODO: Remove old entries from the hash table after a while to free up memory.


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

* This should fix the app_server build under other architectures than x86.
* Fixed wrong operator precedence case in Painter::SetFont().
* Fixed dozens of style violations.


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

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

* moved AGGTextRenderer alongside it's pal, Painter, it felt lonely,
removed font_support folder
* ServerApp can use ServerFont::StringWidth() directly again
* more ServerFont functions implemented via GlyphLayoutEngine and
custom consumer
* extended GlyphCache data structure to hole the left/right insets
of the glyph shape between its advance width, took it from the earlier
ServerFont implementation, have not tested if that gives same result
as R5
* TODO: implement GetGylphShapes via GlyphCache, although it might not
look as clean as it does now


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

Implemented some more overlay support - the overlay bitmap is now allocated
via the graphics driver (but not yet shown on screen).
I probably got the meaning of the "overlay count" wrong - I guess that you
can allocate any number of overlay bitmaps, but can only see "overlay count"
on screen at a time (right now, I only allow to create "overlay count" bitmaps).
Stephan?


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

* 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

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

* Reintroduced third LinkAgainst parameter <mapLibs>, defaulting to true.
Library names are now mapped for all targets but "host" (not only for
"haiku") -- added one more level of indirection to achieve that.
(TARGET_LIBRARY_NAME_MAP -> *_LIBRARY_NAME_MAP_*).
* Renamed build/HaikuBuildCompatibility.h to BeOSBuildCompatibility.h
(auto-included when compiling something that uses the Be API for platform
"host" on anon-BeOS platform), and introduced build/HaikuBuildCompatibility.h,
which can be included when compiling something that can be built for both,
Haiku and BeOS compatible platforms.
* Introduced libhaikucompat.a, a library that adds a few functions existing
under Haiku, but not under BeOS.
* New rule AddSubDirSupportedPlatforms.
* Renamed libopenbeos.so to libbe_haiku.so.
* Introduced new target platform "libbe_test", which is basically equivalent
to a BeOS compatible host platform target, with the exception, that instead
of the host platform's libbe.so a special build of Haiku's libbe.so
(libbe_haiku.so (formerly known as libopenbeos.so)) is used. Furthermore
Haiku's public app, interface, storage, and support kit headers are used
when compiling. This replaces the less nice way in which the test app server
and applications for this test environment were built.
When building for platform "libbe_test", the library name "be" is
autotranslated to "libbe_haiku.so". Thus most applications don't need
special fiddling when them building them for the app server test environment;
usually an "AddSubDirSupportedPlatforms libbe_test ;" will suffice.
* Reduced the dependencies of <syscalls.h> and fixed problems caused by this
(e.g. source files not including the needed headers directly).



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

sorry, forgotten in previous commit

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

Fixed a bunch of bugs in the font sub-system:
* BFont::Face() was almost always wrong - also on the server side,
_TranslateStyleToFace() was broken.
* a clean font was not correctly initialized to be_plain_font
* BFont::GetFamilyAndStyle() did not work correctly if either family
or style was NULL - which is allowed, and shouldn't have let it abort
its task.
* FontServer::GetStyle() by ID did not work reliably under certain
circumstances (but those were not reached with the current server)
* BFont::SetFamilyAndStyle() did not work when family was NULL, and
it also never set fFace correctly.
* Introduced a FontFamily::GetStyleWithFace()
* Renamed some FontFamily/FontStyle methods from ie. GetID() to ID()
to match the style used everywhere else in BeOS.
* Removed AS_SET_FAMILY_NAME as its no longer in use.
* Lots of cleanup and simplification.


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

Merged changes from branch build_system_redesign at revision 14573.


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

Work in progress... improvements on font stuff, reverted to using Painter to get the string width. Since it actually uses glyph caching, it is about 20 times faster than the implementation in ServerFont (and a about twice the time as R5). I added a StringWidth method to Painter and AGGTextRenderer which works as correct as ServerFont::StringWidth, which btw was broken, because I mixed up glyph count and byte count...

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

The Painter now uses a special version of the agg_font_engine that uses the FontServer ftlib and the already loaded FT_Facees from ServerFont/FontStyle instead of doing it all again.

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

disable the build of agg_font_freetype.cpp for now

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

Add Jamfile for libpainter.a to fix the build of app_server.


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