#
9a7906ea |
|
31-Jan-2022 |
Máximo Castañeda <antiswen@yahoo.es> |
PatternHandler: remove unused code hrev17117 implemented B_OP_COPY with a special treatment for text. hrev21929 introduced the color cache to speed up that text drawing. hrev52753 removed the special treatment of text in B_OP_COPY, but left the color cache and the text flag behind. Change-Id: Ib506c80a660e829132bce3ec1cb354fcfbab266c Reviewed-on: https://review.haiku-os.org/c/haiku/+/4931 Reviewed-by: waddlesplash <waddlesplash@gmail.com>
|
#
644c29d0 |
|
07-Jan-2022 |
Augustin Cavalier <waddlesplash@gmail.com> |
Adjust all in-tree applications after BBitmap::ImportBits API changes. Change-Id: If3a06f35c01089cdbb696de479984f2b59fce7a0
|
#
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>
|
#
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>
|
#
d99d8dbd |
|
27-Aug-2020 |
X512 <danger_mail@list.ru> |
app_server memory management: use ObjectDeleter to mark ownership Make object ownership explicit by use of ObjectDeleter where possible. Change-Id: I499a00aa3390d1510ae284419e73faffa5166430 Reviewed-on: https://review.haiku-os.org/c/haiku/+/2695 Reviewed-by: Adrien Destugues <pulkomandy@gmail.com> Reviewed-by: Alex von Gluck IV <kallisti5@unixzen.com>
|
#
4ad808b6 |
|
12-Jul-2020 |
Adrien Destugues <pulkomandy@pulkomandy.tk> |
app_server: Fix clipping computation in DrawArc The clipped rect was extended with the stroke width, and then the result was overwritten. Fixes #3130.
|
#
2e499128 |
|
07-Jun-2020 |
X512 <danger_mail@list.ru> |
app_server: fix transformations in BPicture Fixes #16122, #16147. Change-Id: Iee7aa8a2325d34a526578a58507ea3690459c8d7 Reviewed-on: https://review.haiku-os.org/c/haiku/+/2898 Reviewed-by: waddlesplash <waddlesplash@gmail.com>
|
#
2d69e313 |
|
09-Jun-2020 |
waddlesplash <waddlesplash@gmail.com> |
Revert "app_server: fix transformations in BPicture" This reverts commit b8e5671d5318e59ad4e36f047940521d18d1f5ed. Reason for revert: Broke all builds. Change-Id: Ie7c5b4a3c877894a1dc49a9de7a19f79e7eb2ab7 Reviewed-on: https://review.haiku-os.org/c/haiku/+/2897 Reviewed-by: waddlesplash <waddlesplash@gmail.com>
|
#
b8e5671d |
|
07-Jun-2020 |
X512 <danger_mail@list.ru> |
app_server: fix transformations in BPicture Fixes #16122, #16147. Change-Id: I16a38919d25836546389aff6093415eda781668f Reviewed-on: https://review.haiku-os.org/c/haiku/+/2889 Reviewed-by: Stephan Aßmus <superstippi@gmx.de>
|
#
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>
|
#
f8550e54 |
|
02-Jan-2019 |
Stephan Aßmus <superstippi@gmx.de> |
Added two DrawStringDry() versions for obtaining pen location only When recording into a BPicture (ServerPicture, actually), one cannot simply record the commands only, when the drawing itself would modify state. This affects all drawing commands that change the pen location. Therefore it is necessary to have a way to "dry-run" drawing a string in order to know the pen location that would result. This is what these two new methods help achieve. Change-Id: Ic399a5513f18c12c16c0ab10a55e768c1b30e4e0 Reviewed-on: https://review.haiku-os.org/816 Reviewed-by: Rene Gollent <rene@gollent.com>
|
#
25dbf74b |
|
10-Nov-2015 |
Julian Harnath <julian.harnath@rwth-aachen.de> |
BView: add methods for affine translation/scaling/rotation * BView::TranslateBy(), BView::ScaleBy() and BView::RotateBy() allow to conveniently modify the current affine transformation. This makes it unnecessary to first read the current transform, modify it, and then set it again. Uses the new Pre...() methods of BAffineTransform. * Also, remove setting the transform "through" to the BView even while recording a BPicture, as this now results in transforms being applied more than once.
|
#
d56beda4 |
|
22-Jul-2015 |
Julian Harnath <julian.harnath@rwth-aachen.de> |
app_server: optional coordinate shifting in renderer_region * agg::renderer_region gets an extra feature which allows to optionally shift the coordinates by a specified offset. * This allows to shift coordinates at the lowest level, even below the transformations done by BAffineTransform (which happen in the painter, right before rasterization). Needed for layers support: shifts the origin of the layer bitmaps to their position in the view while keeping all transformations (BView origin/scale transforms as well as BAffineTransforms) intact. The offset for the layer bitmaps within their parent view is determined by the bounding box and is then fixed, it must not be altered while the layer's BPicture is played into the bitmap. If this offset were added to the BView origin or as translation in the BAffineTransform, it would be further transformed by the BView scale or the other affine transform parameters. Thus, we need another low-level offset mechanism which is even below BAffineTransform's transformations.
|
#
d30a0a6e |
|
23-May-2014 |
Stephan Aßmus <superstippi@gmx.de> |
app_sever: Fix more mixups of transformed clipping bounds
|
#
81507fa4 |
|
23-May-2014 |
Stephan Aßmus <superstippi@gmx.de> |
app_server: Fix transformed DrawString()... ...when the transformation moves the text into the view bounds. The rect returned from Painter::BoundingBox() is already transformed, as should be expected.
|
#
1d6f73bc |
|
19-May-2014 |
Adrien Destugues <pulkomandy@pulkomandy.tk> |
Follow-up fixes for FillRect+transforms * Factor out AlignRect to avoid code duplication * Give the right rectangle to the OverlayHider.
|
#
79eb23a8 |
|
19-May-2014 |
Adrien Destugues <pulkomandy@pulkomandy.tk> |
Fix handling of filled rectangles with transforms. The DrawingEngine didn't properly make a distinction between the rectangle being filled and the damaged region on screen. This led to unexpected results when using BAffineTransform.
|
#
eb431663 |
|
11-Mar-2014 |
Adrien Destugues <pulkomandy@pulkomandy.tk> |
app_server & interface kit: support fill rules. * BView gets SetFillRule/FillRule methods. The fill rule is part of the view state. * The B_NONZERO rule is the default. This is what we implemented before. * The B_EVEN_ODD rule is the other common possibility for this, and we need to support it to help WebKit to render properly.
|
#
89f8b7a1 |
|
08-Feb-2014 |
Stephan Aßmus <superstippi@gmx.de> |
app_server: Fix computing bounding boxes for transformed stuff. * In DrawingEngine, clipping is computed before drawing happens. This did not take into account when drawing primitives can now be transformed. Fixes drawing glitches in the Transformation test when the round rect is scrolled into view and it was previously prevented to draw. * Fixed clipping rect computation for the sanitized StrokeRoundRect() implementation which centers the stroke on the rect.
|
#
215119a1 |
|
28-Jan-2014 |
Stephan Aßmus <superstippi@gmx.de> |
app_server: Move AlphaMask management into DrawState. * Give DrawState a real copy constructor, handle deriving in PushState(). (Although clipping region and alpha mask are not cloned, which is on the other hand just what's needed for now.) * Combining alpha masks from previous states is not yet handled. * Remove SetAlphaMask() from DrawingEngine and Painter. It is now done in SetDrawState().
|
#
f08d5477 |
|
28-Jan-2014 |
Adrien Destugues <pulkomandy@pulkomandy.tk> |
Add Alpha Masking support in ClipToPicture Use AGG to implement ClipToPicture in a faster and better way. There are things missing in this initial implementation: * No support for PushState/PopState saving and restoring the picture. * No support for nested clipping through PushState * The clipping doesn't happen where you expect it when using SetScale() * There are artifacts when scrolling and resizing clipped views * The implementation uses more memory than it needs, as the clipping bitmap is stored as RGBA32, yet only the alpha channel is used * The clipping bitmap is rendered more times than it needs to. We need some caching here.
|
#
f4c2f7eb |
|
10-Jan-2014 |
Jonathan Schleifer <js@webkeks.org> |
Remove variable length arrays of non-PODs. Variable length arrays of non-PODs are not part of the C++ standard, but a GNU extension that never worked correctly. Instead, BStackOrHeap array is used now, which makes sure that it's not too big for the stack, calls all constructors and is valid C++.
|
#
e1be7d07 |
|
04-Aug-2012 |
Alex Smith <alex@alex-smith.me.uk> |
Fixed a 64-bit calculation error.
|
#
76ab3f88 |
|
18-Mar-2010 |
Stephan Aßmus <superstippi@gmx.de> |
Basically, this changeset implements BShape::ArcTo(). In more detail: * Added BShape::ArcTo() and BShapeIterator::IterateArcTo(), using a previously unused virtual slot. (Added the symbols for binary compatibility for GCC2 and GCC4.) * Added operator=(), operator==() and operator!=() to BShape. * Added BShape::BezierTo() version taking three points, which is sometimes more convenient. * Added the four new shape data ops OP_LARGE_ARC_TO_CW, OP_LARGE_ARC_TO_CCW, OP_SMALL_ARC_TO_CW and OP_SMALL_ARC_TO_CCW. For a single arc, provided the radius is large enough, there are four possibilities to draw the arc, these are controlled by the two boolean flags to ArcTo() and mapped to the new commands accordingly. * Some style cleanup in Shape.cpp (sorry for mixing it up, but it gets worse below...) * Added ShapeTest to src/tests/servers/app. * Changed the way BShapes are transformed from view to screen space in the app_server. For arcs, it would be nontrivial to apply a proper transformation, it's much easier to let AGG take care of it. This affects ServerPicture as well. * Wrapped iterating the BShape into try/catch blocks in ShapeIterator. But I really don't understand the purpose of the class in the first place. Maybe it can now be dropped, since coordinates don't have to be transformed in place anymore. * Refactored copy&paste shape iteration code in Painter. The transformation to screen space happens there. * Since RemoteDrawingEngine needed to be adopted anyway, I also updated it for the new DrawString() with offsets version. But the client still needs to be adapted. * Style cleanup in Painter.h git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35905 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
77e5acc0 |
|
15-Mar-2010 |
Stephan Aßmus <superstippi@gmx.de> |
* Extended the BView drawing API by a DrawString() version that takes an array of locations, one for each glyph. * Added a test for the new functionality. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35865 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
a0b37b6e |
|
11-Mar-2010 |
Stephan Aßmus <superstippi@gmx.de> |
Tried to fix all issues with running a DEBUG build of app_server. * CopyRegion should not need the HWInterface to be exclusive locked. * BitmapDrawingInterface does not need to be locked at all, since it doesn't use a shared HWInterface instance. * Window and Desktop should lock the HWInterface appropriately before invoking CopyRegion() on the DrawingEngine. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35822 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
8b56f14a |
|
12-Mar-2010 |
Stephan Aßmus <superstippi@gmx.de> |
Fixed debug build. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35820 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
aeb68978 |
|
15-Feb-2010 |
Axel Dörfler <axeld@pinc-software.de> |
* Removed ServerCursorReference in favour of BReference. * Simplified the Desktop::SetCursor() code a bit. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35471 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
d9990014 |
|
07-Nov-2009 |
Axel Dörfler <axeld@pinc-software.de> |
* Fixed a few operator precedence bugs (&& ... & ... &&). * Cleanup. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33931 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
|
#
12349c7d |
|
05-Apr-2009 |
Stephan Aßmus <superstippi@gmx.de> |
Begun to use structs for the BView<->app_server communication. This makes the protocoll less prone to errors, reduces possible points of failure and most importantly, reduces the number of function calls to the link API. I only know the numbers for StrokeLine(), which I tested via the Benchmark test app. With this change, drawing random colored and positioned lines actually doubled in speed. On the BView side, the calls to ServerLink::Attach() only halfed, while on the app_server side, the number of calls to ServerLink::Read() is now 1/4th. It will also be worth investigating why the link stuff is so slow at all. I also optimized BView::DrawString() a lot in this change, but I don't have any numbers yet. Some other commands which used multiple Attach()/Read() calls were also optimized, at least the most important ones. Begin/EndLineArray() was also pretty bad on the app_server side. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29937 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
339676b6 |
|
02-Apr-2009 |
Axel Dörfler <axeld@pinc-software.de> |
* This time, I actually got it right, thanks Alexandre... git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29866 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
56ab1944 |
|
02-Apr-2009 |
Axel Dörfler <axeld@pinc-software.de> |
* Fixed Stippi's favourite typo ("appearantly" does not exist). git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29861 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
64eb49fd |
|
15-Feb-2009 |
Stephan Aßmus <superstippi@gmx.de> |
* Cleanup in the Gradient department. No fuctional change. Renamed BGradient::color_step to BGradient::ColorStop as it's called everywhere else. Also renamed BGradient::gradient_type to just BGradient::Type. Renamed BGradient::Type() to GetType(). * Simplification of method names in Painter.cpp. Some not yet complete and yet inactive code to accelerate vertical gradients (bypassing AGG for this special case). git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29214 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
fb3e35fc |
|
22-Jan-2009 |
Michael Lotz <mmlr@mlotz.ch> |
Fixing all headers/namespaces/name lookup problems that hinder a GCC 4.3.2 build. I sure hope that this doesn't break the build for anyone else. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28992 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
ce5d6472 |
|
19-Jan-2009 |
Stephan Aßmus <superstippi@gmx.de> |
* Renamed the drawing functions in DrawingEngine to remove the *Gradient part. In general, there is a lot of code duplication now, also in Painter. I will need to find a way to elliminate this again. Also, all the stroking functions should be gradient enabled as well. * Improved the look of the DefaultDecorater, inspired by the patch from Dennis Washington. I did not adopt the changes which give backwards compatibility problems, though, like changing the window border width or the single border decorator color. But I reckon these changes are overall even a bit smoother. * Fixed a long standing decorator bug, where the resize area of the border was visually different than the click recognition. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28951 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
0a31071e |
|
28-Nov-2008 |
Axel Dörfler <axeld@pinc-software.de> |
stippi+axeld: * DrawString() took the fast clipping path for rotated fonts which didn't work out (visible when moving a window over the rotated texts in DriveSetup). * Also, made it work correctly when using sheared fonts. * Fixed typo. * Automatic whitespace cleanup. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28741 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
8b8e062d |
|
23-Oct-2008 |
Stephan Aßmus <superstippi@gmx.de> |
* DrawingEngine::CopyBits() was invalidating the wrong region (without offset) when the HWInterface was using acceleration and at the same time double buffering. * _CopyToFront() should always be used, since it calls a protected virtual that derived classes of HWInterface depend on. This fixes some graphics glitches in certain situations. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28300 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
991547ef |
|
14-Oct-2008 |
Stephan Aßmus <superstippi@gmx.de> |
Patch by Artur Wyszynski: * Implemented BGradient, BGradientLinear, BGradientRadial, BGradientDiamond, BGradientConic and BGradientRadialFocus new Interface Kit classes. * Implemented all the (AGG-based) backend necessary in the app_server to render gradients (Painter, DrawingEngine) * app_server/View can convert a BGradient layout to screen coordinates. * Added BGradient methods of the Fill* methods in BView. * Implemented a test app and added it to the image as a demo. * Adopted Icon-O-Matic and libs/icon in order to avoid clashing with the new BGradient class. Re-use some parts where possible. Awesome work, Artur! Thanks a lot. Now a more modern looking GUI has just become much easier to implement! :-) TODO: * Remove the need to have gradient type twice in the app_server protocol. * Refactor some parts of the patch to remove duplicated code (Painter, DrawingEngine). * Adopt the BPicture protocol to know about BGradients. * Review some parts of the BArchivable implementation. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28109 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
3580c2cf |
|
30-Sep-2008 |
Karsten Heimrich <host.haiku@gmx.de> |
* remove png dump from app_server git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27802 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
162a7f5f |
|
28-Jul-2008 |
Stephan Aßmus <superstippi@gmx.de> |
* Implemented new BView drawing functions DrawBitmap[Async]( const BBitmap* bitmap, BRect bitmapRect, BRect viewRect, uint32 options). Only option so far is B_FILTER_BITMAP_BILINEAR. * BView::DrawBitmap[Async](const BBitmap* bitmap, BRect viewRect) was accessing the bitmap pointer without checking it. Would therefore crash when passing NULL, unlike the other methods. * The BPicture code already reserved room for the BBitmap flags, but did not store the actual flags and neiter use them for anything. Since the bitmap data is stored anyways, the bitmap creation flags do not matter. So I reused this for the new bitmap drawing options. * Rewrote Bitmap.h and removed the B_BITMAP_SCALE_BILINEAR flag again. * Tried to optimize Painter::_DrawBitmapBilinearCopy32() a little by giving the compiler better hints. There seems to be a marginal, possibly imagined speed increase < 0.05 ms. ;-) git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26665 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
576305a5 |
|
20-Jul-2008 |
Stephan Aßmus <superstippi@gmx.de> |
* Adopt the code to handle the case that even a HWInterface instance with hardware accelerated functions could be double buffered. * Align the rectangle used for arc drawing like those for ellipsis. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26544 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
93016537 |
|
08-Jul-2008 |
Stephan Aßmus <superstippi@gmx.de> |
Check if the Painter even has a clipping region set before trying to take the short cut when no text needs to be rendered. I've seen a crash yesterday in the app_server test environment when the decorater was drawing something, although it may also have been because I had a screwed up objects folder where some objects were not recompiled because I am switching back and forth between two app_server code folders. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26323 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
018b0c25 |
|
11-Jun-2008 |
Michael Lotz <mmlr@mlotz.ch> |
* The StrokeLine() variation that takes a rgb_color did change the drawing state of the painter without restoring it afterwards (HighColor and DrawingMode). This function is only used in decorators, but as such it could lead to strange effects. When clicking and holding the close button on the R5 MidiPlayer for example, the background of the scope would suddenly become the color of the close buttons middle line. As the drawing mode was also overwritten this could probably have lead to text rendering issues when zooming applications. As I didn't find a easy way to reproduce such a thing, this is only theory though. * Implement the missing IsExclusiveAccessLocked() method in the DrawingEngine which is not used at the moment. If corresponding debug output is generated though, it reveals possible locking issues with CopyRegion(). * Remove an empty line in the LineArrayData struct. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25934 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
|
#
f306ef43 |
|
17-Mar-2008 |
Stephan Aßmus <superstippi@gmx.de> |
* Fix build of app_server test environment by implementing atomic_get(), maybe this should be the assembler version we use for x86, but is probably fine for the purpose of the test environment (only BString uses this) * Fix semantics of DrawingEngine::CopyToFront() which I recently introduced, for the fake accelerant of the test environment, we do need to call Invalidate(), not CopyBackToFront() directly. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24422 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
18212e76 |
|
10-Mar-2008 |
Stephan Aßmus <superstippi@gmx.de> |
* Made it possible to supress automatic back to front buffer copying of the rectangle area that is touched by a drawing command. * Added a CopyToFront(BRegion) method which copies a complete region from the drawing/back buffer to the front buffer. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24353 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
8a1c136e |
|
10-Mar-2008 |
Stephan Aßmus <superstippi@gmx.de> |
Use the front buffer for screenshots always, otherwise we don't get the contents of BDirectWindows for setups where the app_server uses double buffering mode. I didn't test the change, but the way the cursor is optionally copied into the bitmap (which might now be not 32 bpp) looks very flexible. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24346 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
4d1dd3bc |
|
24-Feb-2008 |
Stephan Aßmus <superstippi@gmx.de> |
Use the AutoFloatingOverlaysHider in the remaining cases where overlays were hidden regardless of the affected area. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24098 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
|
#
ff852457 |
|
25-Oct-2007 |
Stephan Aßmus <superstippi@gmx.de> |
* fixed the crashing result of bug #634, check if the supplied region falls within the frame buffer bounds. This should not happen, and I am going to search for the cause next, but at least app_server dosn't crash anymore in this context. Left a comment on my findings so far. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22721 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
158001f5 |
|
12-Sep-2007 |
Stephan Aßmus <superstippi@gmx.de> |
* fractional rects need to be aligned if not drawing in subpixel precise mode, by now, I feel there is too much code involved in this... I guess I should really move this to stuff to ViewLayer::ConvertToScreenForDrawing()... git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22223 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
56184452 |
|
26-Aug-2007 |
Stephan Aßmus <superstippi@gmx.de> |
* implement FillRect() with B_OP_INVERT using hardware acceleration like FillRegion() is already doing (untested) git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22059 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
f7e1df75 |
|
16-Aug-2007 |
Stephan Aßmus <superstippi@gmx.de> |
* get rid of RGBColor usage where it is not needed, this simplified many things, possibly making them a little faster too * mess with decorator button size calculation to make the whole layout scale more agreeable with the font size (no more fixed offsets/insets), but it is work in progress * DefaultDecorator no longer allocated the border color array, it is part of the object now * small memory footprint optimizations in ViewLayer, Decorator and WindowLayer git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22003 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
a2d64753 |
|
13-Aug-2007 |
Stephan Aßmus <superstippi@gmx.de> |
* fixed usage of hardware accelerated inverting, of course we shouldn't do it again in software after we have done it in hardware... git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21921 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
fe914c98 |
|
09-Aug-2007 |
Stephan Aßmus <superstippi@gmx.de> |
* added a version of SetFont() that takes a DrawState* to DrawingEngine and Painter, that is needed to be able to tell if anti-aliasing is to be used, since the flags in the font can be overruled by the flags in the view... * fixes aliased fonts reliably, tested with FontDemo git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21869 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
a748b927 |
|
08-Aug-2007 |
Stephan Aßmus <superstippi@gmx.de> |
* make sure that the pattern used for line arrays is B_SOLID_HIGH and that the previous pattern is restored after execution git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21853 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
4971740e |
|
06-Aug-2007 |
Stephan Aßmus <superstippi@gmx.de> |
* in FillRegion(), check if the current drawing mode is B_OP_INVERT, and then use hardware acceleration... found out this is what our BTextView is actually using, that's why it never used hardware acceleration for invert rect/region before. Have not tested this on real hardware yet. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21843 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
c9d2046f |
|
04-Aug-2007 |
Stephan Aßmus <superstippi@gmx.de> |
* after my last changes to font rendering, it was about 15% slower than before (although there should be much less lock contention) * with this change, there is quite a bit of cleanup, text drawing is now about 20% faster than before the original changes to font caching, mostly due to turning off the kerning feature, which at the moment gives absolutely no benefit. The correct way of doing it might be to use kerning depending on the provided glyph spacing mode * removed fPenLocation from Painter, the usage should be more correct now, since it is now consistently applied before the coordinate transformation from view to screen (also for DrawShape() now, before any view scaling and origin offset) * Painter no longer has it's own instance of a ServerFont, instead it uses its AGGTextRenderer instance, which was per Painter again after the last change, and not global anymore, made _UpdateFont() useless * When using GlyphLayoutEngine, it supports a second pass with the same FontCacheEntry through the introduction of a FontCacheReference. This speeds up DrawString a little, since it needs to calculate the bounding box for the string, and then draw the string in a second pass. This is now done with only one FontCacheEntry lookup * I also tried to optimize the on-the-fly conversion of UTF8->CharCode away, since it was done four times per DrawString, but surprisingly, it proofed to be a slight slowdown. * introduced a shortcut in DrawingEngine::DrawString() which avoids calculating the bounding box, we are now a tiny bit faster to figure out that we don't need to draw any string than Dano In the test environment (drawing to offscreen bitmap and blitting to screen eventually), text rendering is now about 3.7 times _faster_ than Dano text rendering (directly to screen), for untransformed text. Unfortunately I cannot test on the same machine in accelerant using version of the test environment. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21822 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
2222864e |
|
02-Aug-2007 |
Stephan Aßmus <superstippi@gmx.de> |
* complete overhaul of the font/glyph caching * the previous AGG implementation is superfluous * the new implementation is based on that one, but in a way that allows read/write locking to the list of cache entries (fonts) as well as read/write locking to the cached glyphs per individual font cache entry * new GlyphLayoutEngine.h, which is to be the central place for layouting glyphs along the baseline. It handles the locking for getting the font cache entries. It works by giving it a template class GlyphConsumer which does the actual work. * changed AGGTextRenderer to use the new font cache * changed ServerFont::StringWidth(), and the bounding box stuff to use it * changed DrawingEngine, it doesn't need the global font lock anymore * our BFont thought that GetBoundingBoxesAsGlyphs and GetBoundingBoxesAsString is the same, which of course it isn't, hence the two separate functions... AsGlyphs just gets the bounding box of each glyph in a string, not treating the string as an actual word AsString adds the offset of the glyph in the word to the bounding box * changed ServerProtocol.h accordingly for the different bounding box meaning git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21797 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
38287e02 |
|
22-Jul-2007 |
Stephan Aßmus <superstippi@gmx.de> |
* completed my changes to DrawState handling, the current DrawingState of the active ViewLayer is now always mirrored in the Painter instance of a ServerWindow, so that it doesn't need to be synced on every drawing command, this was previously incomplete for font handling * removed the DrawState parameter from all the DrawingEngine functions * adjusted ServerWindow and ServerPicture accordingly * made sure that string related functions used by non-drawing related parts (ServerApp, Decorator) don't interfere with the current drawing state * moved AS_SYNC handling from _DispatchViewMessage to _DispatchMessage, it is actually a window message and doesn't require fCurrentLayer to be valid * fixed bug #1300, fCurrentLayer was not updated when a ViewLayer was deleted by client request which happened to be fCurrentLayer (I am now handling it so that the parent becomes the current layer, could be wrong) * AGGTextRenderer is no longer using it's own scanline, which should save a few bytes RAM, the Painter already had such an object * StringWidth() in AGGTextRenderer is now taking the escapement_delta into account * Painter::StrokeLine() doesn't need to check the clipping as much, since that is already done in DrawingEngine * if a ServerWindow message is not handled because fCurrentLayer is NULL, a reply is sent in case the messages needs it (client window could freeze otherwise, waiting for the reply for ever) * removed unused AS_SET_FONT and AS_SET_FONT_SIZE * added automatic RGBColor -> rgb_color conversion to RGBColor.h * minor cleanup for 80 char/line limit git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21685 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
0896fce5 |
|
18-Jul-2007 |
Stephan Aßmus <superstippi@gmx.de> |
* since every window has it's own Painter instance, the drawing state does not need to be "set" (transfered from the "current" view to the painter) for each singly drawing command. Now, painter is synchronized whenever the client changes the drawing state of the current view, or when the current view changes. * the screen offset of the current view has become part of the Painter state, in the PatternHandler. This fixes a bug in which moving or scrolling a view which used patterns for drawing, resulted in visual glitches (seams in the pattern). NOTE: this patch is a bit work in progress, most importantly, it is not complete with regards to text rendering. More specifically, the server applications and other parts of the appserver might set a font on the Painter and this might mess up the synchronization. But this happens on the Desktop's Painter instance (only?), and so it is not a problem. I did observe some drawing bugs with this patch though, so bug reports are welcome, particularily how to reproduce these bugs reliably. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21643 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
527b4ad1 |
|
15-Dec-2006 |
Stephan Aßmus <superstippi@gmx.de> |
Gracious me, I forgot to actually turn on parallel frame buffer access! Seems to make some difference too. Nothing dramatic though. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19527 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
|
#
846cc588 |
|
14-Sep-2006 |
Stephan Aßmus <superstippi@gmx.de> |
* a fix for the bug where clicking a window decor button drew over the mouse cursor. The problem is actually something else: non-straight lines extend a little past the calculated rectangle git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18842 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
4423855c |
|
13-Sep-2006 |
Stephan Aßmus <superstippi@gmx.de> |
This is the kind of bug you can search for hours. At first, I suspected a concurency problem in the DrawingEngine, so there is some debugging stuff added, as well as some unnecessary locking removed there. The problem was in Painter though, in that certain functions adjusted clipping at the "rasterizer level", while some other functions didn't care about that. Now the clipping is consistently set at the rasterizer level (rough estimate to avoid scanline generation outside real clipping region bounds). There are a number of bugs fixed by this, I'm going to find out later, what their ticket numbers are... Mouse preflet draws the mouse now, Backgrounds preflet draws the screen reliably... probably more, anything to do with bitmaps, round rects and possibly ellipses. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18828 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
9ecf9d1c |
|
26-Aug-2006 |
Ingo Weinhold <ingo_weinhold@gmx.de> |
Merge from layout management branch. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18649 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
|
#
65abd9df |
|
05-May-2006 |
Stephan Aßmus <superstippi@gmx.de> |
* Painter switches back correctly from using B_OP_COPY for text to using the "normal" B_OP_COPY for lines and such that works more like B_OP_OVER actually (for example, the slider in VLC will look much better, but also other stuff) * combined Stroke and FillEllipse() into DrawEllipse() and fixed some longstanding issues, ellipses are now correctly placed (aligned) and of the correct size * removed locking in the DrawingEngine drawing functions, since you need to have the DrawingEngine locked anyways for the clipping to stay what it is (and that's already the case elsewhere in the code) * simplified ConstrainClippingRegion, the NULL version was never useful and also locking is removed, see above summary: slight speed improvements, cleanup and bugfixes... git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17329 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
022cdecc |
|
03-May-2006 |
Stephan Aßmus <superstippi@gmx.de> |
simplified polygon and bezier drawing methods, made them more efficient git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17311 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
3ca1310a |
|
23-Apr-2006 |
Stephan Aßmus <superstippi@gmx.de> |
* cleaned up and optimized a lot setting the font in Painter and AGGTextRenderer (when switching the DrawState for font stuff) * removed unused stuff from the font signature generation that is used to synchronize the font cache * finally nailed that bug that made glyphs of the wrong size appear within lines of text (the problem basically was that outside code messed with the freetype library instance while our glyph cache thought the library was last setup by itself) git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17217 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
|
#
6dcf803e |
|
06-Apr-2006 |
Marcus Overhagen <marcusoverhagen@gmail.com> |
removed some off-by-one errors. replaced cursor->Bounds().IntegerWidth() with cursor->Width() which is equal to cursor->Bounds().IntegerWidth() + 1 git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17032 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
5d0c78f4 |
|
01-Apr-2006 |
Stephan Aßmus <superstippi@gmx.de> |
skip hardware acceleration for small regions, should speed up rendering of small regions in the same way it helped small rects git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16955 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
8e56a3ff |
|
19-Mar-2006 |
Stephan Aßmus <superstippi@gmx.de> |
* some cleanup (removed unsued functions, regrouped others) * FillRect() doesn't use the HW acceleration if the rects are too small (< 100 pixel area, about the sweet spot on my box) -> the same change should be used for FillRegion as well. (4x speed up of rendering large amounts of small rects) * replaced dynamic allocation and freeing of blit_params and fill_rect_params in the accalerant based HWInterfaces on the heap with caching to make using the accelerated functions a little less expensive * fixed a bug in bypassing Painter for B_OP_OVER when the pattern was B_SOLID_LOW (nothing should be rendered) git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16841 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
0581480c |
|
13-Mar-2006 |
Michael Lotz <mmlr@mlotz.ch> |
* Fixed ServerBitmap::ImportBits() to use the correct width/height * Extended ConvertBits() to properly handle negative offsets and overlapping lines * Implemented blitting the software cursor to the bitmap returned from ReadBitmap() Note: In the future we will have to directly use the final graphics buffer for ReadBitmap() if we want DirectWindow output too (R5 includes it). I don't know how R5 handles the hardware cursor though. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16766 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
30ce5790 |
|
11-Mar-2006 |
Stephan Aßmus <superstippi@gmx.de> |
added two TODOs git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16719 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
2a6e9718 |
|
05-Mar-2006 |
Michael Lotz <mmlr@mlotz.ch> |
Actually commit the change to ReadBitmap()... git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16594 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
a97ee677 |
|
05-Mar-2006 |
Michael Lotz <mmlr@mlotz.ch> |
Ensure that the cursor is not drawn (it was visible in single buffered mode). Drawing the cursor is not implemented yet. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16582 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
acfad792 |
|
04-Mar-2006 |
Michael Lotz <mmlr@mlotz.ch> |
Added an ImportBits() function to ServerBitmap and used it in ReadBitmap(). Should work for all colorspaces now. Magnify does now work correctly, fixed bug 197. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16581 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
f1fb383d |
|
02-Mar-2006 |
Michael Lotz <mmlr@mlotz.ch> |
Small fix for the last commit. Next thing is color conversion using a subset of what is in Bitmap.cpp. Maybe the conversion functions should be put into a conversion class that can be used by the app_server too. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16574 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
3e2ee695 |
|
02-Mar-2006 |
Michael Lotz <mmlr@mlotz.ch> |
Started implementing the server side of BScreen()->ReadBitmap(). Colorspace conversion is not done yet so that it only works correct in 32bit modes. Also drawCursor is not respected yet. Partially fixes bug 197. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16573 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
6697289d |
|
06-Feb-2006 |
Stephan Aßmus <superstippi@gmx.de> |
some changes supposed to speed up VESA mode on real hardware, based on my experience with optimizations in other parts git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16259 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
fd7d912f |
|
02-Jan-2006 |
Stephan Aßmus <superstippi@gmx.de> |
* 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
|
#
3155f89a |
|
01-Jan-2006 |
Stephan Aßmus <superstippi@gmx.de> |
blame SaveToPNG for not handling other colorspaces git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15777 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
cd2b129d |
|
29-Dec-2005 |
Stephan Aßmus <superstippi@gmx.de> |
* 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
|
#
208e6678 |
|
23-Dec-2005 |
Stephan Aßmus <superstippi@gmx.de> |
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
|
#
1f0a4ee8 |
|
20-Dec-2005 |
Stephan Aßmus <superstippi@gmx.de> |
removed unused stuff from Painter and DrawingEngine, fixed the deadlock when trying to use the (20 times faster) DrawingEngine version of StringWidth, the font is now usually ignored when taking on a DrawState in Painter... should add a little speed overall git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15628 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
3c2ffeb0 |
|
11-Dec-2005 |
Stephan Aßmus <superstippi@gmx.de> |
fixed one more drawing bug, it only showed because now the test environment uses hardware acceleration, FillRegion for the client irgnored the current clipping git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15483 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
7be34d3e |
|
10-Dec-2005 |
Stephan Aßmus <superstippi@gmx.de> |
* removed CopyRegionList, as it made no sense * finally nailed that much hated bug where the wrong background underneath the cursor was restored. I always looked for this in the wrong place - of course, you cannot blit regions on top of the cursor and expect the backup of the background to be magically valid still... ;-) git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15461 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
e83820ed |
|
07-Dec-2005 |
Axel Dörfler <axeld@pinc-software.de> |
Merged app_server_new_clipping branch changes r15290 to 15418 back into trunk. Also fixed Jamfile for the test environment. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15419 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
2b97fe88 |
|
09-Nov-2005 |
Stephan Aßmus <superstippi@gmx.de> |
now updates BView::PenLocation() correctly after DrawString(), stuff like DrawChar('a') is working nicely now, for rotated text much better then in BeOS in fact because of subpixel precision in pen location git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14794 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
0118ad76 |
|
06-Nov-2005 |
Stephan Aßmus <superstippi@gmx.de> |
* Painter uses the line_cap and join_mode settings of DrawState * Painter implements DrawShape for stroking and filling BShape data * Painter uses clipping to avoid problems with huge coordinates, the R5 app_server can be crashed by this. -> this should be added to more places as well like text rendering * DrawingEngine uses the Painter to draw BShape data git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14735 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
e7869c4c |
|
04-Nov-2005 |
Stephan Aßmus <superstippi@gmx.de> |
renamed DisplayDriverPainter to DrawingEngine, removed tons of duplicated code, and - guess what - found some bugs while doing so... but nothing critical. This patch removes the former DisplayDriver API from libappserver.so, which I think breaks Decorator plug-ins for now git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14707 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
6ed89418 |
|
04-Nov-2005 |
Stephan Aßmus <superstippi@gmx.de> |
renamed DisplayDriverPainter.* to DrawingEngine.* git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14695 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
d30a0a6eae050e3f528521887a867df38a2cd60d |
|
23-May-2014 |
Stephan Aßmus <superstippi@gmx.de> |
app_sever: Fix more mixups of transformed clipping bounds
|
#
81507fa4960e50d0f5cf76095c531bf06e61db4a |
|
23-May-2014 |
Stephan Aßmus <superstippi@gmx.de> |
app_server: Fix transformed DrawString()... ...when the transformation moves the text into the view bounds. The rect returned from Painter::BoundingBox() is already transformed, as should be expected.
|
#
1d6f73bcbd7d98a27a190797580c619ed7bcf05c |
|
19-May-2014 |
Adrien Destugues <pulkomandy@pulkomandy.tk> |
Follow-up fixes for FillRect+transforms * Factor out AlignRect to avoid code duplication * Give the right rectangle to the OverlayHider.
|
#
79eb23a82dfd137b0a8f2a70058463f6d7a3b476 |
|
19-May-2014 |
Adrien Destugues <pulkomandy@pulkomandy.tk> |
Fix handling of filled rectangles with transforms. The DrawingEngine didn't properly make a distinction between the rectangle being filled and the damaged region on screen. This led to unexpected results when using BAffineTransform.
|
#
eb431663264ef319e72b492801fb867b5d71910b |
|
11-Mar-2014 |
Adrien Destugues <pulkomandy@pulkomandy.tk> |
app_server & interface kit: support fill rules. * BView gets SetFillRule/FillRule methods. The fill rule is part of the view state. * The B_NONZERO rule is the default. This is what we implemented before. * The B_EVEN_ODD rule is the other common possibility for this, and we need to support it to help WebKit to render properly.
|
#
89f8b7a12d16a16388e45a4708c033cfb3993df7 |
|
08-Feb-2014 |
Stephan Aßmus <superstippi@gmx.de> |
app_server: Fix computing bounding boxes for transformed stuff. * In DrawingEngine, clipping is computed before drawing happens. This did not take into account when drawing primitives can now be transformed. Fixes drawing glitches in the Transformation test when the round rect is scrolled into view and it was previously prevented to draw. * Fixed clipping rect computation for the sanitized StrokeRoundRect() implementation which centers the stroke on the rect.
|
#
215119a1e73029a7165a1c01dfa3ceb4a90d44bf |
|
28-Jan-2014 |
Stephan Aßmus <superstippi@gmx.de> |
app_server: Move AlphaMask management into DrawState. * Give DrawState a real copy constructor, handle deriving in PushState(). (Although clipping region and alpha mask are not cloned, which is on the other hand just what's needed for now.) * Combining alpha masks from previous states is not yet handled. * Remove SetAlphaMask() from DrawingEngine and Painter. It is now done in SetDrawState().
|
#
f08d5477d8b854d8ae33801ad4aaf3c78008df11 |
|
28-Jan-2014 |
Adrien Destugues <pulkomandy@pulkomandy.tk> |
Add Alpha Masking support in ClipToPicture Use AGG to implement ClipToPicture in a faster and better way. There are things missing in this initial implementation: * No support for PushState/PopState saving and restoring the picture. * No support for nested clipping through PushState * The clipping doesn't happen where you expect it when using SetScale() * There are artifacts when scrolling and resizing clipped views * The implementation uses more memory than it needs, as the clipping bitmap is stored as RGBA32, yet only the alpha channel is used * The clipping bitmap is rendered more times than it needs to. We need some caching here.
|
#
f4c2f7ebdb11576420c00fc4ecb23b32c3ce3137 |
|
10-Jan-2014 |
Jonathan Schleifer <js@webkeks.org> |
Remove variable length arrays of non-PODs. Variable length arrays of non-PODs are not part of the C++ standard, but a GNU extension that never worked correctly. Instead, BStackOrHeap array is used now, which makes sure that it's not too big for the stack, calls all constructors and is valid C++.
|
#
e1be7d07d668af884caab7ff42e15cf95a609692 |
|
04-Aug-2012 |
Alex Smith <alex@alex-smith.me.uk> |
Fixed a 64-bit calculation error.
|
#
76ab3f88df26cbb595ca663798c7d84f9758c7c4 |
|
18-Mar-2010 |
Stephan Aßmus <superstippi@gmx.de> |
Basically, this changeset implements BShape::ArcTo(). In more detail: * Added BShape::ArcTo() and BShapeIterator::IterateArcTo(), using a previously unused virtual slot. (Added the symbols for binary compatibility for GCC2 and GCC4.) * Added operator=(), operator==() and operator!=() to BShape. * Added BShape::BezierTo() version taking three points, which is sometimes more convenient. * Added the four new shape data ops OP_LARGE_ARC_TO_CW, OP_LARGE_ARC_TO_CCW, OP_SMALL_ARC_TO_CW and OP_SMALL_ARC_TO_CCW. For a single arc, provided the radius is large enough, there are four possibilities to draw the arc, these are controlled by the two boolean flags to ArcTo() and mapped to the new commands accordingly. * Some style cleanup in Shape.cpp (sorry for mixing it up, but it gets worse below...) * Added ShapeTest to src/tests/servers/app. * Changed the way BShapes are transformed from view to screen space in the app_server. For arcs, it would be nontrivial to apply a proper transformation, it's much easier to let AGG take care of it. This affects ServerPicture as well. * Wrapped iterating the BShape into try/catch blocks in ShapeIterator. But I really don't understand the purpose of the class in the first place. Maybe it can now be dropped, since coordinates don't have to be transformed in place anymore. * Refactored copy&paste shape iteration code in Painter. The transformation to screen space happens there. * Since RemoteDrawingEngine needed to be adopted anyway, I also updated it for the new DrawString() with offsets version. But the client still needs to be adapted. * Style cleanup in Painter.h git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35905 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
77e5acc0d9d737051591e663ccf3376a32bfcf84 |
|
15-Mar-2010 |
Stephan Aßmus <superstippi@gmx.de> |
* Extended the BView drawing API by a DrawString() version that takes an array of locations, one for each glyph. * Added a test for the new functionality. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35865 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
a0b37b6e3852e63bd2746468411ca7827c900c25 |
|
11-Mar-2010 |
Stephan Aßmus <superstippi@gmx.de> |
Tried to fix all issues with running a DEBUG build of app_server. * CopyRegion should not need the HWInterface to be exclusive locked. * BitmapDrawingInterface does not need to be locked at all, since it doesn't use a shared HWInterface instance. * Window and Desktop should lock the HWInterface appropriately before invoking CopyRegion() on the DrawingEngine. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35822 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
8b56f14aeba18bc3cea7e8f12708c7b155b374fa |
|
12-Mar-2010 |
Stephan Aßmus <superstippi@gmx.de> |
Fixed debug build. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35820 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
aeb689782ce5ced9d23144d982f3655425661297 |
|
15-Feb-2010 |
Axel Dörfler <axeld@pinc-software.de> |
* Removed ServerCursorReference in favour of BReference. * Simplified the Desktop::SetCursor() code a bit. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35471 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
d99900143c15f067315429cf3834982ea5364201 |
|
07-Nov-2009 |
Axel Dörfler <axeld@pinc-software.de> |
* Fixed a few operator precedence bugs (&& ... & ... &&). * Cleanup. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33931 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
|
#
12349c7d3d445aa2bb4d737e5c7bcf135cca1d69 |
|
05-Apr-2009 |
Stephan Aßmus <superstippi@gmx.de> |
Begun to use structs for the BView<->app_server communication. This makes the protocoll less prone to errors, reduces possible points of failure and most importantly, reduces the number of function calls to the link API. I only know the numbers for StrokeLine(), which I tested via the Benchmark test app. With this change, drawing random colored and positioned lines actually doubled in speed. On the BView side, the calls to ServerLink::Attach() only halfed, while on the app_server side, the number of calls to ServerLink::Read() is now 1/4th. It will also be worth investigating why the link stuff is so slow at all. I also optimized BView::DrawString() a lot in this change, but I don't have any numbers yet. Some other commands which used multiple Attach()/Read() calls were also optimized, at least the most important ones. Begin/EndLineArray() was also pretty bad on the app_server side. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29937 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
339676b60859f8c12ac1a7e9d6b97012b82ad5c0 |
|
02-Apr-2009 |
Axel Dörfler <axeld@pinc-software.de> |
* This time, I actually got it right, thanks Alexandre... git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29866 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
56ab1944d5ec8cf4bc11bacf6fceb96368134262 |
|
02-Apr-2009 |
Axel Dörfler <axeld@pinc-software.de> |
* Fixed Stippi's favourite typo ("appearantly" does not exist). git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29861 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
64eb49fd247e510f572ead9f2fbec5b39acd3fe9 |
|
15-Feb-2009 |
Stephan Aßmus <superstippi@gmx.de> |
* Cleanup in the Gradient department. No fuctional change. Renamed BGradient::color_step to BGradient::ColorStop as it's called everywhere else. Also renamed BGradient::gradient_type to just BGradient::Type. Renamed BGradient::Type() to GetType(). * Simplification of method names in Painter.cpp. Some not yet complete and yet inactive code to accelerate vertical gradients (bypassing AGG for this special case). git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29214 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
fb3e35fcec1ef41b413b3b121764509f436dee4d |
|
22-Jan-2009 |
Michael Lotz <mmlr@mlotz.ch> |
Fixing all headers/namespaces/name lookup problems that hinder a GCC 4.3.2 build. I sure hope that this doesn't break the build for anyone else. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28992 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
ce5d64725d8f4ada1b45675102b02e56c890bc18 |
|
19-Jan-2009 |
Stephan Aßmus <superstippi@gmx.de> |
* Renamed the drawing functions in DrawingEngine to remove the *Gradient part. In general, there is a lot of code duplication now, also in Painter. I will need to find a way to elliminate this again. Also, all the stroking functions should be gradient enabled as well. * Improved the look of the DefaultDecorater, inspired by the patch from Dennis Washington. I did not adopt the changes which give backwards compatibility problems, though, like changing the window border width or the single border decorator color. But I reckon these changes are overall even a bit smoother. * Fixed a long standing decorator bug, where the resize area of the border was visually different than the click recognition. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28951 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
0a31071e2fe1833f7f89e72e7d0d91e584f69302 |
|
28-Nov-2008 |
Axel Dörfler <axeld@pinc-software.de> |
stippi+axeld: * DrawString() took the fast clipping path for rotated fonts which didn't work out (visible when moving a window over the rotated texts in DriveSetup). * Also, made it work correctly when using sheared fonts. * Fixed typo. * Automatic whitespace cleanup. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28741 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
8b8e062daa438a8fed22113db7fec7524a355429 |
|
23-Oct-2008 |
Stephan Aßmus <superstippi@gmx.de> |
* DrawingEngine::CopyBits() was invalidating the wrong region (without offset) when the HWInterface was using acceleration and at the same time double buffering. * _CopyToFront() should always be used, since it calls a protected virtual that derived classes of HWInterface depend on. This fixes some graphics glitches in certain situations. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28300 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
991547ef6c1fca650f0fba855206296ef54bc441 |
|
14-Oct-2008 |
Stephan Aßmus <superstippi@gmx.de> |
Patch by Artur Wyszynski: * Implemented BGradient, BGradientLinear, BGradientRadial, BGradientDiamond, BGradientConic and BGradientRadialFocus new Interface Kit classes. * Implemented all the (AGG-based) backend necessary in the app_server to render gradients (Painter, DrawingEngine) * app_server/View can convert a BGradient layout to screen coordinates. * Added BGradient methods of the Fill* methods in BView. * Implemented a test app and added it to the image as a demo. * Adopted Icon-O-Matic and libs/icon in order to avoid clashing with the new BGradient class. Re-use some parts where possible. Awesome work, Artur! Thanks a lot. Now a more modern looking GUI has just become much easier to implement! :-) TODO: * Remove the need to have gradient type twice in the app_server protocol. * Refactor some parts of the patch to remove duplicated code (Painter, DrawingEngine). * Adopt the BPicture protocol to know about BGradients. * Review some parts of the BArchivable implementation. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28109 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
3580c2cf122291d8152ff4a08381d3fbc24112ea |
|
30-Sep-2008 |
Karsten Heimrich <host.haiku@gmx.de> |
* remove png dump from app_server git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27802 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
162a7f5f8e924eda0b7d7b99167882591926ad6d |
|
28-Jul-2008 |
Stephan Aßmus <superstippi@gmx.de> |
* Implemented new BView drawing functions DrawBitmap[Async]( const BBitmap* bitmap, BRect bitmapRect, BRect viewRect, uint32 options). Only option so far is B_FILTER_BITMAP_BILINEAR. * BView::DrawBitmap[Async](const BBitmap* bitmap, BRect viewRect) was accessing the bitmap pointer without checking it. Would therefore crash when passing NULL, unlike the other methods. * The BPicture code already reserved room for the BBitmap flags, but did not store the actual flags and neiter use them for anything. Since the bitmap data is stored anyways, the bitmap creation flags do not matter. So I reused this for the new bitmap drawing options. * Rewrote Bitmap.h and removed the B_BITMAP_SCALE_BILINEAR flag again. * Tried to optimize Painter::_DrawBitmapBilinearCopy32() a little by giving the compiler better hints. There seems to be a marginal, possibly imagined speed increase < 0.05 ms. ;-) git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26665 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
576305a5d8443de26fc55f69d06bb535bda2e450 |
|
20-Jul-2008 |
Stephan Aßmus <superstippi@gmx.de> |
* Adopt the code to handle the case that even a HWInterface instance with hardware accelerated functions could be double buffered. * Align the rectangle used for arc drawing like those for ellipsis. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26544 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
93016537ebd01a047fb2531f33c1bd1d54da4ecf |
|
08-Jul-2008 |
Stephan Aßmus <superstippi@gmx.de> |
Check if the Painter even has a clipping region set before trying to take the short cut when no text needs to be rendered. I've seen a crash yesterday in the app_server test environment when the decorater was drawing something, although it may also have been because I had a screwed up objects folder where some objects were not recompiled because I am switching back and forth between two app_server code folders. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26323 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
018b0c251c2c0c9b08170ad2363fc4419f6f41eb |
|
11-Jun-2008 |
Michael Lotz <mmlr@mlotz.ch> |
* The StrokeLine() variation that takes a rgb_color did change the drawing state of the painter without restoring it afterwards (HighColor and DrawingMode). This function is only used in decorators, but as such it could lead to strange effects. When clicking and holding the close button on the R5 MidiPlayer for example, the background of the scope would suddenly become the color of the close buttons middle line. As the drawing mode was also overwritten this could probably have lead to text rendering issues when zooming applications. As I didn't find a easy way to reproduce such a thing, this is only theory though. * Implement the missing IsExclusiveAccessLocked() method in the DrawingEngine which is not used at the moment. If corresponding debug output is generated though, it reveals possible locking issues with CopyRegion(). * Remove an empty line in the LineArrayData struct. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25934 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
|
#
f306ef434f1676b273fc9c04b6554204bb7f1a79 |
|
17-Mar-2008 |
Stephan Aßmus <superstippi@gmx.de> |
* Fix build of app_server test environment by implementing atomic_get(), maybe this should be the assembler version we use for x86, but is probably fine for the purpose of the test environment (only BString uses this) * Fix semantics of DrawingEngine::CopyToFront() which I recently introduced, for the fake accelerant of the test environment, we do need to call Invalidate(), not CopyBackToFront() directly. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24422 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
18212e76cc0650b08fafd5490bc2dc08ef8b207b |
|
10-Mar-2008 |
Stephan Aßmus <superstippi@gmx.de> |
* Made it possible to supress automatic back to front buffer copying of the rectangle area that is touched by a drawing command. * Added a CopyToFront(BRegion) method which copies a complete region from the drawing/back buffer to the front buffer. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24353 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
8a1c136e4766b52aeeabbaebb59544f4275db1cd |
|
10-Mar-2008 |
Stephan Aßmus <superstippi@gmx.de> |
Use the front buffer for screenshots always, otherwise we don't get the contents of BDirectWindows for setups where the app_server uses double buffering mode. I didn't test the change, but the way the cursor is optionally copied into the bitmap (which might now be not 32 bpp) looks very flexible. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24346 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
4d1dd3bcfee7cc496a1e8881fe911d5706b44d6c |
|
24-Feb-2008 |
Stephan Aßmus <superstippi@gmx.de> |
Use the AutoFloatingOverlaysHider in the remaining cases where overlays were hidden regardless of the affected area. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24098 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
|
#
ff85245718d1c80e06227511d37d33c913a8f538 |
|
25-Oct-2007 |
Stephan Aßmus <superstippi@gmx.de> |
* fixed the crashing result of bug #634, check if the supplied region falls within the frame buffer bounds. This should not happen, and I am going to search for the cause next, but at least app_server dosn't crash anymore in this context. Left a comment on my findings so far. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22721 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
158001f57d14aad0a3cd9be0e072bdeb3265b387 |
|
12-Sep-2007 |
Stephan Aßmus <superstippi@gmx.de> |
* fractional rects need to be aligned if not drawing in subpixel precise mode, by now, I feel there is too much code involved in this... I guess I should really move this to stuff to ViewLayer::ConvertToScreenForDrawing()... git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22223 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
561844529dfec4e1a5d9454ea5abe1d578801864 |
|
26-Aug-2007 |
Stephan Aßmus <superstippi@gmx.de> |
* implement FillRect() with B_OP_INVERT using hardware acceleration like FillRegion() is already doing (untested) git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22059 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
f7e1df75609966bdfdb4ed39edf26dd145d8221f |
|
16-Aug-2007 |
Stephan Aßmus <superstippi@gmx.de> |
* get rid of RGBColor usage where it is not needed, this simplified many things, possibly making them a little faster too * mess with decorator button size calculation to make the whole layout scale more agreeable with the font size (no more fixed offsets/insets), but it is work in progress * DefaultDecorator no longer allocated the border color array, it is part of the object now * small memory footprint optimizations in ViewLayer, Decorator and WindowLayer git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22003 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
a2d647536009ae390f797c865234f26ea34370c8 |
|
13-Aug-2007 |
Stephan Aßmus <superstippi@gmx.de> |
* fixed usage of hardware accelerated inverting, of course we shouldn't do it again in software after we have done it in hardware... git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21921 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
fe914c98b4a80f633b63d01be0fbb2acb40f9958 |
|
09-Aug-2007 |
Stephan Aßmus <superstippi@gmx.de> |
* added a version of SetFont() that takes a DrawState* to DrawingEngine and Painter, that is needed to be able to tell if anti-aliasing is to be used, since the flags in the font can be overruled by the flags in the view... * fixes aliased fonts reliably, tested with FontDemo git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21869 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
a748b927a52b532a44e579901ce9890f953ef49c |
|
08-Aug-2007 |
Stephan Aßmus <superstippi@gmx.de> |
* make sure that the pattern used for line arrays is B_SOLID_HIGH and that the previous pattern is restored after execution git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21853 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
4971740e39a5962f1106572e25b76a27d2445071 |
|
06-Aug-2007 |
Stephan Aßmus <superstippi@gmx.de> |
* in FillRegion(), check if the current drawing mode is B_OP_INVERT, and then use hardware acceleration... found out this is what our BTextView is actually using, that's why it never used hardware acceleration for invert rect/region before. Have not tested this on real hardware yet. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21843 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
c9d2046fe5b12fee15b6c24960d29fd581a81cef |
|
04-Aug-2007 |
Stephan Aßmus <superstippi@gmx.de> |
* after my last changes to font rendering, it was about 15% slower than before (although there should be much less lock contention) * with this change, there is quite a bit of cleanup, text drawing is now about 20% faster than before the original changes to font caching, mostly due to turning off the kerning feature, which at the moment gives absolutely no benefit. The correct way of doing it might be to use kerning depending on the provided glyph spacing mode * removed fPenLocation from Painter, the usage should be more correct now, since it is now consistently applied before the coordinate transformation from view to screen (also for DrawShape() now, before any view scaling and origin offset) * Painter no longer has it's own instance of a ServerFont, instead it uses its AGGTextRenderer instance, which was per Painter again after the last change, and not global anymore, made _UpdateFont() useless * When using GlyphLayoutEngine, it supports a second pass with the same FontCacheEntry through the introduction of a FontCacheReference. This speeds up DrawString a little, since it needs to calculate the bounding box for the string, and then draw the string in a second pass. This is now done with only one FontCacheEntry lookup * I also tried to optimize the on-the-fly conversion of UTF8->CharCode away, since it was done four times per DrawString, but surprisingly, it proofed to be a slight slowdown. * introduced a shortcut in DrawingEngine::DrawString() which avoids calculating the bounding box, we are now a tiny bit faster to figure out that we don't need to draw any string than Dano In the test environment (drawing to offscreen bitmap and blitting to screen eventually), text rendering is now about 3.7 times _faster_ than Dano text rendering (directly to screen), for untransformed text. Unfortunately I cannot test on the same machine in accelerant using version of the test environment. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21822 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
2222864eed6bc28cff3d837c98d1509dcbcf38bc |
|
02-Aug-2007 |
Stephan Aßmus <superstippi@gmx.de> |
* complete overhaul of the font/glyph caching * the previous AGG implementation is superfluous * the new implementation is based on that one, but in a way that allows read/write locking to the list of cache entries (fonts) as well as read/write locking to the cached glyphs per individual font cache entry * new GlyphLayoutEngine.h, which is to be the central place for layouting glyphs along the baseline. It handles the locking for getting the font cache entries. It works by giving it a template class GlyphConsumer which does the actual work. * changed AGGTextRenderer to use the new font cache * changed ServerFont::StringWidth(), and the bounding box stuff to use it * changed DrawingEngine, it doesn't need the global font lock anymore * our BFont thought that GetBoundingBoxesAsGlyphs and GetBoundingBoxesAsString is the same, which of course it isn't, hence the two separate functions... AsGlyphs just gets the bounding box of each glyph in a string, not treating the string as an actual word AsString adds the offset of the glyph in the word to the bounding box * changed ServerProtocol.h accordingly for the different bounding box meaning git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21797 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
38287e02afe4c0b08ae1c2c3279bb8d3a2e07fc2 |
|
22-Jul-2007 |
Stephan Aßmus <superstippi@gmx.de> |
* completed my changes to DrawState handling, the current DrawingState of the active ViewLayer is now always mirrored in the Painter instance of a ServerWindow, so that it doesn't need to be synced on every drawing command, this was previously incomplete for font handling * removed the DrawState parameter from all the DrawingEngine functions * adjusted ServerWindow and ServerPicture accordingly * made sure that string related functions used by non-drawing related parts (ServerApp, Decorator) don't interfere with the current drawing state * moved AS_SYNC handling from _DispatchViewMessage to _DispatchMessage, it is actually a window message and doesn't require fCurrentLayer to be valid * fixed bug #1300, fCurrentLayer was not updated when a ViewLayer was deleted by client request which happened to be fCurrentLayer (I am now handling it so that the parent becomes the current layer, could be wrong) * AGGTextRenderer is no longer using it's own scanline, which should save a few bytes RAM, the Painter already had such an object * StringWidth() in AGGTextRenderer is now taking the escapement_delta into account * Painter::StrokeLine() doesn't need to check the clipping as much, since that is already done in DrawingEngine * if a ServerWindow message is not handled because fCurrentLayer is NULL, a reply is sent in case the messages needs it (client window could freeze otherwise, waiting for the reply for ever) * removed unused AS_SET_FONT and AS_SET_FONT_SIZE * added automatic RGBColor -> rgb_color conversion to RGBColor.h * minor cleanup for 80 char/line limit git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21685 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
0896fce5fb6672058acb2a99990d3a4cd082105c |
|
18-Jul-2007 |
Stephan Aßmus <superstippi@gmx.de> |
* since every window has it's own Painter instance, the drawing state does not need to be "set" (transfered from the "current" view to the painter) for each singly drawing command. Now, painter is synchronized whenever the client changes the drawing state of the current view, or when the current view changes. * the screen offset of the current view has become part of the Painter state, in the PatternHandler. This fixes a bug in which moving or scrolling a view which used patterns for drawing, resulted in visual glitches (seams in the pattern). NOTE: this patch is a bit work in progress, most importantly, it is not complete with regards to text rendering. More specifically, the server applications and other parts of the appserver might set a font on the Painter and this might mess up the synchronization. But this happens on the Desktop's Painter instance (only?), and so it is not a problem. I did observe some drawing bugs with this patch though, so bug reports are welcome, particularily how to reproduce these bugs reliably. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21643 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
527b4ad1b36d434c64eda13a8f1d7aa4d46cddc9 |
|
15-Dec-2006 |
Stephan Aßmus <superstippi@gmx.de> |
Gracious me, I forgot to actually turn on parallel frame buffer access! Seems to make some difference too. Nothing dramatic though. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19527 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
|
#
846cc588f2ea43ed5afa4651bde8e61ea6969e10 |
|
14-Sep-2006 |
Stephan Aßmus <superstippi@gmx.de> |
* a fix for the bug where clicking a window decor button drew over the mouse cursor. The problem is actually something else: non-straight lines extend a little past the calculated rectangle git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18842 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
4423855cbd5411b64deba32e8b58af8b9c708ab6 |
|
13-Sep-2006 |
Stephan Aßmus <superstippi@gmx.de> |
This is the kind of bug you can search for hours. At first, I suspected a concurency problem in the DrawingEngine, so there is some debugging stuff added, as well as some unnecessary locking removed there. The problem was in Painter though, in that certain functions adjusted clipping at the "rasterizer level", while some other functions didn't care about that. Now the clipping is consistently set at the rasterizer level (rough estimate to avoid scanline generation outside real clipping region bounds). There are a number of bugs fixed by this, I'm going to find out later, what their ticket numbers are... Mouse preflet draws the mouse now, Backgrounds preflet draws the screen reliably... probably more, anything to do with bitmaps, round rects and possibly ellipses. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18828 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
9ecf9d1c1d4888d341a6eac72112c72d1ae3a4cb |
|
26-Aug-2006 |
Ingo Weinhold <ingo_weinhold@gmx.de> |
Merge from layout management branch. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18649 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
|
#
65abd9dff07b711bdc9779d0f2e1e81624475cca |
|
05-May-2006 |
Stephan Aßmus <superstippi@gmx.de> |
* Painter switches back correctly from using B_OP_COPY for text to using the "normal" B_OP_COPY for lines and such that works more like B_OP_OVER actually (for example, the slider in VLC will look much better, but also other stuff) * combined Stroke and FillEllipse() into DrawEllipse() and fixed some longstanding issues, ellipses are now correctly placed (aligned) and of the correct size * removed locking in the DrawingEngine drawing functions, since you need to have the DrawingEngine locked anyways for the clipping to stay what it is (and that's already the case elsewhere in the code) * simplified ConstrainClippingRegion, the NULL version was never useful and also locking is removed, see above summary: slight speed improvements, cleanup and bugfixes... git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17329 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
022cdecc8fe078d09483c8706ef2bd38f74a41ee |
|
03-May-2006 |
Stephan Aßmus <superstippi@gmx.de> |
simplified polygon and bezier drawing methods, made them more efficient git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17311 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
3ca1310ac770b4fe5530e87328ad813b6e2755bf |
|
23-Apr-2006 |
Stephan Aßmus <superstippi@gmx.de> |
* cleaned up and optimized a lot setting the font in Painter and AGGTextRenderer (when switching the DrawState for font stuff) * removed unused stuff from the font signature generation that is used to synchronize the font cache * finally nailed that bug that made glyphs of the wrong size appear within lines of text (the problem basically was that outside code messed with the freetype library instance while our glyph cache thought the library was last setup by itself) git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17217 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
|
#
6dcf803e4857bb503adb56dc119cc4b0be987df4 |
|
06-Apr-2006 |
Marcus Overhagen <marcusoverhagen@gmail.com> |
removed some off-by-one errors. replaced cursor->Bounds().IntegerWidth() with cursor->Width() which is equal to cursor->Bounds().IntegerWidth() + 1 git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17032 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
5d0c78f416dbe14544d0d673275c98dd276e4b1d |
|
01-Apr-2006 |
Stephan Aßmus <superstippi@gmx.de> |
skip hardware acceleration for small regions, should speed up rendering of small regions in the same way it helped small rects git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16955 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
8e56a3ff2e2af0e08894a50fc493292b12c6d3fe |
|
19-Mar-2006 |
Stephan Aßmus <superstippi@gmx.de> |
* some cleanup (removed unsued functions, regrouped others) * FillRect() doesn't use the HW acceleration if the rects are too small (< 100 pixel area, about the sweet spot on my box) -> the same change should be used for FillRegion as well. (4x speed up of rendering large amounts of small rects) * replaced dynamic allocation and freeing of blit_params and fill_rect_params in the accalerant based HWInterfaces on the heap with caching to make using the accelerated functions a little less expensive * fixed a bug in bypassing Painter for B_OP_OVER when the pattern was B_SOLID_LOW (nothing should be rendered) git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16841 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
0581480cfec831197846c0449f838768412e2e03 |
|
13-Mar-2006 |
Michael Lotz <mmlr@mlotz.ch> |
* Fixed ServerBitmap::ImportBits() to use the correct width/height * Extended ConvertBits() to properly handle negative offsets and overlapping lines * Implemented blitting the software cursor to the bitmap returned from ReadBitmap() Note: In the future we will have to directly use the final graphics buffer for ReadBitmap() if we want DirectWindow output too (R5 includes it). I don't know how R5 handles the hardware cursor though. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16766 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
30ce5790f24c2cb24e2723748c994b8a0ed512d5 |
|
11-Mar-2006 |
Stephan Aßmus <superstippi@gmx.de> |
added two TODOs git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16719 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
2a6e97186b553cbf8eac168d283da03a7930ee24 |
|
05-Mar-2006 |
Michael Lotz <mmlr@mlotz.ch> |
Actually commit the change to ReadBitmap()... git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16594 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
a97ee677a7e7721c927105c0676523e86dba58f3 |
|
05-Mar-2006 |
Michael Lotz <mmlr@mlotz.ch> |
Ensure that the cursor is not drawn (it was visible in single buffered mode). Drawing the cursor is not implemented yet. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16582 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
acfad7920cd256d36fc7848c8b1da5d83cc3363c |
|
04-Mar-2006 |
Michael Lotz <mmlr@mlotz.ch> |
Added an ImportBits() function to ServerBitmap and used it in ReadBitmap(). Should work for all colorspaces now. Magnify does now work correctly, fixed bug 197. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16581 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
f1fb383d6f235551543bc85e6bbbf3c38dc0a7a4 |
|
02-Mar-2006 |
Michael Lotz <mmlr@mlotz.ch> |
Small fix for the last commit. Next thing is color conversion using a subset of what is in Bitmap.cpp. Maybe the conversion functions should be put into a conversion class that can be used by the app_server too. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16574 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
3e2ee69551a2ab301f93a129863788dc0d9a9b20 |
|
02-Mar-2006 |
Michael Lotz <mmlr@mlotz.ch> |
Started implementing the server side of BScreen()->ReadBitmap(). Colorspace conversion is not done yet so that it only works correct in 32bit modes. Also drawCursor is not respected yet. Partially fixes bug 197. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16573 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
6697289d80413ef21eb4acb353a21f87bbfc06b1 |
|
06-Feb-2006 |
Stephan Aßmus <superstippi@gmx.de> |
some changes supposed to speed up VESA mode on real hardware, based on my experience with optimizations in other parts git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16259 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
fd7d912ff65f0740a1274f512f3cd20190740ca6 |
|
02-Jan-2006 |
Stephan Aßmus <superstippi@gmx.de> |
* 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
|
#
3155f89a0cd1d969ed73f663d84a75815de2d63f |
|
01-Jan-2006 |
Stephan Aßmus <superstippi@gmx.de> |
blame SaveToPNG for not handling other colorspaces git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15777 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
cd2b129d0777a3198229fa66f0f4c344f7027120 |
|
29-Dec-2005 |
Stephan Aßmus <superstippi@gmx.de> |
* 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
|
#
208e6678e324f2ac0d51743d448e95f72b97fc50 |
|
23-Dec-2005 |
Stephan Aßmus <superstippi@gmx.de> |
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
|
#
1f0a4ee8c766f5176c2707539d6732298efab385 |
|
20-Dec-2005 |
Stephan Aßmus <superstippi@gmx.de> |
removed unused stuff from Painter and DrawingEngine, fixed the deadlock when trying to use the (20 times faster) DrawingEngine version of StringWidth, the font is now usually ignored when taking on a DrawState in Painter... should add a little speed overall git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15628 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
3c2ffeb0d649803884fdce5d72b091614399d439 |
|
11-Dec-2005 |
Stephan Aßmus <superstippi@gmx.de> |
fixed one more drawing bug, it only showed because now the test environment uses hardware acceleration, FillRegion for the client irgnored the current clipping git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15483 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
7be34d3eb22bb3cf81643988092ca506d9988c8a |
|
10-Dec-2005 |
Stephan Aßmus <superstippi@gmx.de> |
* removed CopyRegionList, as it made no sense * finally nailed that much hated bug where the wrong background underneath the cursor was restored. I always looked for this in the wrong place - of course, you cannot blit regions on top of the cursor and expect the backup of the background to be magically valid still... ;-) git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15461 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
e83820ed5720395d39a1ff809991b4fd76326548 |
|
07-Dec-2005 |
Axel Dörfler <axeld@pinc-software.de> |
Merged app_server_new_clipping branch changes r15290 to 15418 back into trunk. Also fixed Jamfile for the test environment. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15419 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
2b97fe884d2d06e4f85e344d5d82de55f7ac5340 |
|
09-Nov-2005 |
Stephan Aßmus <superstippi@gmx.de> |
now updates BView::PenLocation() correctly after DrawString(), stuff like DrawChar('a') is working nicely now, for rotated text much better then in BeOS in fact because of subpixel precision in pen location git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14794 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
0118ad76e16ce6ffa705ff3db93f48ed0c3cf260 |
|
06-Nov-2005 |
Stephan Aßmus <superstippi@gmx.de> |
* Painter uses the line_cap and join_mode settings of DrawState * Painter implements DrawShape for stroking and filling BShape data * Painter uses clipping to avoid problems with huge coordinates, the R5 app_server can be crashed by this. -> this should be added to more places as well like text rendering * DrawingEngine uses the Painter to draw BShape data git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14735 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
e7869c4c74d0fdaa08475b85c81044b5864f5dc7 |
|
04-Nov-2005 |
Stephan Aßmus <superstippi@gmx.de> |
renamed DisplayDriverPainter to DrawingEngine, removed tons of duplicated code, and - guess what - found some bugs while doing so... but nothing critical. This patch removes the former DisplayDriver API from libappserver.so, which I think breaks Decorator plug-ins for now git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14707 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
6ed894182f5f5865f2f8a2b1c4dea7bf81324063 |
|
04-Nov-2005 |
Stephan Aßmus <superstippi@gmx.de> |
renamed DisplayDriverPainter.* to DrawingEngine.* git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14695 a95241bf-73f2-0310-859d-f6bbb57e9c96
|