A few visual tests of clipping composition with different combinations of
layers with and without the inverse bit.
Change-Id: Icddb377508733463378f93b24075fd06e54ef2cb
Reviewed-on: https://review.haiku-os.org/c/haiku/+/4454
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
On x86_64, the KERNEL_ARCH should really be "x86_64", but it was "x86"
as the architecture sources/headers directory is shared between 32 and 64 bit.
Should not be a functional change on any platform outside x86_64.
So many Jamfiles to search through...runs also, but there
are lots of graphical glitches
Change-Id: Ibf9e64566a5b8c5742792ac9b1b0f9ccc6693c8d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1753
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
It's quite annoying to install the new debug_server and test with a
crashing app everytime. So add a DebugWindow app that just shows the
debug window and returns the result.
Change-Id: I7238057a508871ce3fffc493cb73126eb852d99e
Reviewed-on: https://review.haiku-os.org/c/1460
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
We now remove it manually for one library to break the dependency loop.
Change-Id: I24061705b4656d444bbe7b4a6af836303f44c020
Reviewed-on: https://review.haiku-os.org/c/873
Reviewed-by: Stephan Aßmus <superstippi@gmx.de>
The test app currently shows a number of problems in text rendering
* Above a certain font-size, there is no glyph caching, which
also means there is no sub-pixel filtering. It is actually
the same problem right now for all vector-drawing. It uses the
sub-pixel rendering pipeline, but without any filtering.
* This test feels very sluggish. Something is going on which seems
to be very unoptimized. To be observed when resizing the window
and causing redraws.
* Overlapping glyphs are handled wrongly in B_OP_COPY mode. The
problem is that glyphs are drawn one at a time, but B_OP_COPY
also draws the background color. In case some pixels already
drawn with the text color by one glyph are drawn again by the
next glyph, but with the background color, then it looks like
gaps in the text. This problem has always existed. With the
double filtering that was recently fixed, it was just especially
visible, since, due to the smearing, it was much more likely that
there were extra background pixels at the left side of glyphs.
(Right side, too, but without visual effect.) Of course not
completely transparent pixels, those are not drawn, but almost
transparent pixels.
Change-Id: If590a4c93983c5a3ff0772c19074c408be8e1e74
Reviewed-on: https://review.haiku-os.org/c/871
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>
* Add a note about a workaround that can be used to run
test_app_server, which currently fails to load the right
library libbe_test.so. The bug should be fixed too, but
with this, it can at least be used until then.
* Expects its config files in /boot/home/test_launch.
* Uses standard I/O, and is always in user mode.
* Also added test_launch_roster command that is able to talk to the test
server like it does to the real thing.
- Interface Kit tests use a View class which is not BView, and has no
SetViewUIColor.
- Libexpat is now in a separate package.
- Shouldn't we add this to the buildbots so we can cath the breakage?
- As suggested by Ingo, add libshared.a to the architecture name map.
This allows it to be linked by its short name like other frequently
used libraries.
- Adjust all Jamfiles referencing the lib accordingly.
Conflicts:
src/kits/interface/PicturePlayer.cpp
src/servers/app/ServerPicture.cpp
In addition, the following files were also adapted to master branch
BPicture changes during the merge:
src/kits/interface/PicturePlayer.h
src/servers/app/PictureBoundingBoxPlayer.cpp
* Make test-app_server work again in a launch_daemon environment
* test_registrar gets a separate signature and port name again so the
host system can distinguish it from the system registrar
* AppServer is normally a BServer now, however, there can't be two
BApplications in one team. A class TestServerLoopAdapter is added,
which becomes the base class of AppServer instead of BServer when
compiling for libbe_test. It's an adapter class which looks towards
AppServer as it if was a BServer, but internally it is derived from
MessageLooper (like the old AppServer before the transition to
BServer).
This way, AppServer can stay a BServer in normal builds and it also
avoids having to use too many #ifdefs to distinguish the two
versions.
* Add new methods
BView::BeginLayer(uint8 opacity)
BView::EndLayer()
* All drawing between begin and end of a layer is redirected onto an
intermediate bitmap. When ending the layer, this bitmap is
composited onto the view with the opacity given when the layer was
started.
* Layers can be nested arbitrarily and will be blended onto each
other in order. There can also be any arbitrary interleaving of
layer begin/end and drawing operations.
* Internally, drawing commands are redirected into a BPicture between
BeginLayer and EndLayer (but client code need not know or care
about this). Client code can also start/end other BPictures while
inside a layer.
* Uses the PictureBoundingBoxPlayer to determine the size of the
layer bitmap before allocating and drawing into it, so it does not
allocate more memory than necessary and -- more importantly -- it
will not alpha-composite more pixels than necessary.
* Drawing mode is always set to B_OP_ALPHA, blend mode to
(B_PIXEL_ALPHA, B_ALPHA_COMPOSITE) while inside layers. This is
necessary for (a) correct compositing output and (b) for
redirection of drawing into the intermediate bitmap, which uses the
renderer_region offset (in B_OP_COPY, the Painter does not use the
AGG renderer methods, it directly accesses the pixel data. This
would access out-of-bounds without the offset, so B_OP_COPY cannot
be allowed.)
To ensure these modes aren't changed, BView::SetDrawingMode()
and BView::SetBlendingMode() are ignored while inside a layer.
* The main motivation behind this new API is WebKit, which internally
expects such a layers functionality to be present. A performant and
reusable implementation of this functionality can only be done
server-side in app_server.
* app_server currently does not have any real unit tests, making
changes more difficult and riskier. A new directory unit_tests with
a test add-on is added in app_server's tetsts directory to hold
future unit tests.
* Add test for SimpleTransform class
* Better reflects the purpose of the class: an interface for things
in which we can draw (e.g. a View)
* Accordingly rename OffscreenContext to OffscreenCanvas
* This allows to remove a job in the init phase already, if its
condition is not only constant, but also failing.
* Also removed the special Job::LaunchInSafeMode() method; this is now
done using the conditions (the config option no_safemode remains,
though).
* Allows to conditionally (or unconditionally) launch targets.
* Including tests for the settings parser.
* FirstBootPrompt is now launched when deemed necessary (as in
the Bootscript).
* Admittedly not very well thought out, but it should be good
enough for now; it doesn't really make sense to initialize jobs
that is never run due to failed conditions.
* Job, and Target now have a common base class BaseJob that deals
with the conditions.
* Moved related test code from DriverSettingsMessageAdapterTest to the
SettingsParser class.
* Added SettingsParserTest class -- most tests already succeed, but not
all; support for the flattened "not" is not working yet.
* Instead of faking libstdc++.so from libstdc++.a, use libstdc++.so
from the gcc_syslibs build feature for everything except x86_gcc2.
* Use libgcc_s.so from the gcc_syslibs build feature for everything but
x86_gcc2 (which still carries libgcc as part of libroot.so).
* Drop filtering of libgcc objects for libroot, as that is no longer
necessary since we're only using libgcc-as-single-object for libroot
with x86_gcc2, where the filtered object file doesn't exist. Should
the objects that used to be filtered cause any problems as part of
libgcc_s.so, we can always filter them as part of the gcc build.
* Use libsupc++.so from the gcc_syslibs build feature for everything but
x86_gcc2.
* Adjust all Jamfiles accordingly.
* Deactivate building of faked libstdc++.so for non-x86-gcc2. For
x86_gcc2, we still build libstdc++.so from the sources in the Haiku
source tree as part of the Haiku build .
* Put gcc_syslibs package onto the image, when needed.
* Add a vertical linear gradient. This bypasses AGG and uses a faster
code path, which works.
* Add gradients drawn in a ClipToPicture() context. This uses an
* unpacked scanline rasterizer, which works.
This hints to the problem being the use of a packed scanline rasterizer,
with agg gradients touching the alpha channel.
Coldfirex