i2p/haiku-beta6
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
15,227 Commits 1 Branch 0 Tags
4f7d12cf6a5c1b9da93b5c8665fa8e4ae62b7186
Commit Graph
100 Commits
This Branch
This Branch
All Branches
Author SHA1 Message Date
Stephan Aßmus 1e1b86ef54 * make sure that fTopLayer is NULL when the top layer is deleted 
* make sure layers are removed from the token space when the
  WindowLayer is deleted


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15852 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2006-01-06 17:17:54 +00:00
Stephan Aßmus fb82d189d0 * BWindow deletes its view hirachry 
* BViews set fOwner to NULL recursively when detached
* updated a comment


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15851 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2006-01-06 17:14:58 +00:00
Stephan Aßmus 71d2531d52 terminate_program() is now actually called - forgot to commit this before... 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15849 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2006-01-06 11:09:44 +00:00
Stephan Aßmus 34a9556215 Made our glue code compatible to BeOS again. IOW executables compiled for Haiku will 
now run under BeOS as well (as long as they don't use any functions that are not
available under R5).
The solution is a bit messy, but we have to live with it :-)
The runtime loader now patches the __gRuntimeLoader symbol in libroot.so to point
to its exported structure instead of passing it to the init functions as an
argument.
(Hax0red by axeld and bonefish on stippi's assimilated machine -- resistence is futile)


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15848 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2006-01-06 03:48:11 +00:00
Stephan Aßmus 269293b0ea Selected objects can be removed with the delete key. 
Added testbed for BTabView.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15847 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2006-01-05 23:51:23 +00:00
Stephan Aßmus 0de2f00de7 updated some comments 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15814 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2006-01-03 12:07:11 +00:00
Stephan Aßmus 7324b0ceb8 invisible views are not allowed to draw 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15808 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2006-01-03 10:19:20 +00:00
Stephan Aßmus 39e8aac151 implemented a "new" look for the BTabView, it is actually 
a mix of the liblayout look (I hope Marcus doesn't mind)
and BMenuFields. I will have to clean up after myself one
day and calculate the tab rects properly instead of drawing
far out of the right side of tabs and adding a weird offset
to the label rendering and other places...


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15801 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2006-01-02 18:15:30 +00:00
Stephan Aßmus fd7d912ff6 * round of baseline position for DrawString() 
-> fixes some clipping problems (because of
  hinting, the text was displayed at a rounded
  position anyways, but the clipping calculation
  was screwed up)
* take the drawing_mode and low color from the
  current state for drawing line arrays


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15800 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2006-01-02 18:11:15 +00:00
Stephan Aßmus 21625cdc1b fix checks for when to draw something 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15789 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2006-01-02 12:45:07 +00:00
Stephan Aßmus 35cf9ee250 remove left overs 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15779 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2006-01-02 01:05:42 +00:00
Stephan Aßmus e067fed541 Decorator::ResizeBy tells you the dirty region, DefaultDecorator::Draw() pays attention to the update rect, small clean ups along the way 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15778 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2006-01-02 01:03:31 +00:00
Stephan Aßmus 3155f89a0c blame SaveToPNG for not handling other colorspaces 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15777 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2006-01-02 01:00:12 +00:00
Stephan Aßmus e644f39677 thought I would accelerate taking a screen shot, but it turned out I slowed it down, but I have yet to test this on Haiku somehow. The new code is commented out 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15776 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2006-01-02 00:58:37 +00:00
Stephan Aßmus 34dcf66837 I guess Axel got bored already having to stare at the same animation all the time... so I changed it a little 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15762 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-31 01:38:36 +00:00
Stephan Aßmus ec42af75e8 * fixed wrong byte order in DrawingModeAlphaCC 
* added another optimized bitmap drawing routine
  for B_OP_ALPHA and BGR[A]32 bitmaps. When actual
  blending takes place, it is more than 1.7 times
  faster than R5, and about the same speed when
  the bitmap is fully opaque.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15761 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-31 01:03:26 +00:00
Stephan Aßmus 1fce337f89 cleaned up the code using templates and added optimized version for CMAP8 bitmaps and B_OP_OVER (to benefit Tracker) 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15760 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-30 23:41:57 +00:00
Stephan Aßmus 2de437fa29 The first stab at optimizing bitmap drawing, 
with quite good results I might add. Drawing B_RGB32
bitmaps is more than 1.2 times faster than on R5, while
B_CMAP8 bitmaps are slightly slower. The optimization
is only for B_OP_COPY and unscaled bitmaps
(B_RGB32 and B_CMAP8). Drawing only parts of the bitmap
is supported. Adding optimization for scaled bitmaps
should be beneficial, since the generic version is 2 two
4 times slower. I think it gets even worse for partial
bitmaps.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15758 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-30 21:31:36 +00:00
Stephan Aßmus d95c3678b9 the source buffer is const of course 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15757 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-30 21:26:24 +00:00
Stephan Aßmus 002356d2c9 round off the destination view rect of the view bitmap to avoid problems with drawing the view color around it 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15753 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-30 19:56:42 +00:00
Stephan Aßmus 38030e0477 removed a clouple TODO comments where issues cleared up meanwhile 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15739 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-30 11:42:01 +00:00
Stephan Aßmus 835a0aaf32 prevent drawing bitmaps at fractional offsets 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15732 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-29 19:31:43 +00:00
Stephan Aßmus 8d66d23e83 removed some of Axels TODOs and added some notes, avoid clipping operations if nothing needs to be drawn 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15731 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-29 19:30:48 +00:00
Stephan Aßmus fe161a0740 tweaked the button look to have somewhat smoother corners and a cleaner disabled look 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15730 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-29 19:16:22 +00:00
Stephan Aßmus 27a00cdd92 don't resize scrollbars if the window hasn't even document look 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15727 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-29 18:25:43 +00:00
Stephan Aßmus cd2b129d07 * removed superflous LockSingleWindow() from WindowLayer::MoveBy() 
and ResizeBy()
* WindowLayer::SetSizeLimits() needs to be called with the
  AllWindows lock held
* I was observing weird behaviour with "unclickable" windows
  that I might have fixed by explicitly excluding invisible
  windows from Desktop::WindowAt(), there might be something
  wrong with the "current" window list though, Axel would know
* finally found the problem with "delayed background clearing"
* enabled delayed background clearing and removed unnecessary
  code. It should be more efficient, since it clears larger
  areas at once, and it solves the problem of views unable to
  draw into regions that are pending for another update - among
  other things, updates in resizing windows are more fluent, 
  especially for B_FULL_UPDATE_ON_RESIZE views. "Cut off" scroll
  bars should no longer appear when the view being scrolled takes
  too long to redraw.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15714 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-29 14:15:59 +00:00
Stephan Aßmus f5b6cf65b2 * extracted the frame buffer memcpy routine from HWInterface.cpp 
into a new frame_buffer_support.h
* added blend32 routine for blending a certain color with
  a scanline in the frame buffer
* added "solid" versions of B_OP_ALPHA drawing with
  B_ALPHA_OVERLAY alha function (blending on top of
  a non-transparent background such as the frame buffer)
* implemented an optimized shortcut for alpha blended
  FillRect() in Painter
* used the "packed" version of scanlines for shapes with
  an outline thicker than 4 pixels (and filled shapes anyways),
  this improves drawing speed when there are a few anti-aliased
  pixels at the beginning of a scanline, then a solid fill and
  some anti-aliased pixels at the end of the scanline. Such as
  large letters.

To summarize: The alpha blending in Painter seems to be about
1.45 times faster than on BeOS R5 which benefits drawing large
shapes. For example, drawing a large alpha blended rounded rect
is 1.28 times faster on the Haiku app_server. On the other hand,
B_OP_COPY is quite tough to beat. It is currently 10 times faster
on R5. But a great deal seems to be caused by the Painter
rasterization algorithm itself, since commenting out the actual
drawing doesn't gain any speed.
The other useful experience I collected was that reading and
writing and over the PCI bus in the same loop really hurts
performance. It is actually faster (like 1.8 times!!) to allocate
a second buffer, read from frame buffer into that, doing the
blending at the same time, then writing the buffer back to the
screen.



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15698 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-28 19:53:00 +00:00
Stephan Aßmus 65b53cc601 quick fix for supporting B_TRANSPARENT_MAGIC pixels in CMAP8 bitmaps when drawing those with B_OP_ALPHA (composite, constant alpha) 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15677 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-26 17:41:18 +00:00
Stephan Aßmus 56a1266027 I never get those right the first time 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15672 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-25 22:43:02 +00:00
Stephan Aßmus 9d909e2556 first simplistic implementation of drag bitmaps, drawing modes need more work, drawing text into offscreen bitmaps seems to be broken for some weird reason, B_OP_COPY actually copies the alpha value of the color as well 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15671 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-25 22:17:17 +00:00
Stephan Aßmus 208e6678e3 small efficiency improvements - overall, the drawing speed of a usual BView, especially controls, is pretty much equal to R5 now (Drawing straight text, using StringWidth(), tons of AddLine()s, FillRect() etc) :-) 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15662 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-23 15:57:55 +00:00
Stephan Aßmus cf434f8eec fixed comment 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15661 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-23 15:54:41 +00:00
Stephan Aßmus 268893283f drawing arrow heads looks good on Haiku using B_OP_OVER... Stefano, I made this local change before your earlier commit, I hope I don't step on your toes, it's just a tiny change anyways... 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15659 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-22 22:15:06 +00:00
Stephan Aßmus 8f30140c63 fixed opening windows in other workspaces than the current, keeps the window lists valid 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15639 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-21 13:50:45 +00:00
Stephan Aßmus 5659f08c68 fixed weird resize behaviour (the mouse cursor returns to the initial drag offset after the window has been resized more than the resize limits allow) 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15638 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-21 13:49:19 +00:00
Stephan Aßmus 3ca8cdfc07 remove empty functions which are no longer virtual anyways 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15636 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-21 11:23:37 +00:00
Stephan Aßmus 28f0e47c1a fix B_SUBPIXEL_PRECISE usage, animation in BitmapDrawing is smooth again 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15635 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-21 11:22:48 +00:00
Stephan Aßmus 464f836807 since this is potentially drawing to the frame buffer in the testenviroment too, we don't use memcpy anymore per se 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15634 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-21 11:21:56 +00:00
Stephan Aßmus eeb06055db the run_haiku_registrar app is placed in the test environment install folder 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15633 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-21 11:20:35 +00:00
Stephan Aßmus 75bf993e08 updates various stuff, Jamefiles and run scripts for the most part... clicking a list view object entry selects the object in Playground... alpha drawing in the scrolling test would reveal problems in the app_server scrolling implementation... more I have forgotten 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15632 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-21 11:19:16 +00:00
Stephan Aßmus a90bd9535b why do the stupid bugs always take soo long to find... even when I did them myself... this fixes attaching BViews to B_CMAP8 bitmaps and drawing into them in the test environment 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15631 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-21 11:16:56 +00:00
Stephan Aßmus 8503c000b3 I just realized I never commited this. This enables Haiku to boot from a logical partition in an extended partition that used to be a BFS partition and has enough of the old super block left for BFS to think it's a valid BFS partition... fix found together with Ingo Weinhold 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15629 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-20 22:54:32 +00:00
Stephan Aßmus 1f0a4ee8c7 removed unused stuff from Painter and DrawingEngine, fixed the deadlock when trying to use the (20 times faster) DrawingEngine version of StringWidth, the font is now usually ignored when taking on a DrawState in Painter... should add a little speed overall 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15628 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-20 22:39:54 +00:00
Stephan Aßmus bee1ec1ee0 overall more correct, most importantly corrected a bug in content scrolling that caused view redraws to ignore the window content clipping 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15627 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-20 22:35:36 +00:00
Stephan Aßmus 3c0e5f8e8b added marking a ViewLayer dirty (ie if background needs to be cleared yet) 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15626 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-20 22:31:42 +00:00
Stephan Aßmus a07317fc10 correctly figure out bits per pixel in the direct window info code, this fixes direct windows in the Accelerant test environment, added a note about how the all windows lock seems to be grabbed for the entire duration of a client update on R5, which cannot quite be the truth, because apps crashing in BView::Draw() would take lock up the app_server, added skipping the processing of drawing messages if the current drawing region is empty, added currently disabled code for clearing the view right before the client draws it... doesn't work for some reason unfortunately 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15625 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-20 22:30:02 +00:00
Stephan Aßmus 33ab390e50 currently, there is no mechanism to update the DrawingEngine to a changed frame buffer pointer, so the Window for the Accelerant based test environment is non-movable... will change later 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15624 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-20 22:25:20 +00:00
Stephan Aßmus ef4635a3f9 added a few comments 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15623 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-20 22:23:48 +00:00
Stephan Aßmus f6cef39e1e row_bytes was used in a weird way, and still is, if you would take row_bytes literally 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15622 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-20 22:22:26 +00:00
Stephan Aßmus 36e605d5f3 combine _UPDATE_ and B_WINDOW_RESIZED messages, I left the old code commented, because my combining code might need review. I don't understand why the current message is still in the queue and why passing 1 as index to FindMessage does not seem to work, BMessageQueue::RemoveMessage does not delete the message as documented in the BeBook... everywhere else in the code it seems to be taken as a fact 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15621 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-20 22:20:37 +00:00
Stephan Aßmus 46128d7e26 fix crash in Invoke() when no items are selected and a selection change message is set 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15620 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-20 22:17:07 +00:00
Stephan Aßmus de0283f0f1 forgot to commit the heart of the new drawing_mode implementation. Sorry about that, guys. Thou shalt use svn status after doing huge changes... 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15600 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-20 08:16:04 +00:00
Stephan Aßmus 8d7b8e8ce7 complete rework of the drawing_modes implementation... I achieved a speedup of 8 to 9 times, tested with text rendering. Believe it or not, but the Haiku text rendering is now faster than R5 for B_OP_COPY at least. And there is quite some room for improvement yet. (faster text bounding box calculation, avoiding the double UTF8 conversion, etc) 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15596 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-19 21:22:03 +00:00
Stephan Aßmus 270b7f58b6 removed unnecessary locks 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15595 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-19 21:18:23 +00:00
Stephan Aßmus 1bcc09f226 small improvements here and there 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15594 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-19 21:18:01 +00:00
Stephan Aßmus ce8ae4d8c2 _TriggerContentRedraw is now given the dirty region, so ProcessDirtyRegion does not have to be called for triggering window local redraws 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15593 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-19 21:16:23 +00:00
Stephan Aßmus 85e1d00d58 small style cleanup 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15592 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-19 21:14:16 +00:00
Stephan Aßmus 025e63b08a added functions to quickly tell if the pattern is the solid high or low pattern 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15533 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-14 08:01:49 +00:00
Stephan Aßmus c676b8fcc6 now has a special version of B_OP_OVER for solid patterns as well, accelerated the alpha blending for B_OP_OVER.... these are the first shy steps of rewriting the drawing mode stuff... :-) 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15532 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-13 20:18:13 +00:00
Stephan Aßmus 2a867ee674 accelerated software cursor drawing 11 times 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15531 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-13 19:28:52 +00:00
Stephan Aßmus 040ce75726 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
 2005-12-13 19:08:18 +00:00
