the better idea after all. The snoozing won't add an additional delay, if the
polling was already slow. Have not tested in VMWare myself, as I don't have a
working installation.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29436 a95241bf-73f2-0310-859d-f6bbb57e9c96
rid of the vnode count hash map and the mount vnode maps. Furthermore it will
allows us to easily associate a file cache with each node.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29435 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Updated copyright section.
* Fixed border mis-alignment of buttons and group view.
* Fixed#3528 by checking the current clipping region which tells us if
windows overlap. Don't display the popup menu then.
* Removed some superfluous calls.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29430 a95241bf-73f2-0310-859d-f6bbb57e9c96
HashMap and HashSet classes to use the kernel utils OpenHashTable instead.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29429 a95241bf-73f2-0310-859d-f6bbb57e9c96
audio playback with frequent glitches. I am testing with HDA and have
perfect audio now. The only remaining problem is the drop-sample
resampling in the system mixer, which gives a somewhat metallic sound.
* Removed hardcoded values from preferred format and used them if
the consumer supplies wildcard values. Since the system mixer supplies
wildcards for all those values, this change does not have any effect
for now. The code is more correct, though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29422 a95241bf-73f2-0310-859d-f6bbb57e9c96
of the audio group. This is supposed to keep the latency about the same
regardless of sample rate and lessen the requirements on the system
performance when using higher sample rates. Currently the multi-audio
addon uses the highest available rate.
* Added TODO about the highest sample rate seemingly being forgotten in one
place.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29421 a95241bf-73f2-0310-859d-f6bbb57e9c96
- Pe - 2.4.1 built in Haiku gcc2
- BeZillaBrowser -- built in Haiku gcc4
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29420 a95241bf-73f2-0310-859d-f6bbb57e9c96
1) When searching the area for a place to allocate the next command, the case of the first command being the same as the last command (as is the case after adding the first message) was not correctly considered. This prevented a given area from ever containing more than one command.
2) The size of a command was incorrectly word-aligned. Rather than aligning to 32-bit boundaries, the size was truncated to between 1-3 bytes, leading to command corruption once multiple messages were in the area, eventually causing registrar to crash while retrieving the messages.
Combined these two changes result in us no longer constantly allocating/destroying areas during heavy node monitor activity.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29417 a95241bf-73f2-0310-859d-f6bbb57e9c96
fixes the high CPU usage when using USB mice. I experimented with transfers
scheduled at fixed intervals, and with using a fixed pause between transfers.
The fixed pauses, though much less sophisticated, give the smoothest drawing
in WonderBrush. ;-)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29413 a95241bf-73f2-0310-859d-f6bbb57e9c96
RecursiveLock in the kernel.
* Several adjustments according to UserlandFS header changes.
* Re-added reiserfs to image.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29410 a95241bf-73f2-0310-859d-f6bbb57e9c96
- Banlance the process of retrieving the remote names, which is blocks the Window Looper, as get remote name is an expensive operation.
Now it waits half second between each operation which gives a better feeling(without using extra thread, that will come when there is an standard barberpole)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29403 a95241bf-73f2-0310-859d-f6bbb57e9c96
file cache are missing yet -- requires some refactoring in Volume.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29402 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Changed cursor keys to their respective arrow symbol
* As mmadia reminded me: since we cannot use Mozilla's Trademarks I renamed
everythig firefoxy to BeZillaBrowser.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29398 a95241bf-73f2-0310-859d-f6bbb57e9c96
pixels than can possibly be visible. Clients may pass very large
view rects to layout a zoomed in bitmap. This doesn't only speed things
up, but also avoids a stack overflow in the app_server, as reported in #3166.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29397 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Combine the many small areas created by the Firewire bus manager
into one larger one. Needs further testing. Supposed to fix#1519.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29396 a95241bf-73f2-0310-859d-f6bbb57e9c96
