* This does not yet close bug #233, but could also be a reason for this crash.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16851 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
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
into account when copying to the same color space (new code isn't that fast,
but it works).
* BBitmap::ImportBits() did not take the specified offset into account at all.
This fixes bug #313.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16812 a95241bf-73f2-0310-859d-f6bbb57e9c96
in HWInterface::_DrawCursor(). Axel, even though we
understood the problem, we didn't really fix it back
then: When the sync flag was set to true in
BView::SetViewCursor(), the link was only flushed,
which means that the function still returned before the
ServerWindow thread processed the message. This means
that the race condition (the cursor being immediately
deleted after SetViewCursor returns, which might be
processed in ServerApp thread before the SetViewCursor
request in ServerWindow thread) still existed. I changed
SetViewCursor now to do a real sync (wait for the
ServerWindow reply) before returning. The alternative
would be to set the fPendingViewCursor flag in either case.
Anyhow, I could reproduce the error quite reliably before
this change, and now it is gone... here is to hoping!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16809 a95241bf-73f2-0310-859d-f6bbb57e9c96
these should be public (they don't match any basic Be naming style
anyway :-).
* Put the code that's used by the app_server where it's needed.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16804 a95241bf-73f2-0310-859d-f6bbb57e9c96
this one, maybe we should find out what it does, make it public and
document it.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16801 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Extended ConvertBits() to properly handle negative offsets and overlapping lines
* Implemented blitting the software cursor to the bitmap returned from ReadBitmap()
Note: In the future we will have to directly use the final graphics buffer for ReadBitmap() if we want DirectWindow output too (R5 includes it). I don't know how R5 handles the hardware cursor though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16766 a95241bf-73f2-0310-859d-f6bbb57e9c96
window from being freed on Quit(). There still is a memory leak within
StressTest, though - but it's pretty tiny now.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16753 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
to the ServerApp, instead of being dropped - the window link is now updated
correctly in that case.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16750 a95241bf-73f2-0310-859d-f6bbb57e9c96
likewise, while the user moves a window around, programmatical moves are ignored
as well.
This fixes bug #264.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16743 a95241bf-73f2-0310-859d-f6bbb57e9c96
useful... so I removed it
* fixed memory leak with SetPulseRate(0), fPulseRunner is now
properly freed in the Window destructor
* fTitle is now freed as well
* fix some potential leaks in BView destructor as well
I wrote a stress test app, which I'm soon going to commit as well...
it shows that not all memory leaks are fixed by this patch, I could
use some help with this...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16713 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Text height was computed with roundf() instead of ceilf() (which makes more sense).
* Minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16706 a95241bf-73f2-0310-859d-f6bbb57e9c96
* No longer changes the arguments in case of an error.
* Takes communication errors more gracefully.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16703 a95241bf-73f2-0310-859d-f6bbb57e9c96
and from big endian - this fixes our StyledEdit not being able to read files
written under BeOS and vice versa.
* Made UnflattenRunArray() more robust against missing fonts; the style is now
tried to be preserved. Note that BeOS doesn't maintain the "face" field in
the flattened run arrays correctly.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16701 a95241bf-73f2-0310-859d-f6bbb57e9c96
that, anyway. This should fix the broken resize behaviour of the slider
(as, for example, seen in DiskProbe).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16689 a95241bf-73f2-0310-859d-f6bbb57e9c96
in your FrameResized() method - exposed by the TextView auto resizing feature).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16687 a95241bf-73f2-0310-859d-f6bbb57e9c96
take an empty region as an indication to remove the clipping, but on R5,
this is actually valid... this patch fixes the problem
* the ViewState::clipping_region is now consistently used to memorize
the user defined clipping of the view state instead of being sometimes
used to cache the current view clipping
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16656 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Also, the selection should be updated correctly when items are removed.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16652 a95241bf-73f2-0310-859d-f6bbb57e9c96
Stefano Ceccherini