Commit Graph

1737 Commits

Author SHA1 Message Date
Stephan Aßmus
7afc7c5074 ServerFont:
* fixed weird pointer conversion in SetStyle()
* fixed a potential mix up in operator=() in case the
  other ServerFont has fStyle == NULL

ServerWindow:
* the WindowLayer fTopLayer cannot be deleted by
  client request, just for safety reasons
* the link is flushed if there is no drawing engine,
  but this case is theoretical only
* deleting the ServerWindow object syncs with the
  client, so that when BBitmaps are deleted, they
  can be sure there are no pending messages (which
  would be executed in a nother thread)
* there is no timeout anymore when sending messages
  to the client, which made absolutely no sense

AGGTextRenderer:
* renamed fFontManager to fFontCache, because that's
  what it really is
* fLastFamilyAndStyle defaulted to the system plain
  font and therefor that font was never loaded when
  the font never changed meanwhile

DrawingMode:
* I'm not quite sure but I think there was the
  potential of a division by zero, at least I
  had crashes with "divide error"

HWInterface:
* fix update when the cursor shape changed in
  double buffered mode
 
ViewLayer:
* since the top layer is never really deleted
  before its time has come, it is not necessary
  to set it to NULL in the ViewLayer destructor

ViewLayer/WindowLayer:
* added a function to collect the view tokens
  that are affected by an update session

EventDispatcher:
* use the importance of the message for the timeout
  in _SendMessage()
* drop mouse moved events in the server if we're
  lagging behind more than 5 ms (Axel, maybe review)

View:
* there were some problems with the locking
  of the BWindow looper in RemoveSelf(), since
  this is called from the window destructor,
  also of BWindows from BBitmaps, which have
  never been run (this might need review), at
  least I seem to have solved the crashing
  problems introduced by actually deleting the
  view hirarchy in the BWindow destructor
* fixed _Draw() for being used non-recursively,
  temporarily disabled DrawAfterChildren, which
  didn't work yet anyways (because views cannot
  draw over children in the server yet)

Window:
* small cleanup when deleting shortcuts
* sync with the server when having send
  AS_DELETE_WINDOW (see ServerWindow above)
* fixed locking in Begin/EndViewTransaction()
* removed folding of _UPDATE_ messages, since
  there is only one ever in the queue
* set the fInTransaction flag during an update,
  I plan to use this in BView later to
  flush the link when drawing outside of an
  update
