* Does anybody know why HaikuBuildCompatibility.h is not included for tools when
compiled on BeOS/Dano?
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21688 a95241bf-73f2-0310-859d-f6bbb57e9c96
It now at least frees all memory when the object is deleted. Reported by Jonas - thanks!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21687 a95241bf-73f2-0310-859d-f6bbb57e9c96
of the active ViewLayer is now always mirrored in the Painter instance
of a ServerWindow, so that it doesn't need to be synced on every drawing
command, this was previously incomplete for font handling
* removed the DrawState parameter from all the DrawingEngine functions
* adjusted ServerWindow and ServerPicture accordingly
* made sure that string related functions used by non-drawing related
parts (ServerApp, Decorator) don't interfere with the current drawing
state
* moved AS_SYNC handling from _DispatchViewMessage to _DispatchMessage,
it is actually a window message and doesn't require fCurrentLayer to
be valid
* fixed bug #1300, fCurrentLayer was not updated when a ViewLayer was
deleted by client request which happened to be fCurrentLayer (I am now
handling it so that the parent becomes the current layer, could be
wrong)
* AGGTextRenderer is no longer using it's own scanline, which should save
a few bytes RAM, the Painter already had such an object
* StringWidth() in AGGTextRenderer is now taking the escapement_delta into
account
* Painter::StrokeLine() doesn't need to check the clipping as much, since
that is already done in DrawingEngine
* if a ServerWindow message is not handled because fCurrentLayer is NULL,
a reply is sent in case the messages needs it (client window could
freeze otherwise, waiting for the reply for ever)
* removed unused AS_SET_FONT and AS_SET_FONT_SIZE
* added automatic RGBColor -> rgb_color conversion to RGBColor.h
* minor cleanup for 80 char/line limit
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21685 a95241bf-73f2-0310-859d-f6bbb57e9c96
be nonstatic. Moved TermParse under Shell, Removed some parameters
passing around from TermWindow/TermView/TermParse. Now TermParse threads are
started when the shell is attached to a TermView. Might still be
improved.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21680 a95241bf-73f2-0310-859d-f6bbb57e9c96
the length of the attribute name in GetNext() for attributes that are actual
inodes. Found by Robert Szeleney, thanks!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21674 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Did anyone see the coding style violations in this file??? :-)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21673 a95241bf-73f2-0310-859d-f6bbb57e9c96
* More conditional debug code (wrt page transitions between caches).
* Replaced debugger command cache_chain by a nicer cache_tree.
* While handling a soft fault: When we temporarily unlock a cache, it
can theoretically become busy. One such occurrence is now handled
properly, two more panic() ATM, though should be fixed.
* When merging caches, we do now always replace a dummy page in the
upper cache, not only when the concurrent page fault is a read fault.
This prevents a page from the lower (to be discarded) cache from still
remaining mapped (causing a panic).
* When merging caches and replacing a dummy page, we were trying to
remove the dummy page from the wrong cache (causing a panic).
The Haiku kernel seems now to run shockingly stable. ATM, we have more
than two hours uptime of a system booted and running over network. We
didn't manage to get it down by fully building Pe, downloading, unzipping,
and playing with various stuff. Someone should finally fix all those app
server drawing bugs, though (hint, hint! ;-)).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21672 a95241bf-73f2-0310-859d-f6bbb57e9c96
Fixed off-by-one error in the b+ tree code splitting a node, which could
result in a read beyond the block bounds thus causing a page fault. Was
nicely reproducible when unzipping big archives. Now bug #1003 seems to
be fixed for real.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21671 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Also eat B_INTERRUPTED on sendto()/recvfrom(). The net stack is
interruptable in principle, but our disk device operations shouldn't.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21670 a95241bf-73f2-0310-859d-f6bbb57e9c96
I "ported" the region implementation from XOrg to work on BRegion data.
This resulted in pretty much the same code structure as before, with
RegionSupport.cpp containing the messy details. Only now it _is_ really messy
from a code beauty point of view. I didn't exactly feel like cleaning it
up right now... but I guess I will have to.
So what does this mean - our BRegion implementation was very slow (no offense!),
and on top of that it scaled very badly with more and more rects. The new
implementation seems to be on par with the very fast R5 implementation and
the data looks exactly the same too. BRegion is very performance critical
for the app_server, and I cannot wait to try this on my slow computer...
Some changes are noteworthy: The right and bottom coordinates of
BRegion internal data are now exclusive! I inherited that from the
XOrg implementation and didn't feel like changing the code, seeing it
is probably tested quite well. The conversion is handled transparently.
Secondly, constructing a BRegion with just one rect is not invoking
malloc anymore for the member data, this makes it much more efficient
to use temporary BRegions with just one rect, both externally and internally
in the BRegion implementation.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21665 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Increased network timeouts. A single lost ARP request would cause
finding the server to fail.
* Consequently set the sockaddr_in::sin_len field.
* Added write support.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21664 a95241bf-73f2-0310-859d-f6bbb57e9c96
misrouting when the net server set up the loop device, thus stopping the
net boot process.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21662 a95241bf-73f2-0310-859d-f6bbb57e9c96
Answered Travis question. We save the registers from the exception
causing the double fault in the double fault iframe, since otherwise it
would contain only completely unusable values.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21661 a95241bf-73f2-0310-859d-f6bbb57e9c96
Don't print a message that couldn't be written to the syslog to stdout.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21659 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Refactored RescanDiskSystems(). Pulled out a function
_RescanDiskSystems() that scans for either file or partitioning
systems. RescanDiskSystems(), which scanned for file systems only
before, is used from the constructor as well (open_module_list()
works in the early boot process since a while).
* Made InitialDeviceScan() and partition scanning safe to be called a second
time. We call it directly after the kernel has mounted the boot
volume, now, so that additional disk systems from the boot volume have a
chance to recognize previously unrecognized partitions. This is a
temporary change only; later the disk device manager shall
automatically find out when new disk systems/devices/whatever are
available.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21655 a95241bf-73f2-0310-859d-f6bbb57e9c96
When loading the driver settings the defaults don't override the
previous variable values anymore.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21654 a95241bf-73f2-0310-859d-f6bbb57e9c96
mounted later by the AutoMounter's initial mounting loop.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21653 a95241bf-73f2-0310-859d-f6bbb57e9c96
crashed. Turns out a call I use, BFont.GetBoundingBoxesForStrings was not
implemented, and worse, there was bug in how the ServerApp read the parameters
from the link. This was easy to fix to stop app_server from crashing, but it
took me a while to figure out how to implement GetBoundingBoxesForStrings.
Anyhow I implemented an initial version which works fairly well for now. I
don't think the width is quite right, but it seems to match StringWidth(), so
I guess it is good enough for now.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21652 a95241bf-73f2-0310-859d-f6bbb57e9c96
a string
* fixed profiling of message processsing in ServerWindow (didn't take batch
processing into account)
* accelerated ViewLayer::RebuildClipping() by a factor of two by avoiding
BRegion::Exclude(clipping_rect) for each child, and instead building
one region with all children, and excluding that. RebuildClipping() is
quite a common operation and is quite slow for views with many children
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21646 a95241bf-73f2-0310-859d-f6bbb57e9c96
one, not the one intended for the double fault) since r20131. IOW double faults are
now working again.
* Minor cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21645 a95241bf-73f2-0310-859d-f6bbb57e9c96
not need to be "set" (transfered from the "current" view to the painter)
for each singly drawing command. Now, painter is synchronized whenever
the client changes the drawing state of the current view, or when the
current view changes.
* the screen offset of the current view has become part of the Painter state,
in the PatternHandler. This fixes a bug in which moving or scrolling a view
which used patterns for drawing, resulted in visual glitches (seams in the
pattern).
NOTE: this patch is a bit work in progress, most importantly, it is not
complete with regards to text rendering. More specifically, the server
applications and other parts of the appserver might set a font on the Painter
and this might mess up the synchronization. But this happens on the Desktop's
Painter instance (only?), and so it is not a problem. I did observe some
drawing bugs with this patch though, so bug reports are welcome, particularily
how to reproduce these bugs reliably.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21643 a95241bf-73f2-0310-859d-f6bbb57e9c96
looking up the color in the pattern, this is needed because before,
patterns were always drawn with the virtual origin in screen coordinate
space, but they need to be drawn with view coordinate origin taken into
account (will be implemented in a forthcomming commit)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21639 a95241bf-73f2-0310-859d-f6bbb57e9c96
FontFamily.h/cpp (just for the reason that this is how we do it mostly
everywhere)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21637 a95241bf-73f2-0310-859d-f6bbb57e9c96
