* Unfortunately, there are remaining issues, but this is something I need to
discuss with Stippi: B_OP_COPY does not work as expected due to anti-aliasing
anymore, but there is no replacement one could possibly use to get the desired
effect without having to clear the background every time.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33676 a95241bf-73f2-0310-859d-f6bbb57e9c96
them more BeOS compatible while still keeping them somewhat flexible.
* _GrowStream() did actually not check if the double indirect region was already
filled up - this caused it to overwrite innocent memory. This fixes the bug
Rudolf showed me on this laptop that happened while copying a large file.
* Loosened file size restriction on a heavy fragmented disk: the indirect block
does not require a minimum array size anymore; before, you just couldn't let
a stream grow into the indirect range if it couldn't allocate NUM_ARRAY_BLOCKS
(4) blocks in a row. This considerably reduced the maximum file size in this
case.
* Removed no longer valid TODO.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33675 a95241bf-73f2-0310-859d-f6bbb57e9c96
to avoid recurring problems during migration of subversion checkouts
(restored binary files that were garbled by subversions during checkout)
* added appropriate svn:mime-type property for problematic (binary) files
* removed a single (mistyped) svn:mimetype property
* dropped svn:eol-style property for cleanup (they all contained 'native')
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33670 a95241bf-73f2-0310-859d-f6bbb57e9c96
a button or within the bar background within the timeout for the repeat-thread,
the thread would exit and there would be no repeating. I think there is still
a race condition somewhere since I managed to see it stall once again, probably
because it locks the looper twice in the loop...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33666 a95241bf-73f2-0310-859d-f6bbb57e9c96
manager and inform it that the video target, ie the view will be gone. The
Controller needs to use the SetTo() method in order to actually close down
the nodes properly in the destructor. Otherwise asynchronous threads will use
the BMediaFile and tracks after it has been deleted (until the NodeManager
destructor is executed).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33662 a95241bf-73f2-0310-859d-f6bbb57e9c96
Restore ignoring the BIOS provided width and height in case the timings
suggest a bigger dimension. Also re-add the corresponding comment. Should
fix#4810 and might affect #4807 as well.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33652 a95241bf-73f2-0310-859d-f6bbb57e9c96
turned on. That should explain Bruno's problems to get debug output from an
accelerant. Thanks to Michael for the hint!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33651 a95241bf-73f2-0310-859d-f6bbb57e9c96
high contention of the read lock (I experimented with the VM page mapping
lock)), it actually hurt the compile performance pretty obviously.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33647 a95241bf-73f2-0310-859d-f6bbb57e9c96
Quad are all reported as "Core 2", because the CPU count is already reported
separately.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33646 a95241bf-73f2-0310-859d-f6bbb57e9c96
makes the reader case a lot less expensive, and should relieve the thread
spinlock contention a bit.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33643 a95241bf-73f2-0310-859d-f6bbb57e9c96
that. But I didn't think of any better solution either... Hopefully these are
all, but I will find out once I built a complete image.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33641 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Rewrote Devices application. -> Thanks a bunch!! Nice work!
* Put Devices onto the image.
Changes by myself:
* Merge some code from the old "preflet" which the new app still relied on.
* Fixed some coding style issues. I didn't review all of the code yet, though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33640 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Check for overflows in memory allocation. If someone happened to (erroneously)
try to allocate a negative amount of memory we could overflow and crash
because of the sizes getting messed up.
* Review and update the alignment logic which was a bit broken for the huge
allocation case (reaching the area threshold). Also assert the results so
next time this will be easier to spot.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33638 a95241bf-73f2-0310-859d-f6bbb57e9c96
I've now removed that code, and factored out a retrieve_current_mode()
function that can work on head A and B.
* This fixes Adrien's flickering problem on his laptop - I can't find the
bug ticket, though. Hopefully it does not break other laptop chips. Testing
would be welcome, as I don't have any other machine here.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33633 a95241bf-73f2-0310-859d-f6bbb57e9c96