* BView::_Draw() is now called by view token,
  this gives the next leap forward in speed,
  the overhead because of drawing clean views
  was considerable



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15878 a95241bf-73f2-0310-859d-f6bbb57e9c96
2006-01-08 22:04:52 +00:00
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
Stefano Ceccherini
7898383a8a Implemented AS_CREATE_PICTURE, started cleaning up Picture.cpp
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15843 a95241bf-73f2-0310-859d-f6bbb57e9c96
2006-01-05 10:27:29 +00:00
Stefano Ceccherini
8f3f25cf63 Merged the four AS_LAYER_DRAW_BITMAP handlers into just one handler
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15842 a95241bf-73f2-0310-859d-f6bbb57e9c96
2006-01-04 12:15:58 +00:00
Stefano Ceccherini
9c0c899e7d Added a copy constructor to ServerPicture. ServerPicture's constructors are private now, and can be called only from ServerApp (friend). Changed BList to a stl::stack which is better suited as a stack... Changed ServerApp::CreatePicture() to accept a picture to clone, instead of passing back a token which was never used anyway.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15840 a95241bf-73f2-0310-859d-f6bbb57e9c96
2006-01-04 09:49:47 +00:00
Stefano Ceccherini
ee6bcb7d78 Initial support for recording (some, for now) drawing events into a BPicture
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15838 a95241bf-73f2-0310-859d-f6bbb57e9c96
2006-01-04 07:30:38 +00:00
Ingo Weinhold
850f611735 Fixed GCC4 build.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15836 a95241bf-73f2-0310-859d-f6bbb57e9c96
2006-01-04 02:35:12 +00:00
Stefano Ceccherini
b41356006a Implement AS_CLONE_PICTURE handler, needed to copy bpictures server side. Not tested yet
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15826 a95241bf-73f2-0310-859d-f6bbb57e9c96
2006-01-03 16:41:00 +00:00
Axel Dörfler
a342fafcf4 Undo 15810 again; it messed up the window lists (as WindowLayer::InWorkspace() and WindowLayer::Workspaces() must be in sync).
Might reveal other problems in this area, that are worth looking into.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15823 a95241bf-73f2-0310-859d-f6bbb57e9c96
2006-01-03 16:12:52 +00:00
Axel Dörfler
696e72709e The debug_server now uses the standard terminal for debugging - we no longer
need MiniTerminal, it's no longer included in the image.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15822 a95241bf-73f2-0310-859d-f6bbb57e9c96
2006-01-03 14:50:39 +00:00
Stefano Ceccherini
cba9e9ece6 Moved picture handlers to DispatchViewMessage, otherwise they are never called as the view can be hidden
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15818 a95241bf-73f2-0310-859d-f6bbb57e9c96
2006-01-03 13:49:20 +00:00
Stefano Ceccherini
1c33148d10 Implemented handlers needed for Begin/EndPicture, and a handler for DrawPicture().
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15816 a95241bf-73f2-0310-859d-f6bbb57e9c96
2006-01-03 12:44:29 +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
Axel Dörfler
cf48970b0f Initial workspace is a bad idea after all - why should debug alerts always open
on workspace 1 just because the system booted in that workspace? :-)
Now modal windows are opened on the current workspace.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15813 a95241bf-73f2-0310-859d-f6bbb57e9c96
2006-01-03 11:55:15 +00:00
Axel Dörfler
843bc3cd0d * Introduced an initial application workspace - should be retrieved differently,
though (ideally when launched).
* B_MODAL_APP_WINDOW_FEEL windows are now visible on the initial app workspace
  in case it has no other window visible. This fixes the missing BAlerts in
  the debug_server or just the "alert" command. Thanks to Stephan for pointing
  this out.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15811 a95241bf-73f2-0310-859d-f6bbb57e9c96
2006-01-03 11:39:03 +00:00
Axel Dörfler
574af5597c Floating windows start with 0 workspaces - probably didn't matter, though, as
freshly added windows are hidden anyway.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15810 a95241bf-73f2-0310-859d-f6bbb57e9c96
2006-01-03 11:36:45 +00:00
Stefano Ceccherini
69706266c5 Added SetPicture and Picture() to ViewLayer
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15809 a95241bf-73f2-0310-859d-f6bbb57e9c96
2006-01-03 10:30:08 +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
Stefano Ceccherini
82b37bb257 Replace our current ServerPicture implementation with the one from Marc Flerackers. Currently it doesn't do anything as I commented out or removed most code, but it shows what we need to do
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15807 a95241bf-73f2-0310-859d-f6bbb57e9c96
2006-01-03 09:29:22 +00:00
Stefano Ceccherini
20c2f67293 Added Create/DeletePicture to ServerApp
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15802 a95241bf-73f2-0310-859d-f6bbb57e9c96
2006-01-03 08:08:20 +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
Stefano Ceccherini
a5e82db05a Commented out AS_LAYER_***_PICTURE handlers, as they don't do anything and can block the client
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15792 a95241bf-73f2-0310-859d-f6bbb57e9c96
2006-01-02 13:09:59 +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
Alexander G.M. Smith
deb238df7d Tried to get MDR to compile under Zeta RC3 but to no avail, with lots of
brick wall collisions.  Along the way I found a few defines that no longer
exist in Haiku - changed B_BEOS_VERSION_DANO to use Haiku versions (anyone
rebuilding under Dano might want to undo it).  By the way, the BeOS version
number define system might be worth using, since it's a numerical compare
rather than #if defined(V1) || defined (V2) || defined (V3) and so on.

