system given by BBitmap::Bounds() when drawing bitmaps (Haiku copies
this bug)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18022 a95241bf-73f2-0310-859d-f6bbb57e9c96
in my branch, but in the main trunk. That should do no harm though.
* Made LayoutTest1 build for libbe_test and added it to the
install-test-apps target.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17982 a95241bf-73f2-0310-859d-f6bbb57e9c96
source file.
* An overlay is now also hidden in case its is removed from the window.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17209 a95241bf-73f2-0310-859d-f6bbb57e9c96
ViewLayer (for example, fixes NetPositive rendering
HTML with a background image)
* use BRegion pool everywhere in ViewLayer
* WindowLayer update sessions distinguish between
different reasons for the update: exposed and requested -
on expose updates, the view backgrounds are cleared
immidiately (as on R5), to keep the time previous stuff
keeps showing as short as possible, while on requested
updates, the background clearing is delayed until the
client draws something, to keep the time until the client
fills a view with content as small as possible to reduce
flickering (might need more work, could be buggy yet)
* HWInterface and DrawingEngine support delayed syncing to
the graphics hardware at least for FillRect/Region. The
speed up gained by this is minor though.
* HWInterface cursor rendering uses a bit of rounding to
avoid the slight transparent shadow around the cursor
(I don't know if it is fully correct though, at least the
shasow disappeared)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17172 a95241bf-73f2-0310-859d-f6bbb57e9c96
to cut down on BRegion related allocations, cannot really tell
if it speeds things up
* used the new BRegion pool in WindowLayer and ViewLayer whereever
a BRegion was used on the stack
* fixed the debugging stuff in MultiLocker - it will get you into
the debugger if you
- try to nest read locks
- try to write lock when your are a reader already
- don't match up nested locks when your a writer
-> but only if you #define DEBUG 1 in the .cpp, is off by default now
* went over WindowLayer, ServerWindow, Desktop and a few other places
and fixed the locking for use with the MultiLocker, the "a reader can
not become a writer" is especially tricky, feel free to review the
changes
* activated the MultiLocker, I tested this quite a bit, if there are
problems simply turn on DEBUG and you should drop into the debugger
right where the problem is... hope all is good
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17046 a95241bf-73f2-0310-859d-f6bbb57e9c96
Also note that BeOS doesn't seem to pick up the cursor this way, it only
works when we're doing this later (ie. in MouseMoved() or Pulse()).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16959 a95241bf-73f2-0310-859d-f6bbb57e9c96
Note, it looks like we translate the cursor shape differently than R5
(according to the docs, black is always opaque and ignores the transparency
bits).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16958 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
even though we might need something similar, we can't use it (since it was
based on BGet++).
* Removed BGet++, it's not used anymore.
* Removed ServerMemIO class, was never used.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16830 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
* Fixed another BMessageRunner leak.
* Added an optional second parameter which you can use to limit the run time
of the app.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16764 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
free to continue (it would be nice to be notified before, though, in case
I get to it again in the next weeks).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16561 a95241bf-73f2-0310-859d-f6bbb57e9c96
app_server...
If you like to use it, define USE_DIRECT_WINDOW_TEST_MODE in the haiku_app_server
Jamfile.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15504 a95241bf-73f2-0310-859d-f6bbb57e9c96
using the clipping info from a BDirectWindow... I made it so that the window
used stays on top always, until I can think of something better. The other
problem is that you should not move the window, since Painter doesn't update
it's pointer into the frame buffer.
* Now the test environment is running at pretty much the same speed as it would
under Haiku, completely by-passing the BeOS app_server. It shows that Painter
needs to be optimized for writing to graphics memory, and also that we need to
figure out a way to distribute update sessions more equally. What happens is
this: The first invalidation of a window triggers an update on the client
side... the client cannot keep up with drawing, since it is pretty much
blocked all the time because the desktop thread moves a window and because
the clipping constantly changes. In the meantime, new update request are
added to the pending session because the client has still not finished with
the current session. Only when things settle a bit, the next update session
can be startet. On the bright side of things, the earlier problems with
scrolling seem to be fixed for good.
* some documentation updates on Painter
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15478 a95241bf-73f2-0310-859d-f6bbb57e9c96
inline. Commented undefined virtual methods. BBitmapBuffer is still used, so
is ViewHWInterface.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15472 a95241bf-73f2-0310-859d-f6bbb57e9c96
* added B_SAME_POSITION_IN_ALL_WORKSPACES for the build under Haiku (and libbe_test)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15437 a95241bf-73f2-0310-859d-f6bbb57e9c96
The buttons now span over the full width (and will be adapted on resize).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15274 a95241bf-73f2-0310-859d-f6bbb57e9c96
B_QUIT_REQUESTED is no longer forwarded to the application too early.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15271 a95241bf-73f2-0310-859d-f6bbb57e9c96
which supports ReadLockWithTimeout()
* commented the code in many more places
* understood the problem of making the read/write locking
work: While it would be possible for each window to
remove the processed region from the global dirty region
in read lock mode (since it is guaranteed not remove
a region not intersecting with its own visible region),
multiple window threads can still not do this at the same
time, since BRegion itself is not threadsafe of course.
* I need to figure out a way for the window threads to be
able to access and modify all needed data in read only mode,
I think this means to divide the global dirty region into
each window again, so that each window thread can simply
clear its own dirty region instead of excluding it from
the global region. Yeah, that might work.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15230 a95241bf-73f2-0310-859d-f6bbb57e9c96
color. In BeOS, a view gets a MouseMoved() with B_ENTERED_VIEW when the window is
opened under the mouse cursor (not yet in Haiku).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15227 a95241bf-73f2-0310-859d-f6bbb57e9c96
* views are now correctly clipped when they are
(partly) hidden under their parent(s)
* removed fIsTopView, the top view in a window
simply has no parent
* introduced WindowLayer::CopyContents() which
blits part of the contents to another location,
while moving that part in the dirty regions. Since
this is currently used from the Desktop thread,
messing with the update session dirty regions
requires now to lock the clipping
* that feature is now used for blitting a view to its
new location in ViewLayer::MoveBy(), which
works for right and/or bottom aligned views just fine
* I left the global dirty region in Desktop for now,
moving it into each WindowLayer gave quite a slowdown
and caused all kinds of other problems.
* a view is now cleared to the background color right
before the first drawing command from the client
is executed for that view, this reduces flickering
a lot because the content is drawn much more shortly
after the background is cleared.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15201 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Introduced WindowLayer::Hide/Show/IsHidden()
* Made ViewLayer::IsHidden() more robust.
* Same with ::TopLayer()
* modified a little ViewLayer::MoveBy() - prepared it to work with
hidden/shown code that will come soon; only calculate dirty regions if a
ViewLayer has a parent, otherwise the move action is pointless.
* Did the same thing with ::MoveBy() except for the parent stuff - no need
for a parent on resizing.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15193 a95241bf-73f2-0310-859d-f6bbb57e9c96
* adds concept of a current and a pending update session
* marks dirty views being resized or moved
Some aspects of the design are buggy, others are slow, but I'm
approaching a good overview of what's needed and what problems
lurk in the details. In the end I hope to make things work fast
and correctly at all times. Adi or anybody else, feel free to
join the efforts.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15158 a95241bf-73f2-0310-859d-f6bbb57e9c96
an app_server code. It's always up-to-date as it just reads the header
directly.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15148 a95241bf-73f2-0310-859d-f6bbb57e9c96
* now with actual view layers inside the windows
* implemented the resize modes (from Adis code)
* windows have resize handles and more correctly
clip the views inside
* bringing windows to front or sending them behind all others
* one active window, the others are inactive
* with and without focus follows mouse mode
* bugs:
- the region marked dirty when views are
resized is not correct yet
* todo:
- move the dirty region from being managed by the
desktop to being managed in each window (and being
local too)
- scrolling
- hiding/showing of windows and views
I plan to extend this to fully simulate asynchronous
drawing from clients, to see any problems before
using this in the real server one day.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15132 a95241bf-73f2-0310-859d-f6bbb57e9c96
Note, I temporarily kept the Utils.h in, because I have other local changes to be
committed soon (sorry for this, but it shouldn't harm).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15043 a95241bf-73f2-0310-859d-f6bbb57e9c96
distribute any messages to the clients yet.
* removed the working thread from RootLayer - for now, its event handlers are
still called using input filters in the new event dispatcher, though (to
get things started).
* ServerApp is now using a BMessenger to identify its client, and no longer
stores the port/token separately.
* the input_server handshake is a bit simpler now, as it can now just reply
to the app_server message, removed unused code from ServerProtocol.h
* calmed down the MultiLocker (it always printed thread statistics on startup,
because it's compiled in debug mode).
* removed the cursor thread stuff from AppServer.cpp
* the new event dispatcher now uses a cursor thread when supported (only in
native mode, not in the test environment), although it improves cursor
movement under Qemu, the effect is not as good as expected - this might
need some more investigations (might just be a thread priority problem).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15012 a95241bf-73f2-0310-859d-f6bbb57e9c96
Notice the doubled key events in case the upper right BTextControl with
B_KEYBOARD_EVENTS has focus in BeOS...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14982 a95241bf-73f2-0310-859d-f6bbb57e9c96
have different token spaces depending on the scope of its objects.
* removed TokenHandler - we're now using BTokenSpace instead.
* removed unused IPoint.cpp - if we ever need it again, it can still easily be
resurrected from the dead.
* some cleanup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14925 a95241bf-73f2-0310-859d-f6bbb57e9c96
* no more libappserver.so - this breaks the "Appearance" application, but that
has to be fixed some day later.
* the drawing stuff is now built in its own directory as libasdrawing.a.
* TEST_MODE defaults to "0" if not defined yet - it's overridden in the test
build now, not in the main build.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14896 a95241bf-73f2-0310-859d-f6bbb57e9c96
Library names are now mapped for all targets but "host" (not only for
"haiku") -- added one more level of indirection to achieve that.
(TARGET_LIBRARY_NAME_MAP -> *_LIBRARY_NAME_MAP_*).
* Renamed build/HaikuBuildCompatibility.h to BeOSBuildCompatibility.h
(auto-included when compiling something that uses the Be API for platform
"host" on anon-BeOS platform), and introduced build/HaikuBuildCompatibility.h,
which can be included when compiling something that can be built for both,
Haiku and BeOS compatible platforms.
* Introduced libhaikucompat.a, a library that adds a few functions existing
under Haiku, but not under BeOS.
* New rule AddSubDirSupportedPlatforms.
* Renamed libopenbeos.so to libbe_haiku.so.
* Introduced new target platform "libbe_test", which is basically equivalent
to a BeOS compatible host platform target, with the exception, that instead
of the host platform's libbe.so a special build of Haiku's libbe.so
(libbe_haiku.so (formerly known as libopenbeos.so)) is used. Furthermore
Haiku's public app, interface, storage, and support kit headers are used
when compiling. This replaces the less nice way in which the test app server
and applications for this test environment were built.
When building for platform "libbe_test", the library name "be" is
autotranslated to "libbe_haiku.so". Thus most applications don't need
special fiddling when them building them for the app server test environment;
usually an "AddSubDirSupportedPlatforms libbe_test ;" will suffice.
* Reduced the dependencies of <syscalls.h> and fixed problems caused by this
(e.g. source files not including the needed headers directly).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14749 a95241bf-73f2-0310-859d-f6bbb57e9c96
Removed that ambiguous second copy constructor and moved push state functionality
into a separate PushState() method.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14679 a95241bf-73f2-0310-859d-f6bbb57e9c96
Added a small test application for view states. Right now, it only tests scaling - which
doesn't seem to work yet at all.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14673 a95241bf-73f2-0310-859d-f6bbb57e9c96
It doesn't build though, as SimpleTest doesn't seem to work anymore.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14644 a95241bf-73f2-0310-859d-f6bbb57e9c96
Added libmessagetest.so to test specifically the BMessage implementation.
Fixing some other unit tests along the way - quite many of them are borken.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13911 a95241bf-73f2-0310-859d-f6bbb57e9c96
src/tests/servers/app/Jamfile. This makes the original Jamfile much cleaner.
Note that you now have to maintain two Jamfiles when adding/removing sources.
The test app server is called haiku_app_server, its library
libhaikuappserver.so. I adjusted a few paths in scripts accordingly, but
I may have missed something elsewhere.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13858 a95241bf-73f2-0310-859d-f6bbb57e9c96
user_shutdown_reply reliably crashes the app server when pressing one
of its buttons (during the shutdown process at least).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13540 a95241bf-73f2-0310-859d-f6bbb57e9c96
the registrar no longer depends on the app_server to be running.
Added a "run_haiku_registrar" tool that is now used in the various "run" scripts.
It only start the registrar on demand, ie. if it's not yet running.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13493 a95241bf-73f2-0310-859d-f6bbb57e9c96
- by holding the secondary mouse button pressed one can draw random lines
so you can see what regions are invalidated durring a move, resize or
scroll operation
- clicking the third mouse button issues a redraw, WITHOUT a region
rebuild action (this is to force a redraw because the window does not
redraw itself, I've been lazy :-)
- playing with the mouse wheel results in the layer under mouse cursor
being scrolled on the y-axis.
- fixed redraw and copyRegion of this sandbox app. They work correctly
now.
- TODO: fix a clipping bug which appears when moving a layer arround.
--This line, and those below, will be ignored--
M newClipping/MyView.cpp
M newClipping/main.cpp
M newClipping/MyView.h
M newClipping/Layer.cpp
M newClipping/Clipping.proj
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12895 a95241bf-73f2-0310-859d-f6bbb57e9c96
* further optimized clipping
* implemented support for B_FULL_UPDATE_ON_RESIZE flag
* added support for hidden layers
* implemented Show()/Hide()
* implemented Invalidate(region)
remains to be done:
* fully redraw center and right alligned layers on a resize operation.
* additional testing.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12798 a95241bf-73f2-0310-859d-f6bbb57e9c96
for the default button does), but at least, the window itself is updated now :-)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12739 a95241bf-73f2-0310-859d-f6bbb57e9c96
with respect to whether the delivery still works when the port is full.
It seems to do (now).
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11139 a95241bf-73f2-0310-859d-f6bbb57e9c96
