#
77870621 |
|
20-Oct-2021 |
Augustin Cavalier <waddlesplash@gmail.com> |
app_server: Drop gfxcpy and implement some TODOs about checking for graphics memory. We still do not know if the accelerant buffers are graphics memory or not, but in my testing (on the VESA driver), the only time I could get _CopyRect to be called was where the buffer was in fact not graphics memory. So that should provide a performance improvement there. On the other end of things, this should resolve unaligned video memory access problems on RISCV, and potentially other platforms, as gfxcpy32 did not attempt to align pointers; it should also improve performance as memcpy will usually be faster than our custom gfxcpy here. Most of this code has not been touched since 2006 or so. Change-Id: I40b0345c5d47f2b45acafb14f03fd3a24d2042a8 Reviewed-on: https://review.haiku-os.org/c/haiku/+/4315 Reviewed-by: waddlesplash <waddlesplash@gmail.com> Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com> Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
|
#
b419a79f |
|
21-Oct-2021 |
Augustin Cavalier <waddlesplash@gmail.com> |
app_server: Remove IsDoubleBuffered() default implementation from HWInterface. It just causes confusion and is wrong in the case where double buffering status changed during the object lifetime. Change-Id: Ia1a9ae3f5a1b1b7d521b79c7d1c7be92cef60a06 Reviewed-on: https://review.haiku-os.org/c/haiku/+/4633 Reviewed-by: waddlesplash <waddlesplash@gmail.com>
|
#
779ab335 |
|
09-Dec-2020 |
X512 <danger_mail@list.ru> |
use .IsSet() instead if .Get() != NULL Change-Id: Ia2b7a719fd398e78cc3b11d4f7b02cb81179f65f Reviewed-on: https://review.haiku-os.org/c/haiku/+/3488 Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
|
#
ebe6011c |
|
11-Dec-2020 |
X512 <danger_mail@list.ru> |
app_server: do not flush back buffer outside of clipping Introduce DrawTransaction that automatically hide/show floating overlays and flush back buffer. Fixes #15574. Change-Id: I30088b74fc66cfcd5b2b433b34141e7d496f68a1 Reviewed-on: https://review.haiku-os.org/c/haiku/+/3496 Reviewed-by: Axel Dörfler <axeld@pinc-software.de>
|
#
60d30785 |
|
27-Aug-2020 |
X512 <danger_mail@list.ru> |
app_server memory management fixes: use BReference Use BReference for more automated reference counting in app_server, fixing some use-after-free and other problems. Extracted from https://review.haiku-os.org/c/haiku/+/2695 Change-Id: I141bb248229405896b29feff3338447f7257b0b4 Reviewed-on: https://review.haiku-os.org/c/haiku/+/3175 Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
|
#
b5be469e |
|
15-Aug-2019 |
Adrien Destugues <pulkomandy@pulkomandy.tk> |
app_server: some missing std::nothrow and error checks. I had app_server crash on me because of an uncaught allocation exception. I don't know if this will fix it but it's better to try to survive even if it may result in some UI glitches. Change-Id: I09dd2a7e6ff63d52f51389d7418d1a1d1810af00 Reviewed-on: https://review.haiku-os.org/c/haiku/+/1720 Reviewed-by: waddlesplash <waddlesplash@gmail.com>
|
#
c247a73b |
|
22-Nov-2017 |
Adrien Destugues <pulkomandy@pulkomandy.tk> |
app_server: handle empty drag bitmap An application is allowed to set an empty drag bitmap. In that case, the offset from the cursor doesn't matter, because there is nothing to draw anyway. app_server would end up confused by the empty bitmap (which has no bits) and invalid offset (it would try to allocate a 2^16 x 2^16 pixels bitmap to fit both the cursor and the empty bitmap), and eventually it would crash. Fixes #13577.
|
#
f3e8ed4d |
|
21-Nov-2017 |
Michael Lotz <mmlr@mlotz.ch> |
app_server: Implement screen changed hooks and notifications. The ScreenOwner interface gets an additional ScreenChanged() hook. It is implemented in the Desktop class to automatically set the preferred screen mode on the changed screen. The HWInterfaceListener, previously only used by the downstream DrawingEngine, gets an additional ScreenChanged() hook as well to inform an upstream client of a changed screen. The ScreenManager ties these two mechanisms together.
|
#
ed80f189 |
|
28-Nov-2012 |
Axel Dörfler <axeld@pinc-software.de> |
Applied an updated patch by looncraz to enable hardware cursor. I made the following changes to the original patch: * Add const to the cursor setting functions. * Removed the legacy cursor copying code. * Minor coding style cleanup.
|
#
ba1c9c6c |
|
08-Aug-2012 |
czeidler <haiku@clemens-zeidler.de> |
The hotspot is already included in the shift. This became visible when dragging an image together with a cursor that has a reasonable large hotspot. In this case the cursor and the bitmap were shifted to much.
|
#
abf0b152 |
|
15-Feb-2010 |
Axel Dörfler <axeld@pinc-software.de> |
* Removed unneeded comment/code. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35470 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
4b0459b2 |
|
04-Nov-2009 |
Axel Dörfler <axeld@pinc-software.de> |
* Refactored ServerBitmap a bit: it now inherits from Referenceable instead of roling its own solution. * Also removed BitmapManager::DeleteBitmap() - you only call ServerBitmap::RemoveReference(), and that one will notify the manager if needed. * Some more cleanup. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33878 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
68667bf4 |
|
04-Oct-2009 |
Michael Lotz <mmlr@mlotz.ch> |
* Adding a remote desktop interface that operates on app_server drawing primitives by providing a RemoteDrawingEngine and a RemoteHWInterface. Not really optimized yet, still a bit WIP. * Adding corresponding infrastructure like a blocking ring buffer and network sender/receiver that are attached to the buffers to feed/drain them as well as a RemoteMessage helper that provides a message based interface. * Adding target screen concept to request an app to be run on a specific screen. It's controlled by the TARGET_SCREEN environment variable which is added on the app side and sent to the app_server. * Right now only remote target screens are supported, in which case a new RemoteHWInterface is created that tries to connect to the given host:port. * Fix shape bounds when drawing, they need to be translated by the pen position and converted to screen like the points as well. Wasn't visible though as the bounds weren't used in the normal DrawingEngine. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33417 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
7b8b23e9 |
|
01-Sep-2009 |
Axel Dörfler <axeld@pinc-software.de> |
* Cleanup, no functional change. +alphabranch git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32881 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
2469a6f4 |
|
23-Oct-2008 |
Stephan Aßmus <superstippi@gmx.de> |
* Rewrote the UpdateQueue class. It actually works now and would perform screen updates during the vertical refresh, but it causes flickering again since there is no guarantee that screen regions will stay clean from the time that they were scheduled with the UpdateQueue until the UpdateQueue thread transfers them. Therefor it is still disabled. * Refactored a bit the distinction between Invalidate() and CopyToFront(). Invalidate() used to be virtual, but now CopyToFront() is. This was mainly needed for the app_server test environment, because the host window needs to call Invalidate() when the front buffer bitmap is clean. When the UpdateQueue is used, this needs to be CopyToFront(). Now the separation is cleaner in combination with the UpdateQueue. * Fixed a problem in HWInterface::CopyToFront(): When separating the region outside the cursor and the region with the cursor during a transfer, it needs to hold the fFloatingOverlay lock to make sure the cursor is not moved in the meantime. This fixes graphics glitches with remnants of the cursor staying on screen. These could very rarely be observed, but much more often with the accelerated double-buffer mode. * Enabled the accelerated double buffered mode, since it works now very well. I was able to test it with the nVidea driver on an nVideo 7300. It works by allocating a frame buffer twice the height of the configured screen mode. Then all drawing goes into the offscreen portion, including accelerated driver functions. AccelerantHWInterface::_CopyToFront() then uses acceleration to blit the clean regions in the offscreen portion of the frame buffer into the visible part. Please tell me if there are problems, for example when if there is too few video memory, or if a driver does not handle it correctly. To disable it, see src/servers/app/drawing/AccelerantHWInterface.cpp line 511. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28301 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
c5ac899a |
|
20-Jul-2008 |
Stephan Aßmus <superstippi@gmx.de> |
* Refactor the method that actually copies rectangles from the back buffer to the front buffer so that derived classes could override it. * Minor coding style changes. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26542 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
97ee7d0a |
|
12-May-2008 |
Stephan Aßmus <superstippi@gmx.de> |
When drawing is double buffered, there is no excuse for a flickering cursor (including any drag bitmap). HWInterface::HideFloatingOverlays() was plain stupid, I know it did check double buffering at one point, but I must have removed that when messing with it. But copying anything from back to front buffer is now not overwriting the cursor area anymore, which is painted immediatly afterwards. Also moving the cursor invalidates only one rect if old and new cursor area overlap. All these changes should save some cycles too. Added TODO with regard to caching the on-the-fly cursor compositing buffer. If you have * a more recent computer * a decent VESA BIOS which supports your native resolution * don't need video overlays ... I recommend using the VESA driver. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25479 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
ace2d5ee |
|
02-Apr-2008 |
Stephan Aßmus <superstippi@gmx.de> |
HWInterface::Cursor() and therefor Desktop::Cursor() accessed the current cursor without locking, and did not add a reference while using the cursor. I have tried to solve both problems by introducing a simple ServerCursorReference class, which makes sure that the reference count is properly maintained. There are only two places where this code was even used, from within ServerApp and when taking screenshots. Axel, you mentioned in #837 that the code is unsafe, is this what you meant? This hopefully fixes #837, but it is very hard to reproduce in the first place, I will close the ticket, but it should just be reopened if ever encountered again. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24741 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
b7458c6b |
|
10-Mar-2008 |
Stephan Aßmus <superstippi@gmx.de> |
RenderingBuffer::Bounds() returns an IntRect, saves a conversion. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24352 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
c8d785a7 |
|
24-Feb-2008 |
Stephan Aßmus <superstippi@gmx.de> |
Cursor frame can be expressed using IntRect. Saves a few lines of code too. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24099 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
b1ab9b5f |
|
24-Feb-2008 |
Stephan Aßmus <superstippi@gmx.de> |
* ReadBitmap() could mess up the software cursor locking, since it used the BRect version of HideSoftwareCursor() but then called ShowSoftwareCursor() unconditionally. * Renamed Hide/ShowSoftwareCursor() to Hide/ShowFloatingOverlays(). * Removed no longer needed FontLocker. * Implemented AutoFloatingOverlaysHider and got rid of a lot of code duplication this way. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24095 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
a0c4a29f |
|
09-Feb-2008 |
Jérôme Duval <korli@users.berlios.de> |
added B_RGBA15 colorspace, and explicitly print which colorspce is unsupported git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23938 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
c2784486 |
|
15-Oct-2007 |
Axel Dörfler <axeld@pinc-software.de> |
* Introduced a monitor_info structure and means to let it be filled by the accelerant (or the app_server via EDID info). It's still experimental API, and opinions are welcome. * Moved BPrivateScreen into the BPrivate namespace. * Rewrote Screen.h. * Introduced a BScreen::GetMonitorInfo() method, and implemented it in the app server as well (ie. AS_GET_MONITOR_INFO). git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22563 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
4191a211 |
|
12-Oct-2007 |
Axel Dörfler <axeld@pinc-software.de> |
* Started accelerant extension to be able to get the preferred mode from the accelerant, as well as its EDID info. B_GET_PREFERRED_DISPLAY_MODE and B_GET_EDID_INFO are both optional. The preferred mode will be taken from the EDID info if only the latter hook is implemented, or the former returned an error. * Currently, the app_server should correctly set the preferred mode on start, but no accelerant supports that yet, so it's not really tested. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22520 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
e2693621 |
|
30-Sep-2007 |
Axel Dörfler <axeld@pinc-software.de> |
Correctly implemented the missing BBitmap::GetOverlayRestrictions() on the client and the server. This should fix bug #1490, but I haven't tested it yet. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22388 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
91d0586a |
|
15-Aug-2007 |
Stephan Aßmus <superstippi@gmx.de> |
* it should be better to lock before accessing the data, even if reading only * after this change, I have not spotted "left behind" cursors again, but it might just be bad luck... git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21966 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
d6f8caca |
|
31-May-2007 |
Axel Dörfler <axeld@pinc-software.de> |
Moved the (currently very simplistic) code to check if a display_mode is valid into it's own (static) method. In case setting the display mode fails, the returned mode is now checked for validity as well. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21282 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
87719fdb |
|
22-Dec-2006 |
Ryan Leavengood <leavengood@gmail.com> |
Added a needed header for the recent ioctl() call addition. Lack of this caused the libbe_test environment build to fail. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19610 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
0c6f7795 |
|
19-Dec-2006 |
Axel Dörfler <axeld@pinc-software.de> |
* Moved VGA planar mode blitting into the VESA kernel driver. * In grayscale mode, the AccelerantHWInterface now sets the palette correctly. * HWInterface now has a fVGADevice set by AccelerantHWInterface which will be used to talk to the VESA driver. * Completed planar blitting for all 4 planes; we now have a perfect 16 color grayscale mode when you choose "Standard VGA mode" in the boot loader with an unsupported graphics card (such as in Qemu). git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19567 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
c46eb09e |
|
19-Dec-2006 |
Axel Dörfler <axeld@pinc-software.de> |
* The 4-bit VGA planar mode is now advertized as B_GRAY8 to the app_server. * The app_server now detects that this mode is being used, and at least correctly copies the 32bit data to the first plane, meaning we have a monochrome output for now (it crashed before, as Stefano reported). git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19565 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
2cfe93e7 |
|
04-Dec-2006 |
Stephan Aßmus <superstippi@gmx.de> |
* renamed HWInterface locking to LockParallelAccess() and LockExclusiveAccess() (meaning more or less access to the frame buffer) * extracted the AGGTextRenderer to be a global instance used by each Painter instance (currently, it is thread safe because of the global font lock, so there is some work left in this regard) * gave every ServerWindow it's own DrawingEngine instance, this is work in progress. So far, there doesn't seem to be a regression, but less fighting over the exclusive access to the frame buffer, now each ServerWindow thread can draw in parallel. There is room for improvement, plus I think I'm leaking the DrawingEngine... * changed the locking for the software cursor. ShowSoftwareCursor() can only be called if HideSoftwareCursor(BRect) returned true, or if you called the generic HideSoftwareCursor(), since it needs to keep the cursor lock and unlocks in Show...! * some clean up and renaming in Decorator and friends * moved PatternHandler.h to live along with the .cpp git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19427 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
67491d2a |
|
29-Nov-2006 |
Stephan Aßmus <superstippi@gmx.de> |
* introduced a listener mechanism to be notified of frame buffer changes in the HWInterface (ie on mode switch) * initialization and shutdown of the HWInterface instance no longer go through DrawingEngine, which had nothing to do with it in the first place (this is in preparation of giving each ServerWindow it's own DrawingEngine instance) * small performance improvement in ViewLayer::ScrollBy() * some cleanup in ServerConfig.h git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19391 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
524c811b |
|
24-Aug-2006 |
Axel Dörfler <axeld@pinc-software.de> |
Renamed HWInterface::GetCursorPosition() to CursorPosition() to match the usual style. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18595 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
b0bc48fb |
|
19-May-2006 |
Axel Dörfler <axeld@pinc-software.de> |
Some more GCC 4 and PPC fixes. * Mesa doesn't compile yet, as some PPC specific stuff seems to be missing, Philippe? * Cortex and some other stuff has been marked x86-only, although it's more of a "GCC 2.95.3"-only. * I'm not sure if it's a bug in GCC 4, or if that's what the C standard demands, but sizeof(some_type::some_field) is not valid anymore :-/ git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17515 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
3652a439 |
|
19-May-2006 |
Axel Dörfler <axeld@pinc-software.de> |
* Accidently broke overlay (but BerliOS didn't let me commit yesterday :-/), since ViewLayer::SetViewBitmap() did not show the overlay, only updated it. * Simplified overlay handling a bit, removed Overlay::Show(), and IsVisible(), replaced Update() by Configure(). * Made similar changes in the HWInterface as well. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17504 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
0ac013e6 |
|
23-Apr-2006 |
Axel Dörfler <axeld@pinc-software.de> |
* Some refactoring: renamed OverlayCookie to Overlay and put it in its own source file. * An overlay is now also hidden in case its is removed from the window. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17209 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
f7c7883b |
|
23-Apr-2006 |
Axel Dörfler <axeld@pinc-software.de> |
* We now have working video overlay - even though the overlay_token handling is currently broken, mode switches probably fail or result in sudden death (didn't try) it's good enough for Radeon cards and VLC (might work with others as well). * Implemented follow modes for view bitmaps (wasn't taken into account at all before). * Switched to a darker overlay color for now (dunno what exactly makes a good candidate there, but this one is good enough for now). * Added TODO about a race condition in AS_LAYER_SET_VIEW_BITMAP. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17208 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
68bf2de5 |
|
21-Apr-2006 |
Axel Dörfler <axeld@pinc-software.de> |
* Refined overlay support a bit: we now allow as many overlay bitmaps to be created as the graphics driver does. * Also, B_BITMAP_RESERVE_OVERLAY_CHANNEL should now work as expected. * We're no longer using the B_OVERLAY_COUNT hook anymore - that one really looks like a misconception to me; I don't see how it can be useful. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17196 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
37b502f2 |
|
21-Apr-2006 |
Axel Dörfler <axeld@pinc-software.de> |
Implemented some more overlay support - the overlay bitmap is now allocated via the graphics driver (but not yet shown on screen). I probably got the meaning of the "overlay count" wrong - I guess that you can allocate any number of overlay bitmaps, but can only see "overlay count" on screen at a time (right now, I only allow to create "overlay count" bitmaps). Stephan? git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17193 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
dd98ed8d |
|
19-Apr-2006 |
Stephan Aßmus <superstippi@gmx.de> |
* implemented view bitmap options (B_BITMAP_TILE...) in ViewLayer (for example, fixes NetPositive rendering HTML with a background image) * use BRegion pool everywhere in ViewLayer * WindowLayer update sessions distinguish between different reasons for the update: exposed and requested - on expose updates, the view backgrounds are cleared immidiately (as on R5), to keep the time previous stuff keeps showing as short as possible, while on requested updates, the background clearing is delayed until the client draws something, to keep the time until the client fills a view with content as small as possible to reduce flickering (might need more work, could be buggy yet) * HWInterface and DrawingEngine support delayed syncing to the graphics hardware at least for FillRect/Region. The speed up gained by this is minor though. * HWInterface cursor rendering uses a bit of rounding to avoid the slight transparent shadow around the cursor (I don't know if it is fully correct though, at least the shasow disappeared) git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17172 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
39cdae74 |
|
10-Apr-2006 |
Michael Lotz <mmlr@mlotz.ch> |
First steps at getting drag & drop to work properly. Simple drag & drop (draging Tracker items) should work now. Not sure about the negotiated version (with mimetype exchange). Fixed left behind drag bitmaps. Some cleanup. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17058 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
907e89c6 |
|
08-Mar-2006 |
Stephan Aßmus <superstippi@gmx.de> |
* The EventDispatcher takes care of reference counting the ServerBitmap used for the drag bitmap, see NOTEs on why that is... * moved reference counting of the ServerCursor from Desktop into HWInterface where it is actually used * I hope to have fixed the problems with _DrawCursor when dragging something. At least the reference counting of the ServerCursor was for real, since the HWInterface rejected changes to the cursor while something was dragged, which caused the old cursor to be Released() and deleted each time the mouse moved... git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16657 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
aa1f5437 |
|
05-Feb-2006 |
Axel Dörfler <axeld@pinc-software.de> |
Some work on cursors: * Fixed a myriad of bugs all over the place, ranging from locking errors to deleting objects that don't belong to the one deleting them (hello HWInterface!) * Almost all ServerWindow cursor stuff was broken; I've replaced all commands to set a cursor with a single one AS_SET_CURSOR. * Renamed some cursor commands. * Changed the (broken) way ServerApp::fAppCursor was maintained - the application cursor is now NULL as long as possible. * Removed superfluous ServerCursor app signature stuff. * The BApplication will no longer duplicate the default/I-beam cursors, it will just reuse the default ones which now have fixed tokens. * As a result, changing the cursor is now working as expected, closing bug #102. * Rewrote Cursor.h, renamed private members to match our style guide. * Minor cleanup. What's still left to be done is reference counting the cursor objects to make them work right and reliable. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16237 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
ff3abf4d |
|
02-Feb-2006 |
Axel Dörfler <axeld@pinc-software.de> |
* Started a naive implementation of BView::SetViewCursor() server-side - doesn't work though, as HWInterface can only draw B_RGB32 cursors... * More build fixes for libbe_test target - it defines __HAIKU__ as well, now git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16211 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
cf6fe303 |
|
12-Jan-2006 |
Stephan Aßmus <superstippi@gmx.de> |
* I decided having the cursor obscuring feature in the HWInterface class was not such a bad idea after all. * Reenabled obscuring the cursor in ServerApp. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15925 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
bd5f895a |
|
11-Jan-2006 |
Stephan Aßmus <superstippi@gmx.de> |
* made hiding and unhiding the cursor actually work git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15918 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
7afc7c50 |
|
08-Jan-2006 |
Stephan Aßmus <superstippi@gmx.de> |
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
|
#
f5b6cf65 |
|
28-Dec-2005 |
Stephan Aßmus <superstippi@gmx.de> |
* 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
|
#
56a12660 |
|
25-Dec-2005 |
Stephan Aßmus <superstippi@gmx.de> |
I never get those right the first time git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15672 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
9d909e25 |
|
25-Dec-2005 |
Stephan Aßmus <superstippi@gmx.de> |
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
|
#
51a523b1 |
|
24-Dec-2005 |
Stefano Ceccherini <stefano.ceccherini@gmail.com> |
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
|
#
464f8368 |
|
21-Dec-2005 |
Stephan Aßmus <superstippi@gmx.de> |
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
|
#
2a867ee6 |
|
13-Dec-2005 |
Stephan Aßmus <superstippi@gmx.de> |
accelerated software cursor drawing 11 times git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15531 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
62b965a6 |
|
10-Dec-2005 |
Stephan Aßmus <superstippi@gmx.de> |
* 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
|
#
02ed46b0 |
|
16-Nov-2005 |
Stephan Aßmus <superstippi@gmx.de> |
* 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
|
#
af8899c4 |
|
15-Nov-2005 |
Axel Dörfler <axeld@pinc-software.de> |
Added support for not visible cursors - defaults to invisible now! git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14948 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
0d02a8aa |
|
18-Jul-2005 |
Stephan Aßmus <superstippi@gmx.de> |
fixed B_CMAP8 back to front buffer conversion (blue was missing) git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13757 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
95e42caf |
|
16-Jul-2005 |
Stephan Aßmus <superstippi@gmx.de> |
tried to find the bug that causes the wrong area underneath the software cursor to be restored, but failed, the only accomplishment is that the cursor is now showing right from the beginning, not only after one moves the mouse git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13702 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
359c905c |
|
05-Jul-2005 |
Stephan Aßmus <superstippi@gmx.de> |
offscreen bitmaps work, tested on Haiku as well, supports all colorspaces that BBitmap::ImportBits() supports. It uses a fallback for non-B_RGB(A)32 bitmaps. Added support for B_SUB_PIXEL_PRECISION view flags, though it is a bit hacky, since I had to add it to LayerData, even though it is not a true part of stack data. Added Layer::SetFlags() to enforce code path and update fLayerData. Cleaned up DisplayDriverPainter and DisplayDriver API (changed some const BRect& rect to simply BRect rect in order to be able to reuse it in the code), moved Painter.h, the test environment only draws the changed part of the frame buffer again - this causes a lot less CPU overhead, Painter special cases stroke width of 1.0 to use square caps, which is similar to R5 implementation and removes a lot of problems with non-straight line drawing, ServerWindow uses the DisplayDriver from it's WinBorder instead of the one from the Desktop (needed for offscreen windows, which have their own DisplayDriverPainter), it also checks for GetRootLayer() == NULL, because offscreen layers are not attached to a RootLayer, there was a fix for scrolling which worked at least in the test environment, it is now defunced, because Adi moved _CopyBits to Layer... I need to reenable it later, LayerData has no more fEscapementDelta, also fixed fFontAliasing (which was thought to overriding the font flags, and now works as such again), Desktop initialises the menu_info and scroll_bar_info stuff, which makes ScrollBars work actually... hope I didn't forget something. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13448 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
3dcb3b07 |
|
23-Jun-2005 |
Stephan Aßmus <superstippi@gmx.de> |
Added some root layer locking in ServerWindow.cpp when accessing the layer tree. Moved HWInterface management out of DisplayDriverPainter and into Desktop. Removed all the directly hardware related functions from DisplayDriver API. They just called the same HWInterface functions. Now DisplayDriver is much cleaner and ready for being attached to a yet to be written BitmapHWInterface. Clean up of the display mode stuff in Screen and the View-/AccelerantHWInterface. Frequency is now regarded on Haiku. AccelerantHWInterface::GetModeList now works before SetMode has been called. Added MultiLocker from the sample code. HWInterface uses it now in preparation to being used from multiple instances of DisplayDriver. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13252 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
fbf48e64 |
|
04-May-2005 |
Stephan Aßmus <superstippi@gmx.de> |
Enabled HW acceleration for CopyRegion(). Tested on Haiku and it works. I also implemented FillRegion and InvertRegion. But using different acceleration hooks after one another freezes Haiku, app_server, the accelerant or whatever. I have no clue about accelerants, so if a knowledgable someone would have a look at AccelerantHWInterface.cpp, that'd be great. The software cursor stuff has a cosmetical bug with regards to CopyRegion() too, I don't understand it yet. I also tried to improve StringWidth() and DrawString() preformance. I confirmed that the glyph cache is actually used, but AGGTextRenderer::RenderString() is a dog. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12573 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
d3194176 |
|
03-May-2005 |
Stephan Aßmus <superstippi@gmx.de> |
added support for software cursor needed for single buffered mode git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12561 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
ded5874e |
|
20-Apr-2005 |
Stephan Aßmus <superstippi@gmx.de> |
Implemented changes necessary for single buffered mode, it is turned off for now, because the soft cursor is currently not being taken care of. We will still use double buffering if the screen color space is not 32 bits, too. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12449 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
e742e3e1 |
|
18-Apr-2005 |
Stephan Aßmus <superstippi@gmx.de> |
refactoring and cleanup in LayerData and friends, it shows what I mean by "forced code paths" for example in coupled font size and view scale, added a couple TODOs, disabled decoupled frame buffer transfers, it is buggy and deadlocks for some reason... git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12441 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
74b3612a |
|
18-Apr-2005 |
Stephan Aßmus <superstippi@gmx.de> |
refactoring, speedup by decoupling back to front transferes from drawing and usage of special memcpy routine, minor speedups in Painter git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12437 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
d78aea18 |
|
13-Apr-2005 |
Stephan Aßmus <superstippi@gmx.de> |
hides a bug where we appearently read from the cursor out of bounds because of float to int converting issues... need to investigate that. In any case, I got the cursor position thing completely wrong, my intentions of setting it to 0.5, 0.5 were something else... git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12385 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
bd6b1617 |
|
12-Apr-2005 |
Stephan Aßmus <superstippi@gmx.de> |
a few cosmetic changes git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12332 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
89b3c19c |
|
30-Mar-2005 |
Stephan Aßmus <superstippi@gmx.de> |
ViewHWInterface updates are a bit smoother now git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12175 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
d3db964e |
|
29-Mar-2005 |
Stephan Aßmus <superstippi@gmx.de> |
code refactoring, moved common stuff into the base class git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12129 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
e33b90ea |
|
28-Mar-2005 |
Stephan Aßmus <superstippi@gmx.de> |
implemented cursor support in the DisplayDriverPainter git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12107 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
53115c99 |
|
27-Mar-2005 |
Stephan Aßmus <superstippi@gmx.de> |
moved the place of implementation of locking in DisplayDriver, because the Painter version has it elsewhere. the DisplayDriver locking API is now abstract, the same locking is now in DisplayDriverImpl, Painter version uses HWInterface for locking git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12084 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
3294d07b |
|
26-Mar-2005 |
Stephan Aßmus <superstippi@gmx.de> |
abstract base class and implementation using BView and BWindow of an interface to a graphics card, UpdateQueue doesn't work yet, it was going to be used to decouple frame buffer transfers to the front buffer from the drawing in the back buffer git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12056 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
ed80f189ce473ee4241de0d9a5e45e384508a0c3 |
|
28-Nov-2012 |
Axel Dörfler <axeld@pinc-software.de> |
Applied an updated patch by looncraz to enable hardware cursor. I made the following changes to the original patch: * Add const to the cursor setting functions. * Removed the legacy cursor copying code. * Minor coding style cleanup.
|
#
ba1c9c6c6da56154f64fae4c455dbe68406e4c33 |
|
08-Aug-2012 |
czeidler <haiku@clemens-zeidler.de> |
The hotspot is already included in the shift. This became visible when dragging an image together with a cursor that has a reasonable large hotspot. In this case the cursor and the bitmap were shifted to much.
|
#
abf0b1523ae50b2a00c378bd90d86e1fa370dfdf |
|
15-Feb-2010 |
Axel Dörfler <axeld@pinc-software.de> |
* Removed unneeded comment/code. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35470 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
4b0459b2eef38f07b8c0c4426860dccb61a1134a |
|
04-Nov-2009 |
Axel Dörfler <axeld@pinc-software.de> |
* Refactored ServerBitmap a bit: it now inherits from Referenceable instead of roling its own solution. * Also removed BitmapManager::DeleteBitmap() - you only call ServerBitmap::RemoveReference(), and that one will notify the manager if needed. * Some more cleanup. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33878 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
68667bf48a9e29a2d142cb3308b606d80bee3c2d |
|
04-Oct-2009 |
Michael Lotz <mmlr@mlotz.ch> |
* Adding a remote desktop interface that operates on app_server drawing primitives by providing a RemoteDrawingEngine and a RemoteHWInterface. Not really optimized yet, still a bit WIP. * Adding corresponding infrastructure like a blocking ring buffer and network sender/receiver that are attached to the buffers to feed/drain them as well as a RemoteMessage helper that provides a message based interface. * Adding target screen concept to request an app to be run on a specific screen. It's controlled by the TARGET_SCREEN environment variable which is added on the app side and sent to the app_server. * Right now only remote target screens are supported, in which case a new RemoteHWInterface is created that tries to connect to the given host:port. * Fix shape bounds when drawing, they need to be translated by the pen position and converted to screen like the points as well. Wasn't visible though as the bounds weren't used in the normal DrawingEngine. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33417 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
7b8b23e9a4505c568342233ed23c2d31de397683 |
|
01-Sep-2009 |
Axel Dörfler <axeld@pinc-software.de> |
* Cleanup, no functional change. +alphabranch git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32881 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
2469a6f4272b43fb04e11290808216f6a7610599 |
|
23-Oct-2008 |
Stephan Aßmus <superstippi@gmx.de> |
* Rewrote the UpdateQueue class. It actually works now and would perform screen updates during the vertical refresh, but it causes flickering again since there is no guarantee that screen regions will stay clean from the time that they were scheduled with the UpdateQueue until the UpdateQueue thread transfers them. Therefor it is still disabled. * Refactored a bit the distinction between Invalidate() and CopyToFront(). Invalidate() used to be virtual, but now CopyToFront() is. This was mainly needed for the app_server test environment, because the host window needs to call Invalidate() when the front buffer bitmap is clean. When the UpdateQueue is used, this needs to be CopyToFront(). Now the separation is cleaner in combination with the UpdateQueue. * Fixed a problem in HWInterface::CopyToFront(): When separating the region outside the cursor and the region with the cursor during a transfer, it needs to hold the fFloatingOverlay lock to make sure the cursor is not moved in the meantime. This fixes graphics glitches with remnants of the cursor staying on screen. These could very rarely be observed, but much more often with the accelerated double-buffer mode. * Enabled the accelerated double buffered mode, since it works now very well. I was able to test it with the nVidea driver on an nVideo 7300. It works by allocating a frame buffer twice the height of the configured screen mode. Then all drawing goes into the offscreen portion, including accelerated driver functions. AccelerantHWInterface::_CopyToFront() then uses acceleration to blit the clean regions in the offscreen portion of the frame buffer into the visible part. Please tell me if there are problems, for example when if there is too few video memory, or if a driver does not handle it correctly. To disable it, see src/servers/app/drawing/AccelerantHWInterface.cpp line 511. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28301 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
c5ac899aac8937f6c4a1fd3243560c33839bc36d |
|
20-Jul-2008 |
Stephan Aßmus <superstippi@gmx.de> |
* Refactor the method that actually copies rectangles from the back buffer to the front buffer so that derived classes could override it. * Minor coding style changes. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26542 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
97ee7d0a557283d65918c9eb9e4c2958d0f1928d |
|
12-May-2008 |
Stephan Aßmus <superstippi@gmx.de> |
When drawing is double buffered, there is no excuse for a flickering cursor (including any drag bitmap). HWInterface::HideFloatingOverlays() was plain stupid, I know it did check double buffering at one point, but I must have removed that when messing with it. But copying anything from back to front buffer is now not overwriting the cursor area anymore, which is painted immediatly afterwards. Also moving the cursor invalidates only one rect if old and new cursor area overlap. All these changes should save some cycles too. Added TODO with regard to caching the on-the-fly cursor compositing buffer. If you have * a more recent computer * a decent VESA BIOS which supports your native resolution * don't need video overlays ... I recommend using the VESA driver. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25479 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
ace2d5ee376ad7d772cd313781ea2f912409f299 |
|
02-Apr-2008 |
Stephan Aßmus <superstippi@gmx.de> |
HWInterface::Cursor() and therefor Desktop::Cursor() accessed the current cursor without locking, and did not add a reference while using the cursor. I have tried to solve both problems by introducing a simple ServerCursorReference class, which makes sure that the reference count is properly maintained. There are only two places where this code was even used, from within ServerApp and when taking screenshots. Axel, you mentioned in #837 that the code is unsafe, is this what you meant? This hopefully fixes #837, but it is very hard to reproduce in the first place, I will close the ticket, but it should just be reopened if ever encountered again. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24741 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
b7458c6b960c278bcae8a4d79b96a80bbc4d4ba9 |
|
10-Mar-2008 |
Stephan Aßmus <superstippi@gmx.de> |
RenderingBuffer::Bounds() returns an IntRect, saves a conversion. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24352 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
c8d785a71d7aa6dde4c36e83f97ef71878d7a8ec |
|
24-Feb-2008 |
Stephan Aßmus <superstippi@gmx.de> |
Cursor frame can be expressed using IntRect. Saves a few lines of code too. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24099 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
b1ab9b5f070e8acfe80cbfa640d6f2c99827bc1e |
|
24-Feb-2008 |
Stephan Aßmus <superstippi@gmx.de> |
* ReadBitmap() could mess up the software cursor locking, since it used the BRect version of HideSoftwareCursor() but then called ShowSoftwareCursor() unconditionally. * Renamed Hide/ShowSoftwareCursor() to Hide/ShowFloatingOverlays(). * Removed no longer needed FontLocker. * Implemented AutoFloatingOverlaysHider and got rid of a lot of code duplication this way. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24095 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
a0c4a29fafba981db24672a183bb0c9342469a48 |
|
09-Feb-2008 |
Jérôme Duval <korli@users.berlios.de> |
added B_RGBA15 colorspace, and explicitly print which colorspce is unsupported git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23938 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
c27844865341578ec602735e06ecba0bd188cdeb |
|
15-Oct-2007 |
Axel Dörfler <axeld@pinc-software.de> |
* Introduced a monitor_info structure and means to let it be filled by the accelerant (or the app_server via EDID info). It's still experimental API, and opinions are welcome. * Moved BPrivateScreen into the BPrivate namespace. * Rewrote Screen.h. * Introduced a BScreen::GetMonitorInfo() method, and implemented it in the app server as well (ie. AS_GET_MONITOR_INFO). git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22563 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
4191a211aaf50f4b491e1f574a759810a4e1f779 |
|
12-Oct-2007 |
Axel Dörfler <axeld@pinc-software.de> |
* Started accelerant extension to be able to get the preferred mode from the accelerant, as well as its EDID info. B_GET_PREFERRED_DISPLAY_MODE and B_GET_EDID_INFO are both optional. The preferred mode will be taken from the EDID info if only the latter hook is implemented, or the former returned an error. * Currently, the app_server should correctly set the preferred mode on start, but no accelerant supports that yet, so it's not really tested. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22520 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
e2693621b6e93462629d439effd550df7f64ac49 |
|
30-Sep-2007 |
Axel Dörfler <axeld@pinc-software.de> |
Correctly implemented the missing BBitmap::GetOverlayRestrictions() on the client and the server. This should fix bug #1490, but I haven't tested it yet. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22388 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
91d0586a7dec208ed73904b33684c2ffd02106bd |
|
15-Aug-2007 |
Stephan Aßmus <superstippi@gmx.de> |
* it should be better to lock before accessing the data, even if reading only * after this change, I have not spotted "left behind" cursors again, but it might just be bad luck... git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21966 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
d6f8cacab9b5f89a940d3c18fd2ea436ba54e68c |
|
31-May-2007 |
Axel Dörfler <axeld@pinc-software.de> |
Moved the (currently very simplistic) code to check if a display_mode is valid into it's own (static) method. In case setting the display mode fails, the returned mode is now checked for validity as well. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21282 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
87719fdb8fa342e20fa403d742d9be26ca73f58b |
|
22-Dec-2006 |
Ryan Leavengood <leavengood@gmail.com> |
Added a needed header for the recent ioctl() call addition. Lack of this caused the libbe_test environment build to fail. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19610 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
0c6f77951ed2366737266cae1bf0c2f98842e6f5 |
|
19-Dec-2006 |
Axel Dörfler <axeld@pinc-software.de> |
* Moved VGA planar mode blitting into the VESA kernel driver. * In grayscale mode, the AccelerantHWInterface now sets the palette correctly. * HWInterface now has a fVGADevice set by AccelerantHWInterface which will be used to talk to the VESA driver. * Completed planar blitting for all 4 planes; we now have a perfect 16 color grayscale mode when you choose "Standard VGA mode" in the boot loader with an unsupported graphics card (such as in Qemu). git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19567 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
c46eb09e8f49a4db5b9d6f64af0f5f4082893d9f |
|
19-Dec-2006 |
Axel Dörfler <axeld@pinc-software.de> |
* The 4-bit VGA planar mode is now advertized as B_GRAY8 to the app_server. * The app_server now detects that this mode is being used, and at least correctly copies the 32bit data to the first plane, meaning we have a monochrome output for now (it crashed before, as Stefano reported). git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19565 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
2cfe93e7804edb2817dba26ba9b908efbfa80b06 |
|
04-Dec-2006 |
Stephan Aßmus <superstippi@gmx.de> |
* renamed HWInterface locking to LockParallelAccess() and LockExclusiveAccess() (meaning more or less access to the frame buffer) * extracted the AGGTextRenderer to be a global instance used by each Painter instance (currently, it is thread safe because of the global font lock, so there is some work left in this regard) * gave every ServerWindow it's own DrawingEngine instance, this is work in progress. So far, there doesn't seem to be a regression, but less fighting over the exclusive access to the frame buffer, now each ServerWindow thread can draw in parallel. There is room for improvement, plus I think I'm leaking the DrawingEngine... * changed the locking for the software cursor. ShowSoftwareCursor() can only be called if HideSoftwareCursor(BRect) returned true, or if you called the generic HideSoftwareCursor(), since it needs to keep the cursor lock and unlocks in Show...! * some clean up and renaming in Decorator and friends * moved PatternHandler.h to live along with the .cpp git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19427 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
67491d2adc2fa7050317f8e113c01d5cf700abd7 |
|
29-Nov-2006 |
Stephan Aßmus <superstippi@gmx.de> |
* introduced a listener mechanism to be notified of frame buffer changes in the HWInterface (ie on mode switch) * initialization and shutdown of the HWInterface instance no longer go through DrawingEngine, which had nothing to do with it in the first place (this is in preparation of giving each ServerWindow it's own DrawingEngine instance) * small performance improvement in ViewLayer::ScrollBy() * some cleanup in ServerConfig.h git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19391 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
524c811b5dc2739fe6c28b33fad76b946859a555 |
|
24-Aug-2006 |
Axel Dörfler <axeld@pinc-software.de> |
Renamed HWInterface::GetCursorPosition() to CursorPosition() to match the usual style. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18595 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
b0bc48fbd360f10cee1856e03393c63dcbdd180f |
|
19-May-2006 |
Axel Dörfler <axeld@pinc-software.de> |
Some more GCC 4 and PPC fixes. * Mesa doesn't compile yet, as some PPC specific stuff seems to be missing, Philippe? * Cortex and some other stuff has been marked x86-only, although it's more of a "GCC 2.95.3"-only. * I'm not sure if it's a bug in GCC 4, or if that's what the C standard demands, but sizeof(some_type::some_field) is not valid anymore :-/ git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17515 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
3652a4391798140c3e3e5894a205db0db6d61c48 |
|
19-May-2006 |
Axel Dörfler <axeld@pinc-software.de> |
* Accidently broke overlay (but BerliOS didn't let me commit yesterday :-/), since ViewLayer::SetViewBitmap() did not show the overlay, only updated it. * Simplified overlay handling a bit, removed Overlay::Show(), and IsVisible(), replaced Update() by Configure(). * Made similar changes in the HWInterface as well. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17504 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
0ac013e66f75c5733fcd6bca47300d126b293279 |
|
23-Apr-2006 |
Axel Dörfler <axeld@pinc-software.de> |
* Some refactoring: renamed OverlayCookie to Overlay and put it in its own source file. * An overlay is now also hidden in case its is removed from the window. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17209 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
f7c7883b9f7be15d6ffcc066e0f75e3d878c7923 |
|
23-Apr-2006 |
Axel Dörfler <axeld@pinc-software.de> |
* We now have working video overlay - even though the overlay_token handling is currently broken, mode switches probably fail or result in sudden death (didn't try) it's good enough for Radeon cards and VLC (might work with others as well). * Implemented follow modes for view bitmaps (wasn't taken into account at all before). * Switched to a darker overlay color for now (dunno what exactly makes a good candidate there, but this one is good enough for now). * Added TODO about a race condition in AS_LAYER_SET_VIEW_BITMAP. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17208 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
68bf2de593715bb0f43a0fbbd988bf9f2d651976 |
|
21-Apr-2006 |
Axel Dörfler <axeld@pinc-software.de> |
* Refined overlay support a bit: we now allow as many overlay bitmaps to be created as the graphics driver does. * Also, B_BITMAP_RESERVE_OVERLAY_CHANNEL should now work as expected. * We're no longer using the B_OVERLAY_COUNT hook anymore - that one really looks like a misconception to me; I don't see how it can be useful. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17196 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
37b502f28bf22293b4b060e8577e491d1c299ca8 |
|
21-Apr-2006 |
Axel Dörfler <axeld@pinc-software.de> |
Implemented some more overlay support - the overlay bitmap is now allocated via the graphics driver (but not yet shown on screen). I probably got the meaning of the "overlay count" wrong - I guess that you can allocate any number of overlay bitmaps, but can only see "overlay count" on screen at a time (right now, I only allow to create "overlay count" bitmaps). Stephan? git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17193 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
dd98ed8dfcfe69c729b06f4d3deb9cbc82015552 |
|
19-Apr-2006 |
Stephan Aßmus <superstippi@gmx.de> |
* implemented view bitmap options (B_BITMAP_TILE...) in ViewLayer (for example, fixes NetPositive rendering HTML with a background image) * use BRegion pool everywhere in ViewLayer * WindowLayer update sessions distinguish between different reasons for the update: exposed and requested - on expose updates, the view backgrounds are cleared immidiately (as on R5), to keep the time previous stuff keeps showing as short as possible, while on requested updates, the background clearing is delayed until the client draws something, to keep the time until the client fills a view with content as small as possible to reduce flickering (might need more work, could be buggy yet) * HWInterface and DrawingEngine support delayed syncing to the graphics hardware at least for FillRect/Region. The speed up gained by this is minor though. * HWInterface cursor rendering uses a bit of rounding to avoid the slight transparent shadow around the cursor (I don't know if it is fully correct though, at least the shasow disappeared) git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17172 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
39cdae74a7fc098db3a59a3e9db03b6ad57ab991 |
|
10-Apr-2006 |
Michael Lotz <mmlr@mlotz.ch> |
First steps at getting drag & drop to work properly. Simple drag & drop (draging Tracker items) should work now. Not sure about the negotiated version (with mimetype exchange). Fixed left behind drag bitmaps. Some cleanup. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17058 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
907e89c6e83770685f47219bb625d411602c4694 |
|
08-Mar-2006 |
Stephan Aßmus <superstippi@gmx.de> |
* The EventDispatcher takes care of reference counting the ServerBitmap used for the drag bitmap, see NOTEs on why that is... * moved reference counting of the ServerCursor from Desktop into HWInterface where it is actually used * I hope to have fixed the problems with _DrawCursor when dragging something. At least the reference counting of the ServerCursor was for real, since the HWInterface rejected changes to the cursor while something was dragged, which caused the old cursor to be Released() and deleted each time the mouse moved... git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16657 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
aa1f5437999ab8531f33139c129c6bcaceb74e7a |
|
05-Feb-2006 |
Axel Dörfler <axeld@pinc-software.de> |
Some work on cursors: * Fixed a myriad of bugs all over the place, ranging from locking errors to deleting objects that don't belong to the one deleting them (hello HWInterface!) * Almost all ServerWindow cursor stuff was broken; I've replaced all commands to set a cursor with a single one AS_SET_CURSOR. * Renamed some cursor commands. * Changed the (broken) way ServerApp::fAppCursor was maintained - the application cursor is now NULL as long as possible. * Removed superfluous ServerCursor app signature stuff. * The BApplication will no longer duplicate the default/I-beam cursors, it will just reuse the default ones which now have fixed tokens. * As a result, changing the cursor is now working as expected, closing bug #102. * Rewrote Cursor.h, renamed private members to match our style guide. * Minor cleanup. What's still left to be done is reference counting the cursor objects to make them work right and reliable. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16237 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
ff3abf4d6f7d48ce29fc2ff3e2937cdf89a65b08 |
|
02-Feb-2006 |
Axel Dörfler <axeld@pinc-software.de> |
* Started a naive implementation of BView::SetViewCursor() server-side - doesn't work though, as HWInterface can only draw B_RGB32 cursors... * More build fixes for libbe_test target - it defines __HAIKU__ as well, now git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16211 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
cf6fe303d66468616a0dbadb879b6a8df68bc784 |
|
12-Jan-2006 |
Stephan Aßmus <superstippi@gmx.de> |
* I decided having the cursor obscuring feature in the HWInterface class was not such a bad idea after all. * Reenabled obscuring the cursor in ServerApp. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15925 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
bd5f895aa6831a842170b459e9c01ac1d7b747fd |
|
11-Jan-2006 |
Stephan Aßmus <superstippi@gmx.de> |
* made hiding and unhiding the cursor actually work git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15918 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
7afc7c5074c2a3382be788d22fe999040c582ccb |
|
08-Jan-2006 |
Stephan Aßmus <superstippi@gmx.de> |
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
|
#
f5b6cf65b27a78f055c668b11f03ed6e3187c775 |
|
28-Dec-2005 |
Stephan Aßmus <superstippi@gmx.de> |
* 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
|
#
56a12660275c9f4ea3c8628ba6a0ecfe11ca50f5 |
|
25-Dec-2005 |
Stephan Aßmus <superstippi@gmx.de> |
I never get those right the first time git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15672 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
9d909e25560c098447fd4dddbed7ed48ae8c9748 |
|
25-Dec-2005 |
Stephan Aßmus <superstippi@gmx.de> |
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
|
#
51a523b14792f192490e6a09d13d313f5e870229 |
|
24-Dec-2005 |
Stefano Ceccherini <stefano.ceccherini@gmail.com> |
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
|
#
464f836807201dff68090a7846ac68999a920084 |
|
21-Dec-2005 |
Stephan Aßmus <superstippi@gmx.de> |
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
|
#
2a867ee67407b7fa60947fa329728cc880253d2c |
|
13-Dec-2005 |
Stephan Aßmus <superstippi@gmx.de> |
accelerated software cursor drawing 11 times git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15531 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
62b965a65f1c2e5898e0ec2c294b3d5a24f7761e |
|
10-Dec-2005 |
Stephan Aßmus <superstippi@gmx.de> |
* 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
|
#
02ed46b0de9b1e4f67ef3fc89886a526fa4fa5ed |
|
16-Nov-2005 |
Stephan Aßmus <superstippi@gmx.de> |
* 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
|
#
af8899c4bfd1ff711e0286db3ceda6403deae834 |
|
15-Nov-2005 |
Axel Dörfler <axeld@pinc-software.de> |
Added support for not visible cursors - defaults to invisible now! git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14948 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
0d02a8aabae5a0bbe7a4eabc696b5e245cec47d7 |
|
18-Jul-2005 |
Stephan Aßmus <superstippi@gmx.de> |
fixed B_CMAP8 back to front buffer conversion (blue was missing) git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13757 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
95e42caf132f46a6eba9ac3b0bc03eb9062113ec |
|
16-Jul-2005 |
Stephan Aßmus <superstippi@gmx.de> |
tried to find the bug that causes the wrong area underneath the software cursor to be restored, but failed, the only accomplishment is that the cursor is now showing right from the beginning, not only after one moves the mouse git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13702 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
359c905c57c9d43ce84badcaef859fa94322897c |
|
05-Jul-2005 |
Stephan Aßmus <superstippi@gmx.de> |
offscreen bitmaps work, tested on Haiku as well, supports all colorspaces that BBitmap::ImportBits() supports. It uses a fallback for non-B_RGB(A)32 bitmaps. Added support for B_SUB_PIXEL_PRECISION view flags, though it is a bit hacky, since I had to add it to LayerData, even though it is not a true part of stack data. Added Layer::SetFlags() to enforce code path and update fLayerData. Cleaned up DisplayDriverPainter and DisplayDriver API (changed some const BRect& rect to simply BRect rect in order to be able to reuse it in the code), moved Painter.h, the test environment only draws the changed part of the frame buffer again - this causes a lot less CPU overhead, Painter special cases stroke width of 1.0 to use square caps, which is similar to R5 implementation and removes a lot of problems with non-straight line drawing, ServerWindow uses the DisplayDriver from it's WinBorder instead of the one from the Desktop (needed for offscreen windows, which have their own DisplayDriverPainter), it also checks for GetRootLayer() == NULL, because offscreen layers are not attached to a RootLayer, there was a fix for scrolling which worked at least in the test environment, it is now defunced, because Adi moved _CopyBits to Layer... I need to reenable it later, LayerData has no more fEscapementDelta, also fixed fFontAliasing (which was thought to overriding the font flags, and now works as such again), Desktop initialises the menu_info and scroll_bar_info stuff, which makes ScrollBars work actually... hope I didn't forget something. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13448 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
3dcb3b079ab645a90859eba6505cf2692c291138 |
|
23-Jun-2005 |
Stephan Aßmus <superstippi@gmx.de> |
Added some root layer locking in ServerWindow.cpp when accessing the layer tree. Moved HWInterface management out of DisplayDriverPainter and into Desktop. Removed all the directly hardware related functions from DisplayDriver API. They just called the same HWInterface functions. Now DisplayDriver is much cleaner and ready for being attached to a yet to be written BitmapHWInterface. Clean up of the display mode stuff in Screen and the View-/AccelerantHWInterface. Frequency is now regarded on Haiku. AccelerantHWInterface::GetModeList now works before SetMode has been called. Added MultiLocker from the sample code. HWInterface uses it now in preparation to being used from multiple instances of DisplayDriver. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@13252 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
fbf48e64370ade7c175a58c03739847074be3d66 |
|
04-May-2005 |
Stephan Aßmus <superstippi@gmx.de> |
Enabled HW acceleration for CopyRegion(). Tested on Haiku and it works. I also implemented FillRegion and InvertRegion. But using different acceleration hooks after one another freezes Haiku, app_server, the accelerant or whatever. I have no clue about accelerants, so if a knowledgable someone would have a look at AccelerantHWInterface.cpp, that'd be great. The software cursor stuff has a cosmetical bug with regards to CopyRegion() too, I don't understand it yet. I also tried to improve StringWidth() and DrawString() preformance. I confirmed that the glyph cache is actually used, but AGGTextRenderer::RenderString() is a dog. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12573 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
d3194176a30628f844cfcfdb01bf93256e4ed525 |
|
03-May-2005 |
Stephan Aßmus <superstippi@gmx.de> |
added support for software cursor needed for single buffered mode git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12561 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
ded5874ea2183328e81015e199f54a3dd786fc60 |
|
20-Apr-2005 |
Stephan Aßmus <superstippi@gmx.de> |
Implemented changes necessary for single buffered mode, it is turned off for now, because the soft cursor is currently not being taken care of. We will still use double buffering if the screen color space is not 32 bits, too. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12449 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
e742e3e106eb77f506e827b18f4a35e015e55f61 |
|
18-Apr-2005 |
Stephan Aßmus <superstippi@gmx.de> |
refactoring and cleanup in LayerData and friends, it shows what I mean by "forced code paths" for example in coupled font size and view scale, added a couple TODOs, disabled decoupled frame buffer transfers, it is buggy and deadlocks for some reason... git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12441 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
74b3612ac3f32d32a9f2aa97d0a50746e088d3ea |
|
18-Apr-2005 |
Stephan Aßmus <superstippi@gmx.de> |
refactoring, speedup by decoupling back to front transferes from drawing and usage of special memcpy routine, minor speedups in Painter git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12437 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
d78aea1846f656b1703bac5b59300982b4eab39a |
|
13-Apr-2005 |
Stephan Aßmus <superstippi@gmx.de> |
hides a bug where we appearently read from the cursor out of bounds because of float to int converting issues... need to investigate that. In any case, I got the cursor position thing completely wrong, my intentions of setting it to 0.5, 0.5 were something else... git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12385 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
bd6b1617ec713e87ebef98f14af96e46d0ca7bbb |
|
12-Apr-2005 |
Stephan Aßmus <superstippi@gmx.de> |
a few cosmetic changes git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12332 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
89b3c19c8a86f03a82d0410bd471caf9d2aaceba |
|
30-Mar-2005 |
Stephan Aßmus <superstippi@gmx.de> |
ViewHWInterface updates are a bit smoother now git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12175 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
d3db964ed0075963d9ecbb708dc37a7f5ce649c3 |
|
29-Mar-2005 |
Stephan Aßmus <superstippi@gmx.de> |
code refactoring, moved common stuff into the base class git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12129 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
e33b90ea35564c5fe7d2f1775f5ff0fba2005cd9 |
|
28-Mar-2005 |
Stephan Aßmus <superstippi@gmx.de> |
implemented cursor support in the DisplayDriverPainter git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12107 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
53115c9920402bcd7597d8d6f4090b308a02cc24 |
|
27-Mar-2005 |
Stephan Aßmus <superstippi@gmx.de> |
moved the place of implementation of locking in DisplayDriver, because the Painter version has it elsewhere. the DisplayDriver locking API is now abstract, the same locking is now in DisplayDriverImpl, Painter version uses HWInterface for locking git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12084 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
3294d07b156f3329d8c5839d297089ae84d5ffa7 |
|
26-Mar-2005 |
Stephan Aßmus <superstippi@gmx.de> |
abstract base class and implementation using BView and BWindow of an interface to a graphics card, UpdateQueue doesn't work yet, it was going to be used to decouple frame buffer transfers to the front buffer from the drawing in the back buffer git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12056 a95241bf-73f2-0310-859d-f6bbb57e9c96
|