system given by BBitmap::Bounds() when drawing bitmaps (Haiku copies
this bug)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18022 a95241bf-73f2-0310-859d-f6bbb57e9c96
in my branch, but in the main trunk. That should do no harm though.
* Made LayoutTest1 build for libbe_test and added it to the
install-test-apps target.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17982 a95241bf-73f2-0310-859d-f6bbb57e9c96
on R5 it seems a reply to a asynchronously-forwarded synchronous BMessage is the same as when no forward happens
I didn't test on Haiku, but I suspect the behavior is different, especially a _previous_ is added as for asynchronous BMessages
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17814 a95241bf-73f2-0310-859d-f6bbb57e9c96
(by linking them to haiku's libsocket.so and libbind.so). This in turn greatly
simplifies building their respective userland version as they now are the same
as the standard version.
- added ping and traceroute to install-userland-networking pseudotarget
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17717 a95241bf-73f2-0310-859d-f6bbb57e9c96
userland-networking files into a convenient place for easier testing:
+ net_server_driver and net_stack_driver are installed to
/boot/home/config/add-ons/kernel/drivers/bin and ../dev/net
+ net_stack_tester, ifconfig, arp and route are installed to
$(HAIKU_TEST_DIR)/kits/net/userland
+ libsocket, libnet, libbind and libnetapi are installed to
$(HAIKU_TEST_DIR)/kits/net/userland/lib
+ userland add-ons are installed to
$(HAIKU_TEST_DIR)/kits/net/userland/add-ons/obos_network
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17701 a95241bf-73f2-0310-859d-f6bbb57e9c96
log). Still doesn't seem to work correctly, though (but it's definitely
getting closer :-)).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17560 a95241bf-73f2-0310-859d-f6bbb57e9c96
environment: actually build it! :-)
Next step: fix the Jamfile to create the symlink to userland "obos_network" add-ons.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17520 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Fixed Jamfile (was set to only support libbe_test).
* Fixed warnings.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17457 a95241bf-73f2-0310-859d-f6bbb57e9c96
this is what bash is currently using (we're supposed to be posix compatible after all)
success on R5, R5 setjmp.h; fail on R5, Haiku setjmp.h (could be expected)
to be tested: on Haiku, R5 & Haiku setjmp.h
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17430 a95241bf-73f2-0310-859d-f6bbb57e9c96
source file.
* An overlay is now also hidden in case its is removed from the window.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17209 a95241bf-73f2-0310-859d-f6bbb57e9c96
ViewLayer (for example, fixes NetPositive rendering
HTML with a background image)
* use BRegion pool everywhere in ViewLayer
* WindowLayer update sessions distinguish between
different reasons for the update: exposed and requested -
on expose updates, the view backgrounds are cleared
immidiately (as on R5), to keep the time previous stuff
keeps showing as short as possible, while on requested
updates, the background clearing is delayed until the
client draws something, to keep the time until the client
fills a view with content as small as possible to reduce
flickering (might need more work, could be buggy yet)
* HWInterface and DrawingEngine support delayed syncing to
the graphics hardware at least for FillRect/Region. The
speed up gained by this is minor though.
* HWInterface cursor rendering uses a bit of rounding to
avoid the slight transparent shadow around the cursor
(I don't know if it is fully correct though, at least the
shasow disappeared)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17172 a95241bf-73f2-0310-859d-f6bbb57e9c96
to cut down on BRegion related allocations, cannot really tell
if it speeds things up
* used the new BRegion pool in WindowLayer and ViewLayer whereever
a BRegion was used on the stack
* fixed the debugging stuff in MultiLocker - it will get you into
the debugger if you
- try to nest read locks
- try to write lock when your are a reader already
- don't match up nested locks when your a writer
-> but only if you #define DEBUG 1 in the .cpp, is off by default now
* went over WindowLayer, ServerWindow, Desktop and a few other places
and fixed the locking for use with the MultiLocker, the "a reader can
not become a writer" is especially tricky, feel free to review the
changes
* activated the MultiLocker, I tested this quite a bit, if there are
problems simply turn on DEBUG and you should drop into the debugger
right where the problem is... hope all is good
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17046 a95241bf-73f2-0310-859d-f6bbb57e9c96
Also note that BeOS doesn't seem to pick up the cursor this way, it only
works when we're doing this later (ie. in MouseMoved() or Pulse()).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16959 a95241bf-73f2-0310-859d-f6bbb57e9c96
Note, it looks like we translate the cursor shape differently than R5
(according to the docs, black is always opaque and ignores the transparency
bits).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16958 a95241bf-73f2-0310-859d-f6bbb57e9c96
Jérôme Duval