make it work, one would need to use versioning for all libbe symbols. This is
worth an 8k price per file that links against libbe.so, so I didn't want to
commit this as is. An alternative to this solution would be to write a
separate application that is responsible for the app_server's window. Comments
welcome.
* Removed BeOS compatbility of the libbe_test stuff.
* Renamed the libbe_test targets from *haiku* to *test*, ie. libbe_haiku.so is
now called libbe_test.so, haiku_registrar is now test_registrar, etc.
* This also removes BeOS compatibility from tracker/FSUtils.cpp (all BeOS
compatibility should be removed, but I don't want to make Alexandre more work
in his branch, and it's not urgent at all).
* Replaced the former "run" scripts for the test environment with a single
run script (see updated NOTES file).
* Removed the libbe_test target from some applications - this was only to help
developing them under BeOS, and is thus no longer necessary.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32521 a95241bf-73f2-0310-859d-f6bbb57e9c96
because I forgot to add these files in my last commit... sorry.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29959 a95241bf-73f2-0310-859d-f6bbb57e9c96
mode. The ClippedLineTest is removed, since that was a dup of RandomLines
anyways.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29953 a95241bf-73f2-0310-859d-f6bbb57e9c96
text controls for defining the color. Thanks a lot! (Also took the opportunity
to fix some coding style violations which had already been there.)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29846 a95241bf-73f2-0310-859d-f6bbb57e9c96
new thread and the main thread in this order. Allows to reproduce #2956
quite often.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29301 a95241bf-73f2-0310-859d-f6bbb57e9c96
or moving mode when it was shown again. Added a test app HideAndShow which let
you easily reproduce the faulty behaviour (with a previous version of the
app_server, that is).
* Minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28847 a95241bf-73f2-0310-859d-f6bbb57e9c96
fixes in my tree to make it compile on R5 still. I don't really want to
check this in, I'd rather adopt the buildsystem to make it run on Haiku
itself...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28298 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Made the StressTest app into a real stress test for the app_server, as the
windows are now randomly changed, ie. moved, resized, hidden, activated, ...
* This already helped identifying two long-hiding bugs in the app_server code!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28216 a95241bf-73f2-0310-859d-f6bbb57e9c96
shows a bug in the app_server event dispatching which is going to be fixed
next.)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28058 a95241bf-73f2-0310-859d-f6bbb57e9c96
of stealing (not anymore) mouse messages that are important for maintaining
the correct transit.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28003 a95241bf-73f2-0310-859d-f6bbb57e9c96
* 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
accordingly and refactor a bit). It also prints the number of clipping rects.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26685 a95241bf-73f2-0310-859d-f6bbb57e9c96
small clipping holes to the TestView user clipping.
* Added a bunch of new tests. Here are some numbers from the test environment,
which is similar to running Haiku in VESA mode:
Horizontal lines per second:
Haiku: 192964.663 (117,7%)
ZETA: 163977.006
Vertical lines per second:
Haiku: 90109.985 (276.9%)
ZETA: 32538.458
Random lines per second:
Haiku: 7998.451 (23.1%)
ZETA: 34602.539
Random colored lines per second:
Haiku: 7976.437 (22.9%)
ZETA: 34788.247
Random clipped lines per second:
Haiku: 262.180 (2.5%)
ZETA: 10394.794
Clipped glyphs per second:
Haiku: 5911.526 (1.0%)
ZETA: 590508.726
Obviously the clipping performance is a punch in the stomache.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26683 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Use more letters of the roman alphabet (doh...)
* Tested drawing mode is currently B_OP_COPY
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26681 a95241bf-73f2-0310-859d-f6bbb57e9c96
of the Haiku app_server. The immediate comparison are of course BeOS and ZETA.
Currently, it measures the performance of drawing untransformed text. For
now, I have only tested on ZETA and the app_server testing environment. Will
let you know my findings with Haiku running on real hardware.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26680 a95241bf-73f2-0310-859d-f6bbb57e9c96
* statusbar was used to test and improve some BStatusBar behavior
* lagging_get_mouse demonstrates what the problem is with older
applications using synchronous GetMouse() calls without specifying
that they actually don't care about mouse history.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26327 a95241bf-73f2-0310-859d-f6bbb57e9c96
to draw a bitmap and a B_MIXED_COLORS pattern. This shows that most of the
Haiku drawing modes are off of what the BeBook documents them to be and also
shows that B_OP_SELECT is actually broken under R5.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26074 a95241bf-73f2-0310-859d-f6bbb57e9c96
get drawn into a window with random colors. With that one can for example add
code to the app_server or interface kit classes that push through rects or
regions to see what exactly is going on in drawing operations. Code examples
of how to use are at the top of the file. Has fixed window dimensions though
as I was lazy :-)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25855 a95241bf-73f2-0310-859d-f6bbb57e9c96
Firefox. It stores the active clipping region of a view when Draw() is
invoked, and uses that for asynchronous drawing. The test already shows
a couple of problems. When PushState() / PopState() is used, it is not
equivalent to ConstrainClippingRegion(&someRegion) /
ConstrainClippingRegion(NULL). Another problem shows when adding delays
(currently disabled), there should not be any difference, regardless of
how much delay is inserted into the asynchronous drawing.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25150 a95241bf-73f2-0310-859d-f6bbb57e9c96
command line.
* Using this, you can easily reproduce #1765 on BeOS, too. Ie. while it's also
a bug in Haiku, this also shows a conceptional problem with the way LaunchBox
switches to the current workspace. Stipp, any reason why it doesn't just let
the window appear on all workspaces?
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24630 a95241bf-73f2-0310-859d-f6bbb57e9c96
since the changes to where the mime database write support lives
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23629 a95241bf-73f2-0310-859d-f6bbb57e9c96
