History log of /haiku/src/tests/servers/app/newerClipping/
Revision Date Author Comments
(<<< Hide modified files)
(Show modified files >>>)
9e54316c 27-Aug-2019 CodeforEvolution <secundaja@gmail.com>

Fix the build of test_app_server on 64bit

So many Jamfiles to search through...runs also, but there
are lots of graphical glitches

Change-Id: Ibf9e64566a5b8c5742792ac9b1b0f9ccc6693c8d
Reviewed-on: https://review.haiku-os.org/c/haiku/+/1753
Reviewed-by: waddlesplash <waddlesplash@gmail.com>

4b7e2196 03-Oct-2013 Ingo Weinhold <ingo_weinhold@gmx.de>

Remove /boot/common for good

* Remove support for the "common" installation location from packagefs,
package kit, package daemon, package managers.
* Rename the B_COMMON_*_DIRECTORY constants referring to writable
directories to B_SYSTEM_*_DIRECTORY.
* Remove/adjust the use of various B_COMMON_*_DIRECTORY constants.
I'm sure some occurrence still remain. They can be adjusted when the
remaining B_COMMON_*_DIRECTORY constants are removed.

3dfd9cb9 16-Jun-2011 Oliver Tappe <zooey@hirschkaefer.de>

Flat commit of all changes from package-management branch in svn

0a6ef817 25-Apr-2008 Stephan Aßmus <superstippi@gmx.de>

I have no idea anymore what I was messing with here, but it looks interesting.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25147 a95241bf-73f2-0310-859d-f6bbb57e9c96

040ce757 13-Dec-2005 Stephan Aßmus <superstippi@gmx.de>

added libbeadapter.so (used by the storage kit and the haiku regisrar) to the test libs, it just went unnoticed before

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15530 a95241bf-73f2-0310-859d-f6bbb57e9c96

e76d86d5 09-Dec-2005 Stephan Aßmus <superstippi@gmx.de>

now directly banging the hardware by using a cloned accelerant, soon to be ported to the app_server test environment. Unfortunately deadlocks most of the time when quitting...

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15462 a95241bf-73f2-0310-859d-f6bbb57e9c96

a825e403 01-Dec-2005 Stephan Aßmus <superstippi@gmx.de>

not in a nice way, but I hope to have fixed the deadlocking problems on program exit

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15279 a95241bf-73f2-0310-859d-f6bbb57e9c96

0bbd104a 01-Dec-2005 Stephan Aßmus <superstippi@gmx.de>

don't allow the top view to be scrolled

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15278 a95241bf-73f2-0310-859d-f6bbb57e9c96

7943e1a8 01-Dec-2005 Stephan Aßmus <superstippi@gmx.de>

scrolling seems to work nicely, dirty regions are tracked fine and shifted along with the scrolling if necessary

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15277 a95241bf-73f2-0310-859d-f6bbb57e9c96

3d05db78 01-Dec-2005 Axel Dörfler <axeld@pinc-software.de>

Fixed compilation (at least under Zeta/Dano).

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15276 a95241bf-73f2-0310-859d-f6bbb57e9c96

727653f7 01-Dec-2005 Stephan Aßmus <superstippi@gmx.de>

implemented invalidation triggered from the client side. 20 clients each displaying an animation in one view at 25 fps leaves the new clipping unimpressed, everything is fluent, also during moving and resizing windows

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15275 a95241bf-73f2-0310-859d-f6bbb57e9c96

8c8275c2 01-Dec-2005 Stephan Aßmus <superstippi@gmx.de>

showing and hiding windows and views works now, views are not so heavily tested, but any problems should be easy to fix. the recursive IsHidden() is now avoided, there is only one recursion now, which is when the hidden status changes. in the simulation, double clicking a window will temporarily hide it and show it asynchronously from the window thread. looks like the locking model works out fine.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15272 a95241bf-73f2-0310-859d-f6bbb57e9c96

d0e89d53 30-Nov-2005 Stephan Aßmus <superstippi@gmx.de>

I couldn't resist playing some more with ezprof. I don't know if I can trust it's results though, revealing as they are. Somebody should explain to me why forgetting a return *this; in an operator= method works in the first place, and why it results in the constructor being called.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15255 a95241bf-73f2-0310-859d-f6bbb57e9c96

c8b8bbfc 30-Nov-2005 Stephan Aßmus <superstippi@gmx.de>

fix the update session operator=, temporarily enabled Flush()ing the underlying BView again in order to not distract with fake drawing bugs

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15252 a95241bf-73f2-0310-859d-f6bbb57e9c96

7fd1af6f 30-Nov-2005 Stephan Aßmus <superstippi@gmx.de>

I did some profiling using Daniel Reinholds ezprof, which is quite nice actually. I optimized a bit, without spending too much time on that yet, and now the clipping is on average 7 times faster than the current app_server (the time spend in the root layer thread)

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15251 a95241bf-73f2-0310-859d-f6bbb57e9c96

7e68917f 29-Nov-2005 Stephan Aßmus <superstippi@gmx.de>

more commenting, if only to clean up my own mind

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15235 a95241bf-73f2-0310-859d-f6bbb57e9c96

1ba9992d 29-Nov-2005 Stephan Aßmus <superstippi@gmx.de>

a views screen clipping does no longer includes the windows actual clipping, only the content clipping, this simplifies some calculations, and avoids invalidating each views screen clipping when the window clipping changes. at any time the views screen clipping is used, we need to watch out for the effective clipping anyways

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15234 a95241bf-73f2-0310-859d-f6bbb57e9c96

