#
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>
|
#
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>
|
#
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.
|
#
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.
|
#
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.
|
#
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
|
#
db7e5d19 |
|
07-Oct-2009 |
Axel Dörfler <axeld@pinc-software.de> |
* This fixes the coding style violations Michael recently introduced. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33482 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
|
#
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
|
#
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
|
#
611c6ed9 |
|
30-Sep-2008 |
Karsten Heimrich <host.haiku@gmx.de> |
* forgot this file... git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27803 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
|
#
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
|
#
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
|
#
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
|
#
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
|
#
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
|
#
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
|
#
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
|
#
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
|
#
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.
|
#
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.
|
#
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
|
#
db7e5d1960b80fd26e8a94f54d4ea84243062157 |
|
07-Oct-2009 |
Axel Dörfler <axeld@pinc-software.de> |
* This fixes the coding style violations Michael recently introduced. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33482 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
|
#
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
|
#
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
|
#
611c6ed97714d528fb3bbedac3e16b5c265399ca |
|
30-Sep-2008 |
Karsten Heimrich <host.haiku@gmx.de> |
* forgot this file... git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27803 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
|
#
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
|
#
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
|
#
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
|
#
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
|
#
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
|
#
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
|
#
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
|
#
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
|