Stephan Aßmus 60e12a12c5 no longer used 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15484 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-11 13:09:51 +00:00
Stephan Aßmus 3c2ffeb0d6 fixed one more drawing bug, it only showed because now the test environment uses hardware acceleration, FillRegion for the client irgnored the current clipping 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15483 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-11 13:03:53 +00:00
Stephan Aßmus 1b13861833 included the wrong header 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15482 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-11 13:00:29 +00:00
Stephan Aßmus 62b965a65f * got the "cloned accelerant" based DWindowHWInterface to work, though without 
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
 2005-12-10 21:45:41 +00:00
Stephan Aßmus c2270088dc build the DirectWindow/Accelerant based HWInterface instead - Axel, don't check this out, it doesn't work yet, this is for Ingo to investigate that linker problem 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15471 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-10 16:45:25 +00:00
Stephan Aßmus 17a4024ca9 classes needed for the new cloned Accelerant based test environment 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15470 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-10 16:43:38 +00:00
Stephan Aßmus 2b98735f6d forgot about the right side extra room for the focus indication 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15464 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-10 13:58:42 +00:00
Stephan Aßmus e76d86d5dd 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
 2005-12-10 12:43:19 +00:00
Stephan Aßmus 7be34d3eb2 * removed CopyRegionList, as it made no sense 
* finally nailed that much hated bug where the
  wrong background underneath the cursor was restored.
  I always looked for this in the wrong place -
  of course, you cannot blit regions on top
  of the cursor and expect the backup of the
  background to be magically valid still... ;-)


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15461 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-10 10:42:26 +00:00
Stephan Aßmus 12b29b9f1a forgot to add a comment 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15460 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-10 08:21:50 +00:00
Stephan Aßmus a80bd60522 through the methods of chaos programming, I hope I have finally got this right 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15459 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-10 08:19:35 +00:00
Stephan Aßmus f3faa3c29d * renamed _MarkContentDirty() to _TransferToUpdateSession() 
to avoid any confusion with MarkContentDirty()
* hopyfully fixed all drawing defects that could be
  observed with CopyBits()ing and ScrollTo()ing, the fix
  is definitely valid, and I cannot see any more problems
  in Tracker either... hopefully this is it.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15458 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-10 08:05:25 +00:00
