built for UserlandFS. The latter appears to be working fine.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20347 a95241bf-73f2-0310-859d-f6bbb57e9c96
add-ons accordingly and removed the syscall.
* Removed send_notification().
* Reimplemented notify_listener(). It used the unimplemented
send_notification(). Now it has a chance to work. Note that
notify_listener() is obsolete. I would already have removed it, if
there weren't lots of FS implementations still using it (Hint!).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20329 a95241bf-73f2-0310-859d-f6bbb57e9c96
* For B_EQUALS queries the first match would be skipped.
* Exact entry name matches were broken, since the used NameIndex::Find()
expected null-terminated keys with the \0 included in the key length
while it was fed only the raw string length.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20306 a95241bf-73f2-0310-859d-f6bbb57e9c96
Currently Archiving the Unflattened picture doesn't work, and it hangs
inside assert_local_copy(), waiting for the app_server reply...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20280 a95241bf-73f2-0310-859d-f6bbb57e9c96
the stream after Flattening. Now Unflattening works, but the picture
seems to be empty
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20270 a95241bf-73f2-0310-859d-f6bbb57e9c96
doesn't show up, that means something is still broken in Flatten() or
Unflatten()
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20267 a95241bf-73f2-0310-859d-f6bbb57e9c96
Haiku's userlandfs. I wouldn't expect them to work very well yet, though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20255 a95241bf-73f2-0310-859d-f6bbb57e9c96
headers dir are used instead. Added missing <new> inclusion.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20253 a95241bf-73f2-0310-859d-f6bbb57e9c96
reason, don't see the obvious. Well, or doesn't if absent...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20230 a95241bf-73f2-0310-859d-f6bbb57e9c96
reference without being a referring entry.
* Reworked entry renaming. We do now remove the original entry first and
then create a target entry. Renaming directories didn't work before since
there would temporarily have been two links to a directory, which is not
allowed. Replacing an entry was also broken: The original entry was not
removed. Due to reversing the entry creation/deletion order we also do no
longer suffer from the Tracker bug, that entries would disappear from
queries when being renamed.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20204 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added missing locking in the query hooks.
* Added live query support similarly as done in BFS:
- Volume manages a doubly-linked list of live queries.
- Volume::UpdateLiveQueries() invoked from several places where it makes
sense (standard indices, Attribute::WriteAt(), and
BVolume::NodeAttributeRemoved()) notifies the live Query objects.
- Adjusted Query to be able to deal with hard links. Unfortunately Tracker
is a bit broken with respect to hard links, particularly in the query
windows. E.g. only one entry referring to a node is shown, and the renaming
method RamFS uses (link new entry, then unlink old one) causes renamed
entries to fall out of queries, even if they should still be in.
(Want a bug report for this, Axel? :-P)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20203 a95241bf-73f2-0310-859d-f6bbb57e9c96
not-yet-mounted ClientVolume was not removed, which could cause query requests
to crash the server.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20184 a95241bf-73f2-0310-859d-f6bbb57e9c96
modifications for BONE/Dan0). As test file systems are included:
* A Reiser FS 3.6 read-only implementation (should be a virtually unmodified
version released as 1.0.1 on BeBits).
* A not quite finished RAM FS.
* A BeOS-specific networking FS. It works well as far as I've tested it, but
is utterly insecure at the moment and missing nice GUI preflets. It's also
amazingly slow which, I hope, is mainly caused by the UserlandFS layer and
BeOS R5 net server. We'll see as soon as it can be compiled for the Haiku
kernel.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20171 a95241bf-73f2-0310-859d-f6bbb57e9c96
Added stop_console(), a shutdown procedure for consoled (for cases
when it executes a single command only, like the debugger).
Unfortunately the system kind of freezes when the keyboard is attempted
to be closed. Entering KDL still works. It always shows consoled's
keyboard reader thread running somewhere in the endless loop in
keyboard_read() in the keyboard driver. The main thread is ready in
delete_sem() invoked by keyboard_close(), not advancing any further when
continuing the system. Apparently the scheduler needs a good spanking.
:-P
Generally it also doesn't help that the keyboard driver code is
completely cookie ignorant.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20135 a95241bf-73f2-0310-859d-f6bbb57e9c96
then the overhead of a call into libroot, and finally the overhead of a syscall
(using is_computer_on).
The numbers are totally abysmal right now. :(
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20070 a95241bf-73f2-0310-859d-f6bbb57e9c96
broken (see bug #996), but less broken than Be's.
Also the Linux implementation is not perfect, as test 4 reveals: it waits for a
child with a certain process group, even if there is no child around anymore (because
the last child changed its process group. However, it will still return (and report
the correct error code) once this child exits.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20009 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Fixed comment, as Haiku now behaves properly at least for most cases :-)
* Style guide update.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20007 a95241bf-73f2-0310-859d-f6bbb57e9c96
wait() should return with an error when the process has no children
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19983 a95241bf-73f2-0310-859d-f6bbb57e9c96
another test that doesn't work on BeOS, dunno why, but who cares...).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19767 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Implemented a fibo_fork which uses fork() instead.
* Both tests can pretty easily let the kernel crash!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19764 a95241bf-73f2-0310-859d-f6bbb57e9c96
due to problems with wait_for_thread().
* Minor cleanup to the Jamfile.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19757 a95241bf-73f2-0310-859d-f6bbb57e9c96
still tons of OpenBeOS references in various source files (especially in
comments), but this was more overt.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19461 a95241bf-73f2-0310-859d-f6bbb57e9c96
* there are now two hash tables: one for connections, and one for ports
* the first one is used to find the endpoint for incoming connections
* the latter is used to check if the address to bind() to is still available
(incl. support for SO_REUSEADDR, and SO_REUSEPORT). Specialising an existing
socket is not allowed, though; wildcard sockets need to be started last.
* the TCPConnection class now has a pointer to the next endpoint with the
same port number - this list is scanned for the existing bound sockets
on that port.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19416 a95241bf-73f2-0310-859d-f6bbb57e9c96
* socket_recv[from]() now accept a NULL buffer in case there was nothing to read.
* the tcp_tester's server thread now actually reads the data it receives.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19400 a95241bf-73f2-0310-859d-f6bbb57e9c96
* cancel_timer() cancels a timer, and returns true if the timer was running
* is_timer_active() determines if the timer is currently running or not.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19393 a95241bf-73f2-0310-859d-f6bbb57e9c96
but use integer coordinates. These are now used in ViewLayer for the
coordinate system (layout, scrolling offset, view bitmap layout)
* modest performance improvements by inlining some very often used
methods, and by preventing to go down the entire layer tree too often,
for example InvalidateScreenClipping was always called in the deep
mode, therefor it is save to assume that the tree does not have to
be traversed as soon as the clipping is already invalid
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19390 a95241bf-73f2-0310-859d-f6bbb57e9c96
that the terminal's color is changed when the app is quit (or interrupted).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19381 a95241bf-73f2-0310-859d-f6bbb57e9c96
* The MTU returned by the domain was too large; it should already take the
IP header into account.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19373 a95241bf-73f2-0310-859d-f6bbb57e9c96
receiving thread. While this steals away a test case for now (dead lock), it will
allow to reorder packets in a better way.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19363 a95241bf-73f2-0310-859d-f6bbb57e9c96
* you can now instruct it to drop specific packets
* you can now also define a round trip time for the packets
* added a "send" command to send arbitrarily sized buffers over TCP.
Not surprising, the current implementation of TCP doesn't do anything with
those (other than crashing as soon as you try to send data).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19362 a95241bf-73f2-0310-859d-f6bbb57e9c96
this option now using the "dprintf" command
* Added dump_block() function to kernelland_emu
* Added tcpdump-like output to tcp_tester for each TCP segment, lines from the
server are red, lines from the client are black.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19334 a95241bf-73f2-0310-859d-f6bbb57e9c96
actual versions cannot work in userland.
* Extended the tcp_tester to be able to connect and quit connections.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19330 a95241bf-73f2-0310-859d-f6bbb57e9c96
Locking GL context is better, even if it's not mandatory under Be's R5 OpenGL stack.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19259 a95241bf-73f2-0310-859d-f6bbb57e9c96
a window to the PictureTest which should show the svg lion, but doesn't
work yet for some reason
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19243 a95241bf-73f2-0310-859d-f6bbb57e9c96
able to connect to itself, this should already work at this point.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19234 a95241bf-73f2-0310-859d-f6bbb57e9c96
a set of commands that can be thrown at a listening and a client end of a TCP connection.
This will allow for an easier and faster implementation of the TCP module, as well as
regression tests, etc.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19232 a95241bf-73f2-0310-859d-f6bbb57e9c96
could get modules whose initialization failed.
* Fixed how built-in modules are initialized.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19231 a95241bf-73f2-0310-859d-f6bbb57e9c96
yet
added to the image) written by Marc Flerackers, for a SVG -> BPicture
importer, will be used to show the SVG lion and butterfly (included in
this commit)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19177 a95241bf-73f2-0310-859d-f6bbb57e9c96
draws some stuff directly, the other draws the same stuff using a
BPicture. This shows that BPicture doesn't support BShapes yet, and it
has some problems with pen size.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19129 a95241bf-73f2-0310-859d-f6bbb57e9c96
Reported by Robert Szeleney.
* Fixed an endian problem in write_stat() in the R5 version of BFS.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19121 a95241bf-73f2-0310-859d-f6bbb57e9c96
the data stream area is reused as link data in this case.
Reported by Robert Szeleney.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19120 a95241bf-73f2-0310-859d-f6bbb57e9c96
Haiku image) revealed a problem with that change:
* If the root node only contained a single entry it was freed instead of just making
it a leaf node - that could produce an invalid b+tree (could only happen with
attribute or index trees, as directories always contain '.' and '..').
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19006 a95241bf-73f2-0310-859d-f6bbb57e9c96
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
while working on the app_server should less likely happen - hopefully.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16836 a95241bf-73f2-0310-859d-f6bbb57e9c96
* 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
even though we might need something similar, we can't use it (since it was
based on BGet++).
* Removed BGet++, it's not used anymore.
* Removed ServerMemIO class, was never used.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16830 a95241bf-73f2-0310-859d-f6bbb57e9c96
all teams in serveral server areas, and instead of having to eventually clone
them all several times in BBitmap, we now have one or more areas per team,
and BBitmap will only clone areas once if needed. As a side effect, this
method should be magnitudes faster than the previous version.
* This method is also much more secure: instead of putting the allocation
maintenance structures into those everyone-read-write areas, they are now
separated, so that faulty applications cannot crash the app_server this
way anymore. This should fix bug #172.
* Freeing memory is not yet implemented though! (although all memory will
be freed upon app exit)
* There are now 3 different bitmap allocation strategies: per ClientMemoryAllocator
(ie. via ServerApp), per area (for overlays, not yet implemented), and using
malloc()/free() for server-only bitmaps.
* ServerBitmap now deletes its buffers itself.
* Cleaned up BBitmap and BApplication a bit.
* The test environment currently doesn't build anymore, will fix it next.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16826 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Fixed another BMessageRunner leak.
* Added an optional second parameter which you can use to limit the run time
of the app.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16764 a95241bf-73f2-0310-859d-f6bbb57e9c96
connection.
StressTest now detects this case and quits those windows.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16752 a95241bf-73f2-0310-859d-f6bbb57e9c96
message they passed to a BMessageRunner object.
* Added note about the ownership of the message to the BMessageRunner
documentation.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16751 a95241bf-73f2-0310-859d-f6bbb57e9c96
$ /boot/home/develop/haiku/generated/objects/haiku/x86/debug_1/tests/system/kernel/port_close_test_1
created port 2269
write port result 0x00000000 (No Error)
write port result 0x00000000 (No Error)
close port result 0x00000000 (No Error)
write port result 0x80001200 (Bad port ID)
port_buffer_size -2147479552 (0x80001000) (Bad semaphore ID)
read port code 1234, size 10 (0x0000000a) (Unknown Error (10))
port_buffer_size -2147479552 (0x80001000) (Bad semaphore ID)
read port code 5678, size 20 (0x00000014) (Unknown Error (20))
should block now
port_buffer_size -2147479552 (0x80001000) (Bad semaphore ID)
$ /boot/home/develop/haiku/generated/objects/haiku/x86/debug_1/tests/system/kernel/port_close_test_2
created port 2270
write port result 0x00000000 (No Error)
write port result 0x00000000 (No Error)
close port result 0x00000000 (No Error)
write port result 0x80001200 (Bad port ID)
port_buffer_size -2147479552 (0x80001000) (Bad semaphore ID)
read port code 1234, size 10 (0x0000000a) (Unknown Error (10))
port_buffer_size -2147479552 (0x80001000) (Bad semaphore ID)
read port code 5678, size 20 (0x00000014) (Unknown Error (20))
should block now
read port code 5678, size -2147479040 (0x80001200) (Bad port ID)
$ /boot/home/develop/haiku/generated/objects/haiku/x86/debug_1/tests/system/kernel/port_delete_test
created port 2271
write port result 0x00000000 (No Error)
write port result 0x00000000 (No Error)
delete port result 0x00000000 (No Error)
everything should fail now
write port result 0x80001200 (Bad port ID)
port_buffer_size -2147479040 (0x80001200) (Bad port ID)
read port code 0, size -2147479040 (0x80001200) (Bad port ID)
$
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16645 a95241bf-73f2-0310-859d-f6bbb57e9c96
* added two more tests that exhibit the (now fixed) problem in FindLast()
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16586 a95241bf-73f2-0310-859d-f6bbb57e9c96
free to continue (it would be nice to be notified before, though, in case
I get to it again in the next weeks).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16561 a95241bf-73f2-0310-859d-f6bbb57e9c96
in the test environment; the visual glitches should now be fixed.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16368 a95241bf-73f2-0310-859d-f6bbb57e9c96
parameter from a C++ to a C context doesn't work as expected (on x86).
The caller reserves 4 bytes on the stack, but initializes only the
less significant 2 of them, while the callee reads all four bytes.
A symptom was, that one couldn't remove a symlink pointing to a directory.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16352 a95241bf-73f2-0310-859d-f6bbb57e9c96
12 points to make sure it'll look acceptable.
* Fixed direct window rendering by disabling moving the animation area around
(would have to be changed in DirectConnected() as well).
* Refresh and density sliders now ResizeToPreferred().
* Some cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16206 a95241bf-73f2-0310-859d-f6bbb57e9c96
source directory is currently hardcoded in InstallerWindow.cpp, it could be changed in a macro
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16197 a95241bf-73f2-0310-859d-f6bbb57e9c96
The test application lets run a thread at the highest priority that calls
yield all the time - the system stays responsible when it runs, so it seems
to work fine :)
Changed the malloc implementation to use _kern_thread_yield() instead of
snoozing.
We should think about making this call public, too.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16166 a95241bf-73f2-0310-859d-f6bbb57e9c96
implement the B_GET_GEOMETRY command in a usable way. The bfs_shell is
able to play with partition devices under Linux, now.
* Fixed two warnings.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16146 a95241bf-73f2-0310-859d-f6bbb57e9c96
app_server...
If you like to use it, define USE_DIRECT_WINDOW_TEST_MODE in the haiku_app_server
Jamfile.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15504 a95241bf-73f2-0310-859d-f6bbb57e9c96
using the clipping info from a BDirectWindow... I made it so that the window
used stays on top always, until I can think of something better. The other
problem is that you should not move the window, since Painter doesn't update
it's pointer into the frame buffer.
* Now the test environment is running at pretty much the same speed as it would
under Haiku, completely by-passing the BeOS app_server. It shows that Painter
needs to be optimized for writing to graphics memory, and also that we need to
figure out a way to distribute update sessions more equally. What happens is
this: The first invalidation of a window triggers an update on the client
side... the client cannot keep up with drawing, since it is pretty much
blocked all the time because the desktop thread moves a window and because
the clipping constantly changes. In the meantime, new update request are
added to the pending session because the client has still not finished with
the current session. Only when things settle a bit, the next update session
can be startet. On the bright side of things, the earlier problems with
scrolling seem to be fixed for good.
* some documentation updates on Painter
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15478 a95241bf-73f2-0310-859d-f6bbb57e9c96
inline. Commented undefined virtual methods. BBitmapBuffer is still used, so
is ViewHWInterface.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15472 a95241bf-73f2-0310-859d-f6bbb57e9c96
* added B_SAME_POSITION_IN_ALL_WORKSPACES for the build under Haiku (and libbe_test)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15437 a95241bf-73f2-0310-859d-f6bbb57e9c96
The buttons now span over the full width (and will be adapted on resize).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15274 a95241bf-73f2-0310-859d-f6bbb57e9c96
B_QUIT_REQUESTED is no longer forwarded to the application too early.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15271 a95241bf-73f2-0310-859d-f6bbb57e9c96
which supports ReadLockWithTimeout()
* commented the code in many more places
* understood the problem of making the read/write locking
work: While it would be possible for each window to
remove the processed region from the global dirty region
in read lock mode (since it is guaranteed not remove
a region not intersecting with its own visible region),
multiple window threads can still not do this at the same
time, since BRegion itself is not threadsafe of course.
* I need to figure out a way for the window threads to be
able to access and modify all needed data in read only mode,
I think this means to divide the global dirty region into
each window again, so that each window thread can simply
clear its own dirty region instead of excluding it from
the global region. Yeah, that might work.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15230 a95241bf-73f2-0310-859d-f6bbb57e9c96
color. In BeOS, a view gets a MouseMoved() with B_ENTERED_VIEW when the window is
opened under the mouse cursor (not yet in Haiku).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15227 a95241bf-73f2-0310-859d-f6bbb57e9c96
