is defined to 1; this allows asserting the read lock case, too.
* Added ASSERT_{READ|WRITE}_LOCKED_RW_LOCK() macros. The read assertion is only
working when KDEBUG_RW_LOCK_DEBUG is defined to 1, the write assertion works
always.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26686 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
* Added "syslog" command that dumps the contents of the syslog ring buffer into
KDL. Use the '-n' option to only show what hasn't been sent to the syslog
daemon yet.
* When entering the kernel debugger, the current thread ID and name are also
printed (not only the current CPU).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26684 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
by myself:
* renamed xsi_do_undo() to xsi_sem_undo() (there is more to XSI than sems).
* Fixed coding style issues in sys/sem.h and xsi_sem.cpp.
* Added _kern_*() syscall prototypes to syscalls.h.
* Added a TODO in xsi_sem.cpp and xsi_semaphore.h about moving union semun to
a shared header.
* Made the team::xsi_sem_undo_requests int32 - due to padding, it would have
needed 4 bytes anyway; please always use specific types over int/short/long.
* xsi_sem_undo() now checks if it needs to do anything - the calls in team.cpp
no longer needs to do this.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26676 a95241bf-73f2-0310-859d-f6bbb57e9c96
don't check any longer whether the given number is the address of a
condition variable in the global hash table; we just assume it is a
valid condition variable pointer.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26674 a95241bf-73f2-0310-859d-f6bbb57e9c96
so we need to check for that explicitly in the CObjectDeleter and
MethodDeleter cases.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26673 a95241bf-73f2-0310-859d-f6bbb57e9c96
vnode (falling back to synchronous I/O if the io() is not supported).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26672 a95241bf-73f2-0310-859d-f6bbb57e9c96
FS shell. The latter two lack an implementation yet, though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26670 a95241bf-73f2-0310-859d-f6bbb57e9c96
before?! Is about 4% faster than before. If anyone sees a way to make it faster
yet, please shoot! I can watch movies fullscreen on a 2 GHz Core 2 Duo in
VESA with bilinear scaling, but it would be nice to use less CPU... :-)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26667 a95241bf-73f2-0310-859d-f6bbb57e9c96
const BBitmap* bitmap, BRect bitmapRect, BRect viewRect, uint32 options).
Only option so far is B_FILTER_BITMAP_BILINEAR.
* BView::DrawBitmap[Async](const BBitmap* bitmap, BRect viewRect) was accessing
the bitmap pointer without checking it. Would therefore crash when passing
NULL, unlike the other methods.
* The BPicture code already reserved room for the BBitmap flags, but did not
store the actual flags and neiter use them for anything. Since the bitmap
data is stored anyways, the bitmap creation flags do not matter. So I reused
this for the new bitmap drawing options.
* Rewrote Bitmap.h and removed the B_BITMAP_SCALE_BILINEAR flag again.
* Tried to optimize Painter::_DrawBitmapBilinearCopy32() a little by giving
the compiler better hints. There seems to be a marginal, possibly imagined
speed increase < 0.05 ms. ;-)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26665 a95241bf-73f2-0310-859d-f6bbb57e9c96
that from the start. Please review for possible binary compatibility problems!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26663 a95241bf-73f2-0310-859d-f6bbb57e9c96
need to be interpolated because the x index is right on a source pixel. This
prevents the out of bounds access for the second to last row in the last
column. Also the rightmost pixels where incorrectly interpolated with the
leftmost pixels of the next row. And it actually helps speed too of course.
* Added a compile time option to allocate the filter weighting and index
caches on the heap instead of the cache. I am not sure if it is a problem
though, I recall Haiku threads have quite a lot of stack space. The needed
memory depends on the target size. For a screen with 1920x1200, the caches
would need 12.5 KB. Allocating them on the stack saves about 0.2 ms on my
test system.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26656 a95241bf-73f2-0310-859d-f6bbb57e9c96
to provide asynchrounous (or only synchronous, if asynchronous is not
supported) I/O request support. It will eventually replace
{read,write}_pages(). None of the FS implementations implement them
yet.
* Implemented some support functions for request-based I/O. File system
implementations can use do_fd_io() which passes an I/O request to the
layer responsible for a given FD, and do_iterative_fd_io(), which
translates a request for a file to subrequests for the underlying
device and passes them on. Both fall back to synchrounous processing
when the io() hook is not supported.
Furthermore added vfs_synchronous_io() which should be handy for the
devfs to perform io_requests synchronously for devices that don't
support the io() hook.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26655 a95241bf-73f2-0310-859d-f6bbb57e9c96
added an IORequest::Init() version with that parameter. This makes
splitting an iovec array into IOBuffers/IORequests easier.
* Added IORequest::CreateSubRequest(). It creates and adds an IORequest
that covers a part of the range of the parent request, but may use
another file offset. This will be used e.g. in the way that the parent
request describes an I/O operation for a file while its subrequests
describe the same operation translated to the underlying device.
* Added IORequest::DeleteSubRequests(), which does the obvious. It's
also invoked in the destructor.
* Added method for iterating through subrequests.
* Made IORequestChunk::{Set,Reset}Status() protected. For both
subclasses some locking is needed (though different locking), so we
rather make this more explicit.
* Added IORequest::SetStatusAndNotify(), which is SetStatus() +
NotifyFinished() with proper locking.
* Changed the I/O request finished and iteration callback signatures.
The finished callback has got an additional "status" argument, since
the request itself may already be inaccessible at the time the
callback is executed.
* Changed IORequest::NotifyFinished(). The policy is now that if the
iteration callback fails, the method will do the finished
notifications. This simplifies things in the iteration callbacks.
* Fixed bug in IORequest::_CopyPhysical(): It didn't take into account
that the physical buffer could not be page aligned.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26654 a95241bf-73f2-0310-859d-f6bbb57e9c96
B_OP_COPY which is about 2.4 times faster than the AGG version (but of
course less generic). The speed up is even better for smaller and even
scales.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26652 a95241bf-73f2-0310-859d-f6bbb57e9c96
an invalid page state was supplied. The comment was misleading too,
as the pages weren't reserved upfront.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26650 a95241bf-73f2-0310-859d-f6bbb57e9c96
* When drawing BBitmaps with scaling in the app_server, use a bilinear
filter when a bitmap has this flag set. (Hope nobody objects, otherwise
I can revert or improve this. Performance can certainly be improved, since
the AGG implementation is too generic. But that goes for the nearest
neighbor implementation as well.)
* Flags are uint32, fix app_server side code to declare them correctly. Use
appropriate link methods in BBitmap and ServerApp.
* Enable the BeOS compatibility mode for B_RGB32 (works just like B_RGBA32
in B_OP_ALPHA mode).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26649 a95241bf-73f2-0310-859d-f6bbb57e9c96
* adjust all drivers to take that into account
* fix UpdateText() signature in JSDSlider to avoid warning
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26648 a95241bf-73f2-0310-859d-f6bbb57e9c96
- For simplicity we'll force using only insn common to 020 to 060, mostly to avoid unimplemented floating point ops in the kernel.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26647 a95241bf-73f2-0310-859d-f6bbb57e9c96
children of the device and recreate them so that they are updated to any
changes. MainWindow::_Initialize() was using a stale BPartition pointer
after calling CommitModifications(). Now the pointer is recreated from the
id. Should fix#2548. Untested.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26643 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Renamed sModifiedTemporaryPages to sModifiedNoSwapPages to better
express what this variable is about.
* Changed tracking of sModifiedNoSwapPages. It really counts
non-swappable pages only, now (if swap support is enabled).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26641 a95241bf-73f2-0310-859d-f6bbb57e9c96