Stephan Aßmus a04f5a1a5b Now the scrollbar works much more like the R5 scrollbar: 
* prevents the target view from being scrolled out of range
 * handles Trackers completely confused usage of scrollbars

There is just one problem with Tracker's horizontal scrollbar
scrolling the title view much further than it should, which I
will look into tomorrow...


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15457 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-09 23:27:35 +00:00
Stephan Aßmus 0f1d5a1af7 finally nailed that bug which prevented Tracker from showing the attribute column titles, I spent way too much time debugging this... 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15455 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-09 17:53:55 +00:00
Stephan Aßmus f056e688a3 now uses the same defaults as in the input_server when unable to contact the input_server 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15454 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-09 17:52:18 +00:00
Stephan Aßmus 939fb4077c fix scrolling of BViews that rely on app_server painting the background, remove a forgotten debug output in ViewLayer, reimplemented setting the window title during runtime, fix Decorator redraw on pressing buttons - though I was lazy on that one... it works, but as the TODOs say, it would be better integrated directly in the Decorator class than being handled by WindowLayer 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15429 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-08 22:15:12 +00:00
Stephan Aßmus fcb6cbaa64 when attached to a BWindow, make sure that the window sets up pulse messaging, if the view has B_PULSE_NEEDED, fixes Tracker showing 0 items in CountView 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15428 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-08 22:10:24 +00:00
Stephan Aßmus 1ba4d96326 take it easy when unable to contact the input_server, makes Tracker run much better in the test environment 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15427 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-08 22:09:22 +00:00
Stephan Aßmus 1cf70f2e66 use With() and Height() instead of right an bottom for the new frame size, fBounds contains the scrolling offset... 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15423 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-08 15:30:15 +00:00
Stephan Aßmus af43bb3c94 a first and really naive implementation of drag&drop support, no visuals yet... Axel, no worries I'm going to clean this up and remove stuff from EventDispatcher again... 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15417 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-08 12:13:22 +00:00
Stephan Aßmus 3f0aa1427c take care of resizing and cleaning up parent BMenuField in FrameResized(), fixes missing areas in Fonts and most likely other BMenuFields 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15413 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-08 12:04:51 +00:00
Stephan Aßmus 9584d7e45e hefty overall drawing speed optimizazion, the Draw() hook was called for every view down the hirarchy when one single child had to redraw, added some TODOs in _Draw about some stuff we need to think about 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15388 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-06 23:27:00 +00:00
Stephan Aßmus 9fe0cc5965 was there any particular reason why BAlerts were old style synchronous controls BWindows? 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15387 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-06 23:25:28 +00:00
Stephan Aßmus 0a95bea66d fixed wrong usage of ConstrainClippingRegion() introduced by myself a couple months ago 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15374 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-06 16:56:31 +00:00
Stephan Aßmus f41715436a remove left over debugging output 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15363 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-06 13:47:16 +00:00
Stephan Aßmus dde10e4519 fixes for various controls to remove or show focus indication when the window active status changes 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15362 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-06 13:46:50 +00:00
Stephan Aßmus a2b387ad6e prevent applying zero offsets to all rects 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15361 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-06 13:45:15 +00:00
Stephan Aßmus a289cd317f slightly improved look 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15360 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-12-06 13:44:38 +00:00
Stephan Aßmus a825e4034c 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
 2005-12-02 00:10:41 +00:00
Stephan Aßmus 0bbd104a7d 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
 2005-12-01 21:32:45 +00:00
Stephan Aßmus 7943e1a86d 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
 2005-12-01 21:14:10 +00:00
Stephan Aßmus 727653f7ab 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
 2005-12-01 19:04:37 +00:00
Stephan Aßmus 8c8275c2ea 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
 2005-12-01 17:24:47 +00:00
Stephan Aßmus d0e89d5302 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
 2005-11-30 23:03:05 +00:00
Stephan Aßmus c8b8bbfca4 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
 2005-11-30 20:51:39 +00:00
Stephan Aßmus 7fd1af6f04 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
 2005-11-30 20:35:47 +00:00
Stephan Aßmus 7e68917fe7 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
 2005-11-30 00:29:19 +00:00
Stephan Aßmus 1ba9992d13 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
 2005-11-29 21:21:12 +00:00
Stephan Aßmus 312345bcb1 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
 2005-11-29 20:53:00 +00:00