i2p/haiku-beta6
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
15,091 Commits 1 Branch 0 Tags
4acb99b60f38da581d1409e9ffd3c4ab8fe95041
Commit Graph
100 Commits
This Branch
This Branch
All Branches
Author SHA1 Message Date
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
Stephan Aßmus c63a78aafa 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
 2005-11-29 20:35:47 +00:00
Stephan Aßmus 4dd89c6903 * 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
 2005-11-29 19:08:58 +00:00
Stephan Aßmus b619f15f6d 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
 2005-11-28 19:40:02 +00:00
Stephan Aßmus 748533bbf9 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
 2005-11-28 19:28:38 +00:00
Stephan Aßmus f51806635b 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
 2005-11-27 00:18:08 +00:00
Stephan Aßmus 0036cd5d1b 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
 2005-11-26 18:02:13 +00:00
Stephan Aßmus 7241178e3f 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
 2005-11-26 17:55:05 +00:00
Stephan Aßmus f5552ed0b2 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
 2005-11-26 17:01:29 +00:00
Stephan Aßmus 987aa5e4d4 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
 2005-11-26 15:22:35 +00:00
Stephan Aßmus 27b740633e one bug fixed, three more to go 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15162 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-11-26 14:51:35 +00:00
Stephan Aßmus cfc40fb337 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
 2005-11-26 14:33:26 +00:00
Stephan Aßmus 7f705589e2 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
 2005-11-26 14:07:44 +00:00
Stephan Aßmus ff89d51e02 * 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
 2005-11-26 00:13:34 +00:00
Stephan Aßmus 23f32b1552 corrected and cleaned up coordinate conversion. conversion from or to parent coords doesn't actually require a parent, directly using fScrollingOffset, uses less stack memory now and should be faster (especially when converting regions, because those were offsetted twice) 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15136 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-11-24 21:23:33 +00:00
Stephan Aßmus 0cf04412be 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
 2005-11-24 21:04:46 +00:00
Stephan Aßmus 420b55f261 fixed the frame buffer version for real 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15134 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-11-24 21:01:49 +00:00
Stephan Aßmus 935510ce32 fixed build of frame buffer version 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15133 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-11-24 20:56:53 +00:00
Stephan Aßmus 0b78f37e8e * 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
 2005-11-24 20:49:30 +00:00
Stephan Aßmus bef1ed93e1 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
 2005-11-24 09:45:28 +00:00
Stephan Aßmus bbbe5a3329 of course, GetPreferredSize() is defined void 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15077 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-11-22 19:17:12 +00:00
Stephan Aßmus 45b013192a fix crashes when the text pointer is NULL, this lets you for example pick a background image with the Backrounds preflet, though it doesn't work further down 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15076 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-11-22 19:02:56 +00:00
Stephan Aßmus b223f78041 fixes origin and scale handling, it behaves mostly like R5 now (it is used for drawing only, yes not mouse coords or anything else). Also fixes offscreen layers clipping rebuilding when the user defined clipping is added or changed 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15040 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-11-20 15:10:18 +00:00
Stephan Aßmus 02ed46b0de * fixes the cursor handling after Axels changes, it crashed on real HW. 
Axel, I think you didn't realise that _CursorFrame() gave and
invalid BRect for fCursorVisible=false, but that rect was used
to create the backup area, so it was buggy at that place. I removed
your checks for fCursorVisible in SetCursor() for cleaner code, but
left it in MoveCursor() because it might save a few cycles.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14954 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-11-16 10:29:06 +00:00
Stephan Aßmus f4cee9d5f5 fix the FBC problem, as Ingo pointed out, derived classes contain slots for all virtuals defined in the base class, therefor, it is ok to just define WindowActivated for BScrollBar. The only problem is that BScrollBar::WindowActivated() cannot be called from apps having overridden WindowActivated() in a BScrollBar subclass of their own. 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14953 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-11-15 23:46:02 +00:00
Stephan Aßmus b894f5f778 fix build of test environment 
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14952 a95241bf-73f2-0310-859d-f6bbb57e9c96
 2005-11-15 23:43:02 +00:00