What sort of errors?  Besides needing libzeta.so for some things, the
networking compatibility compile doesn't work (libbind and all that).
Some examples among many:

In file included from /boot/home/Haiku/src/kits/mail/numailkit.cpp:14:
/boot/develop/headers/be/support/Autolock.h:3: using directive `BAutolock' introduced ambiguous type `BAutolock'

In file included from /boot/home/Haiku/src/kits/network/compat/libnet/netdebug.c:6:
/boot/home/Haiku/headers/private/net/netdebug.h:32: syntax error before `void'


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15775 a95241bf-73f2-0310-859d-f6bbb57e9c96
2006-01-01 23:59:24 +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
Axel Dörfler
9aad1a5754 Fixed some problems of the EventDispatcher I introduced since I've played
with the "EventMask" test app the last time:
* The focus view didn't get any mouse messages anymore if there was a permanent
  B_POINTER_EVENTS view.
* B_KEYBOARD_EVENTS now works again.
* B_MOUSE_WHEEL_CHANGED messages no do arrive their targets without prior
  keyboard input.
* Added TODO item that other focus messages don't go through to the app without
  keyboard input (fix only works for B_MOUSE_WHEEL_CHANGED).


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15754 a95241bf-73f2-0310-859d-f6bbb57e9c96
2005-12-30 20:59:14 +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
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
Axel Dörfler
fc6ec91732 Implemented AS_SET_DESKTOP_COLOR - the desktop is not redrawn yet, but freshly exposed
areas will be filled with the new color.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15724 a95241bf-73f2-0310-859d-f6bbb57e9c96
2005-12-29 18:09:07 +00:00
Axel Dörfler
55fd3336b6 * Fixed a bug in ServerApp: when a ServerWindow would take too long to quit,
it could crashed the server.
* ViewLayer now deletes the view bitmap on destruction, if any.
* BitmapManager::Delete() now also accepts NULL bitmaps.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15723 a95241bf-73f2-0310-859d-f6bbb57e9c96
2005-12-29 17:40:18 +00:00
Axel Dörfler
4c66abd6f2 Implemented basic server side BView::SetViewBitmap() support. Things like B_TILE_BITMAP
or even the resizing mode isn't done yet, though. See TODOs.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15720 a95241bf-73f2-0310-859d-f6bbb57e9c96
2005-12-29 16:46:02 +00:00
Axel Dörfler
4acb99b60f Implemented reference counting of ServerBitmaps, made constructor and destructor private,
as only the BitmapManager class is allowed to call them.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15718 a95241bf-73f2-0310-859d-f6bbb57e9c96
2005-12-29 15:36:18 +00:00
Axel Dörfler
93052717b0 Renamed AS_LAYER_GET_{DRAW|BLEND}_MODE to *_{DRAWING|BLENDING}_MODE.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15717 a95241bf-73f2-0310-859d-f6bbb57e9c96
2005-12-29 15:06:24 +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
Stefano Ceccherini
5a077d3f0d Windowscreen sorta works. This should've waited till the end of Christmas holidays, but since I had to fix the build today...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15670 a95241bf-73f2-0310-859d-f6bbb57e9c96
2005-12-25 10:45:39 +00:00
Alexander G.M. Smith
84c93e0938 mmadia provided an updated install.sh, all options should now work. I've
also added a few comments explaining what's going on.  Japanese not updated?


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15667 a95241bf-73f2-0310-859d-f6bbb57e9c96
2005-12-25 03:40:34 +00:00
Stefano Ceccherini
51a523b147 implemented AS_GET_ACCELERANT/DRIVER_PATH and renamed the relative constants
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15666 a95241bf-73f2-0310-859d-f6bbb57e9c96
2005-12-24 16:25:47 +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