312345bc 29-Nov-2005 Stephan Aßmus <superstippi@gmx.de>

with the new design, there is always only one redraw message in the WindowLayers message queue, therefor, ReadLockWithTimeout() is no longer needed, removed RWLocker again as MultiLocker suits our needs.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15232 a95241bf-73f2-0310-859d-f6bbb57e9c96

c63a78aa 29-Nov-2005 Stephan Aßmus <superstippi@gmx.de>

now doing without a global dirty region, and it seems it gained a little speed too, should be easier now to make the multi locker work

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15231 a95241bf-73f2-0310-859d-f6bbb57e9c96

4dd89c69 29-Nov-2005 Stephan Aßmus <superstippi@gmx.de>

* added a multi locker implementation from Ingo Weinhold,
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

b619f15f 28-Nov-2005 Stephan Aßmus <superstippi@gmx.de>

that expensive drawing mode served it's purpose, but it makes it seem like the prototyp is maxing out the CPU again

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15202 a95241bf-73f2-0310-859d-f6bbb57e9c96

748533bb 28-Nov-2005 Stephan Aßmus <superstippi@gmx.de>

figured out and solved several problems:
* 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

12aa597d 27-Nov-2005 Adi Oanca <adioanca@nowhere.fake>

Played a bit :-)
* 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

f5180663 26-Nov-2005 Stephan Aßmus <superstippi@gmx.de>

stress testing. It shows that for 40 open windows, the newerClipping design takes 3.5 times less time in the root layer thread compared to the newClipping design. On average, it is about 8.7 times faster. The goal of the redesign, to move the heavier computation from the root layer thread into each window thread, seems achieved, since even with 100 open windows, moving a window does not start any lagging. By removing the global dirty region in Desktop, I think this can be further improved.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15183 a95241bf-73f2-0310-859d-f6bbb57e9c96

0036cd5d 26-Nov-2005 Stephan Aßmus <superstippi@gmx.de>

I don't want to promise anything but that fix could have been the last remaining bug. Next up is scrolling then showing, hiding, adding and removing layers during runtime... Maybe the simulation can be extended by drawing animations triggered from the client too.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15171 a95241bf-73f2-0310-859d-f6bbb57e9c96

7241178e 26-Nov-2005 Stephan Aßmus <superstippi@gmx.de>

ViewLayers screen clipping is clipped to the parent bounds, but that is only a partial fix and should be done more elegantly. When moving a window, the part that we could blit is certainly not dirty, the pending dirty region that we drag along is clipped to the new visible region of the moved window

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15170 a95241bf-73f2-0310-859d-f6bbb57e9c96

f5552ed0 26-Nov-2005 Stephan Aßmus <superstippi@gmx.de>

this fixes the bugs in the update session region enforcement during client drawing, there is only one bug left now: resized ViewLayers don't invalidate the correct regions (they don't take areas into account that are hidden because the parent is too small)

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15168 a95241bf-73f2-0310-859d-f6bbb57e9c96

987aa5e4 26-Nov-2005 Stephan Aßmus <superstippi@gmx.de>

remaining bugs are with update session region tracking and dirty regions when layers are moved and resized, the window clipping itself seems to work reliably now

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15163 a95241bf-73f2-0310-859d-f6bbb57e9c96

27b74063 26-Nov-2005 Stephan Aßmus <superstippi@gmx.de>

one bug fixed, three more to go

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15162 a95241bf-73f2-0310-859d-f6bbb57e9c96

cfc40fb3 26-Nov-2005 Stephan Aßmus <superstippi@gmx.de>

make client drawing slow again, made client drawing use B_OP_BLEND which shows problems with incorrect clipping during update sessions

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15161 a95241bf-73f2-0310-859d-f6bbb57e9c96

7f705589 26-Nov-2005 Stephan Aßmus <superstippi@gmx.de>

still buggy but less buggy than before, more caching and less overhead

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15160 a95241bf-73f2-0310-859d-f6bbb57e9c96

ff89d51e 25-Nov-2005 Stephan Aßmus <superstippi@gmx.de>

* adds drawing commands from clients
* 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

0cf04412 24-Nov-2005 Stephan Aßmus <superstippi@gmx.de>

please forgive me (next check in when I really coded new stuff)

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15135 a95241bf-73f2-0310-859d-f6bbb57e9c96

420b55f2 24-Nov-2005 Stephan Aßmus <superstippi@gmx.de>

fixed the frame buffer version for real

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15134 a95241bf-73f2-0310-859d-f6bbb57e9c96

935510ce 24-Nov-2005 Stephan Aßmus <superstippi@gmx.de>

fixed build of frame buffer version

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15133 a95241bf-73f2-0310-859d-f6bbb57e9c96

0b78f37e 24-Nov-2005 Stephan Aßmus <superstippi@gmx.de>

* a bit more sophisticated
* 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

bef1ed93 24-Nov-2005 Stephan Aßmus <superstippi@gmx.de>

Adi and I have had long talks about better approaches to clipping and we are convinced that a different design can significantly speed up the clipping processing in the root layer thread. This is a first prototype implementing the new ideas. Lots of features are missing yet, but Adi asked me to commit it now, so that we can both continue to work on it. The purpose of the new design is to significantly reduce the computations during an atomic clipping update, and also to scale much better with many more open windows.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15101 a95241bf-73f2-0310-859d-f6bbb57e9c96