InvalidateLayout().
This fixes#1461, the bug appeared because DraggableContainerIcon uses a special trick, involving changing the resizing
mode, to get the total width of the menu items. (see tracker/ContainerWindow.cpp line 479)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25948 a95241bf-73f2-0310-859d-f6bbb57e9c96
We now keep track of a lower bound as to when the list should scale
itself back down. When increasing the list size, we double the current,
with the lower bound set to 1/4 of the current size, not allowing it to
go any smaller than the block size. These combined allow us to do very
cheap tests to see if an operation requires a resize at all, and minimize
how often the list actually needs to be resized, since the difference in upper
and lower bounds prevents bouncing back and forth between a size in the case
of adding/removing an item while close to a boundary. All in all this should
make BList noticably more scalable when doing large numbers of add/remove
operations.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25946 a95241bf-73f2-0310-859d-f6bbb57e9c96
Replace bsd types for haiku ones
-ve-This line, and those below, will be ignored--
M l2cap/l2cap_command.cpp
M l2cap/l2cap.h
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25945 a95241bf-73f2-0310-859d-f6bbb57e9c96
- As more cleaning still needs to be done regarding this subject the ticket is not yet closed
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25944 a95241bf-73f2-0310-859d-f6bbb57e9c96
- Tailor a bit the main module
- Fix definitions in the main header
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25943 a95241bf-73f2-0310-859d-f6bbb57e9c96
When changing to icon mode with a size other than 32 (ie: kScaleIconMode) PoseView calls Refresh() and all the poses are
removed and loaded again (PoseView.cpp line 1995). This called AddPoses but didn't check for ShowDiskIcon(). The Disks icon
was shown on startup though, since Tracker uses another code path when starting (caching?).
This fixes#1833.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25941 a95241bf-73f2-0310-859d-f6bbb57e9c96
- do not count usb headers as part of count returned by write(), else we might end up writing more than the passed amount :)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25939 a95241bf-73f2-0310-859d-f6bbb57e9c96
* The audio and video panes refered to the OS as "BeOS", now it's "Haiku".
Thanks!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25936 a95241bf-73f2-0310-859d-f6bbb57e9c96
state of the painter without restoring it afterwards (HighColor and
DrawingMode).
This function is only used in decorators, but as such it could lead to
strange effects. When clicking and holding the close button on the R5
MidiPlayer for example, the background of the scope would suddenly become
the color of the close buttons middle line. As the drawing mode was also
overwritten this could probably have lead to text rendering issues when
zooming applications. As I didn't find a easy way to reproduce such a thing,
this is only theory though.
* Implement the missing IsExclusiveAccessLocked() method in the DrawingEngine
which is not used at the moment. If corresponding debug output is generated
though, it reveals possible locking issues with CopyRegion().
* Remove an empty line in the LineArrayData struct.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25934 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Cleaning up and refactoring the OpenSoundNode code to use a single coding
style and be less C-like in many places.
* Fixed quite a few memory leaks in OpenSoundNode.
* Removed large chunks of inactive code originating from the MultiAudioNode.
* Transfered some functionality into NodeInput and NodeOutput, could be more.
* No functional changes.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25932 a95241bf-73f2-0310-859d-f6bbb57e9c96
the delta.
For example, MoveBy(-0.5, 0.0) would do nothing in this case:
roundf(150.0 - 0.5) = 150.0, when rounding the delta it gives the
expected value: roundf(150.0 + roundf(-0.5)) = 149.
On the other hand, BView::ResizeBy was doing it right, and this
explains the bug in Cortex (#333). Cortex was doing
scrollBar->MoveBy(-0.5,0) then scrollBar->ResizeBy(0.5,0) and the
inconsistency lead to the visual bug. (see StatusView::MouseMoved())
This fixes#333. The bug was strange to reproduce since sometimes the
point received in MouseMoved would be "some_integer+0.5" values
sometimes just integral. This has still to be investigated though not
problematic here anymore. See cortex/RouteApp/StatusView.cpp line 222.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25930 a95241bf-73f2-0310-859d-f6bbb57e9c96
only the decoder structure is now initialized per instance, this should
be better (thread safe).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25925 a95241bf-73f2-0310-859d-f6bbb57e9c96
in Cortex). This happened only when needing a tabbed view. It will now return a view with the
most fitting size. This fixes#597
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25923 a95241bf-73f2-0310-859d-f6bbb57e9c96
BIOS owned flag and clear all possibly enabled SMIs. It seems to be common
practice to just ignore this error case, probably because there are enough
broken BIOSs out there that do not correctly hand over the controller.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25918 a95241bf-73f2-0310-859d-f6bbb57e9c96
BasicTerminalBuffer. It synchronizes this buffer with the actual
terminal buffer and uses it for drawing. This does significantly
decrease the time the terminal buffer is locked by the window thread,
and avoids the necessity to do invalidations in Draw() when the
terminal buffer changed in the meantime.
* When the view detects heavy scrolling of the terminal buffer due to
lots of continued output, it throttles redraws to one every 0.1s. The
detection condition might need some fine-tuning -- it's probably a bit
too strict for most situations.
I guess I'm done now with optimizations. After testing on real iron for
the first time, I'm a little impressed. In the "time seq ..." speed
competition Haiku's Terminal easily beats Konsole by 10 to 20% for 80x25
and by factor 3+ for full screen. And if I interpret the results
correctly 90% of the time is actually used by "seq" itself which seems
to be about 5 times slower than under Linux.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25917 a95241bf-73f2-0310-859d-f6bbb57e9c96
we now double/halve the current size of the list, starting with the constructor blocksize as a baseline.
This has the net effect that when doing large numbers of inserts/removes, the number of resize operations
needed scales logarithmically to the number of operations, which should yield a decent performance
improvement in such cases.
Review welcome. This does not yet affect ticket #2363 that I'm aware of, as I'm currently in the process
of attempting to find a copy of said app to test with.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25916 a95241bf-73f2-0310-859d-f6bbb57e9c96
handover indeed worked. Doesn't really matter though, as we reset anyway,
just not twice in the success case.
* Disable all interrupts and clear any pending active interrupts just after
taking over the controller. This might fix bug #2361.
* Also trace output when the ownership change is successful.
* Don't disable interrupts during reset.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25915 a95241bf-73f2-0310-859d-f6bbb57e9c96
Temporarily removed the VESA driver, as long as it only builds on x86.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25913 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added a ResizeTo() version that allows to set the history capacity at
the same time.
* Added a SynchronizeWith() method that allows synchronizing with (a
part of) another buffer.
* Fixed TODO in _Scroll().
* Improved the dirty region update code in _Scroll(). It would in
certain (not exactly uncommon) situations needlessly invalidate the
whole screen.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25912 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Introduced a small (64 byte) buffer for the parser thread. Instead of
directly reading single characters out of the reader buffer, we read
a full parser buffer and process the characters from the parser
buffer. Thus _NextParseChar() could be inlined, since it merely
consists of a conditional method call and an access to the parser
buffer, now.
* Improved the locking of the terminal buffer. Instead of unlocking and
relocking after every multi-byte char or escape sequence, we only
unlock while refilling the parser buffer.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25911 a95241bf-73f2-0310-859d-f6bbb57e9c96
- spice up select_oss_rate() to use the passed rate as hint, and also check in the rate array, or the range for cards with the FREERATE cap.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25906 a95241bf-73f2-0310-859d-f6bbb57e9c96
