#
b5ba4bad |
|
12-Feb-2023 |
X512 <danger_mail@list.ru> |
app_server: clear background immediately on expose Reduce stamping artifacts when application slowly responds to redraw requests. This fixes and reintroduces logic previously removed in hrev53711. Previous logic was incorrect as it didn't take the possibility of multiple invalidations of different kinds (expose, update request) into account. Now separate update and expose regions are maintained and only expose region is cleared immediately. Change-Id: I0fd98cb1b45ccec285154e8c0d8e3a1400d156d7 Reviewed-on: https://review.haiku-os.org/c/haiku/+/6067 Reviewed-by: Jérôme Duval <jerome.duval@gmail.com> Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
|
#
779ab335 |
|
09-Dec-2020 |
X512 <danger_mail@list.ru> |
use .IsSet() instead if .Get() != NULL Change-Id: Ia2b7a719fd398e78cc3b11d4f7b02cb81179f65f Reviewed-on: https://review.haiku-os.org/c/haiku/+/3488 Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>
|
#
60d30785 |
|
27-Aug-2020 |
X512 <danger_mail@list.ru> |
app_server memory management fixes: use BReference Use BReference for more automated reference counting in app_server, fixing some use-after-free and other problems. Extracted from https://review.haiku-os.org/c/haiku/+/2695 Change-Id: I141bb248229405896b29feff3338447f7257b0b4 Reviewed-on: https://review.haiku-os.org/c/haiku/+/3175 Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
|
#
47102c07 |
|
24-Feb-2020 |
X512 <danger_mail@list.ru> |
Interface Kit: introduce B_TRANSPARENT_BACKGROUND flag BeOS didn't support transparent views. As documented in the Be Book, SetViewColor(B_TRANSPARENT_COLOR) only effect is to not fill the invalidated areas with the view color before calling Draw() (it avoids flickering, especially when combined with B_FULL_UPDATE_ON_RESIZE). A previous change made B_TRANSPARENT_COLOR actually make the view transparent (that is, additionally to the above, the underlying view is drawn before the transparent children), but it creates compatibility issues. In order to keep the API compatible with BeOS, the new behavior is now enabled explicitly using the B_TRANSPARENT_VIEW flag. This also opens for future developments like allowing a view color with an alpha channel (not supported yet). Adjust programs that require transparent views. Fixes #15744, #15745. Helps with #15645. Change-Id: I529574ea23db0a23579521b263bc8d572775e35a Reviewed-on: https://review.haiku-os.org/c/haiku/+/2275 Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
|
#
0d312fea |
|
29-Feb-2020 |
Augustin Cavalier <waddlesplash@gmail.com> |
app_server: Reduce usage of the RegionPool where unnecessary. BRegions with only 1 rectangle will use inline data and perform no allocations, so when we create a BRegion and only add one rect to it, we can just use one inline and avoid using the pool entirely at no cost (and some savings.) No functional change (intended). Change-Id: I10ac6bc7b5cf6b681641e88558a3f1ba770b6f77 Reviewed-on: https://review.haiku-os.org/c/haiku/+/2298 Reviewed-by: waddlesplash <waddlesplash@gmail.com>
|
#
6ab29b93 |
|
09-Jan-2020 |
X512 <danger_mail@list.ru> |
app_server: fix drawing of transparent views This change makes to draw parent view before current view if current view ViewColor is transparent. Views with transparent parts such as BDragger are now drawing properly without workarounds. Change-Id: I0450d1f012555137c8e7dd2d08c0c27df39465ff Reviewed-on: https://review.haiku-os.org/c/haiku/+/2091 Reviewed-by: Stephan Aßmus <superstippi@gmx.de>
|
#
7f9368ca |
|
09-Dec-2015 |
looncraz <looncraz@looncraz.net> |
Set*UIColor, etc. The inseparable changes necessary to support live color updating across the system in a sane, safe, and performant manner. BView gains: HasSystemColors() HasDefaultColors() AdoptSystemColors() AdoptParentColors() AdoptViewColor(BView*) SetViewUIColor(color_which, float tint) SetHighUIColor(... SetLowUIColor(... ViewUIColor(float* tint) HighUIColor(... LowUIColor(... DelayedInvalidate() BWindow gains a simple helper method: IsOffscreenWindow() BMessage gains: AddColor() FindColor() GetColor() HasColor() * allegedly this API is deprecated, but I implemented it anyway ReplaceColor() SetColor() Previous private ColorTools methods are made public and moved into GraphicsDefs: mix_color, blend_color, disable_color These are fully compatible with BeOS dan0 R5.1 methods and are just code cleanup of BeOS example code under the OpenTracker license. In addition, four new colors are created: B_LINK_TEXT_COLOR B_LINK_HOVER_COLOR B_LINK_ACTIVE_COLOR B_LINK_VISITED_COLOR These changes are documented in their proper user documentation files. In addition, due to a history rewrite, B_FOLLOW_LEFT_TOP has been defined and used in lieu of B_FOLLOW_TOP | B_FOLLOW_LEFT and is included in this commit. On the app_server side, the following has changed: Add DelayedMessage - a system by which messages can be sent at a scheduled time, and can also be merged according to set rules. A single thread is used to service the message queue and multiple recipients can be set for each message. Desktop gains the ability to add message ports to a DelayedMessage so that said messages can target either all applications or all windows, as needed. Desktop maintains a BMessage which is used to queue up all pending color changes and the delayed messaging system is used to enact these changes after a short period of time has passed. This prevents abuse and allows the system to merge repeated set_ui_color events into one event for client applications, improving performance drastically. In addition, B_COLORS_UPDATED is sent to the BApplication, which forwards the message to each BWindow. This is done to improve performance over having the app_server independently informing each window. Decorator changes are live now, which required some reworking. Signed-off-by: Augustin Cavalier <waddlesplash@gmail.com>
|
#
1cde68c5 |
|
09-Nov-2015 |
Julian Harnath <julian.harnath@rwth-aachen.de> |
app_server: apply transform to CopyBits * Apply affine transforms to source and target rects of BView::CopyBits(). For now, only if transform is a dilation.
|
#
551438b9 |
|
25-Jul-2015 |
Julian Harnath <julian.harnath@rwth-aachen.de> |
app_server: add new BView layers API * Add new methods BView::BeginLayer(uint8 opacity) BView::EndLayer() * All drawing between begin and end of a layer is redirected onto an intermediate bitmap. When ending the layer, this bitmap is composited onto the view with the opacity given when the layer was started. * Layers can be nested arbitrarily and will be blended onto each other in order. There can also be any arbitrary interleaving of layer begin/end and drawing operations. * Internally, drawing commands are redirected into a BPicture between BeginLayer and EndLayer (but client code need not know or care about this). Client code can also start/end other BPictures while inside a layer. * Uses the PictureBoundingBoxPlayer to determine the size of the layer bitmap before allocating and drawing into it, so it does not allocate more memory than necessary and -- more importantly -- it will not alpha-composite more pixels than necessary. * Drawing mode is always set to B_OP_ALPHA, blend mode to (B_PIXEL_ALPHA, B_ALPHA_COMPOSITE) while inside layers. This is necessary for (a) correct compositing output and (b) for redirection of drawing into the intermediate bitmap, which uses the renderer_region offset (in B_OP_COPY, the Painter does not use the AGG renderer methods, it directly accesses the pixel data. This would access out-of-bounds without the offset, so B_OP_COPY cannot be allowed.) To ensure these modes aren't changed, BView::SetDrawingMode() and BView::SetBlendingMode() are ignored while inside a layer. * The main motivation behind this new API is WebKit, which internally expects such a layers functionality to be present. A performant and reusable implementation of this functionality can only be done server-side in app_server.
|
#
6f2a446e |
|
06-Apr-2015 |
Julian Harnath <julian.harnath@rwth-aachen.de> |
app_server: extract coordinate conversion class * Move coordinate conversion into a new class SimpleTransform. It supports scaling and translation which is sufficient for conversion between screen, local and pen (drawing) coordinates. * Because all the overloaded methods for converting BPoint/BRect/BRegion/etc are now within the single SimpleTransform class, the interfaces of Canvas, View, DrawState, etc. are slimmed down. These classes have too many responsibilities, so some will be factored out into separate classes, this being the first.
|
#
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().
|
#
a01eaea7 |
|
28-Jan-2014 |
Stephan Aßmus <superstippi@gmx.de> |
app_server: Some cleanup of the new clipping code. * Fixed some coding style issues and use regular pointers like everywhere else in app_server code. * Moved _RenderPicture() from View to AlphaMask.
|
#
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.
|
#
77bf4d8d |
|
21-Jan-2014 |
Adrien Destugues <pulkomandy@pulkomandy.tk> |
Style fixes.
|
#
e1a30115 |
|
21-Jan-2014 |
Adrien Destugues <pulkomandy@pulkomandy.tk> |
Introduce DrawingContext View superclass In order to properly implement ClipToPicture in BView, we need to render a Picture to a Bitmap. This is currently done client-side, but the overhead for this (creating a BBitmap that accepts views, including a window thread, adding a view to it, and rendering the picture to the view, then sending the result to app_server) isn't acceptable. Moreover, the bitmap drawn this way is clipped to the view size, and the clipping won't work when the view is scaled or translated. So, we need to move the Bitmap creation server-side. However, app_server currently have no means of doing this. Factor out the relevant parts of View: a DrawingState stack with PushState/PopState, a DrawingEngine, and a ConvertToScreen transformation. Another implementation of the DrawingContext will allow us to also draw a picture directly using a Painter and low-level pixel buffer, in a format suitable for use as an AGG alpha mask.
|
#
3fed1a15 |
|
05-Aug-2012 |
Alex Smith <alex@alex-smith.me.uk> |
Get app_server working on x86_64. With this commit, app_server now compiles and runs at boot! Nothing particularly interesting happens, just the blue background and a mouse pointer. Remote backends are broken and not compiled in, see #8834. Note that it won't be possible to build this quite yet, need to get the FreeType package uploaded.
|
#
95e95fee |
|
23-Dec-2010 |
Michael Lotz <mmlr@mlotz.ch> |
* CID 10247: Initialize those two members. Didn't do any harm since they depend on a set view bitmap and are set when setting one. * We can safe that resize_frame() call in case no view bitmap is set. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39931 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
bd06a41c |
|
02-Aug-2010 |
Clemens Zeidler <clemens.zeidler@googlemail.com> |
Cleanup of the some header includes. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37856 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
4b0459b2 |
|
04-Nov-2009 |
Axel Dörfler <axeld@pinc-software.de> |
* Refactored ServerBitmap a bit: it now inherits from Referenceable instead of roling its own solution. * Also removed BitmapManager::DeleteBitmap() - you only call ServerBitmap::RemoveReference(), and that one will notify the manager if needed. * Some more cleanup. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33878 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
85a7877f |
|
04-Nov-2009 |
Axel Dörfler <axeld@pinc-software.de> |
* ServerApp's bitmap and picture handling was completely broken, as it ignored concurrency as well as reference counting, causing occasional crashes and memory corruption. * ServerPicture now subclasses Referenceable, and will notify its owner when it's going to be deleted. This might bring some regressions, although I couldn't spot anything wrong yet. * ServerBitmap will now also notify its owner when it's going to be deleted as well. * Switched from the former picture/bitmap lists to a std::map. This also solves the issue of not checking whether or not the bitmap/picture actually belongs to the ServerApp (before, all apps could access and delete all pictures/bitmaps) * Introduced a new fMapLocker that guards the new maps. * ServerWindow now uses GetBitmap()/GetPicture(), and gives up its reference after use. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33876 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
edb62548 |
|
03-Sep-2009 |
Michael Lotz <mmlr@mlotz.ch> |
When an app is going down and the windows are destroyed, all views are detached. On detaching the views remove themselves from the app local token space. Since the ServerApp only waits for all ServerWindows to be removed from the window list and not for their actual destruction, it can happen that the ServerApp is deleted before the window destruction and hence the view detaching has finished. The views would then access a stale ServerApp pointer and try to remove their token from the deleted token space. To avoid that we set the ServerApp pointer to NULL when the window is removed from the app (as after that the app can be gone any time) and check for that case when detaching. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32927 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
701dae79 |
|
15-Aug-2009 |
Stefano Ceccherini <stefano.ceccherini@gmail.com> |
Squashed a TODO: Added a View::InitCheck() and use it after construction. Removed the check for View->CurrentState() == NULL. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32412 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
19e179ca |
|
19-Jun-2009 |
Stephan Aßmus <superstippi@gmx.de> |
* Moved the implementation of SetViewCursor from the thread of the window of the view into the application thread. This solves the race condition with asynchronous SetViewCursor and deleting the cursor immediately afterwards for real. * The ServerApp now requires a reference to the current cursor, just in case... * Added TODOs for caching the BView token, it's currently resolved for every single BView call that talks to the server... not good! git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31133 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
55a88f0c |
|
29-Mar-2009 |
Stephan Aßmus <superstippi@gmx.de> |
When a view has B_DRAW_ON_CHILDREN set, do not ignore the user clipping when painting the background. The user may have set that on purpose. For regular views, it doesn't really make sense to use the user clipping for painting the background, since there is no way these parts could ever be painted at all. In Draw() there will be a new view state on the stack, so the client has no way to unset the clipping. On the other hand, there may be useful cases where the user applied a clipping, and wants itself not drawing outside of it, but does want the background painted. (For example BTextView::SetTextRect() may use this in the future.) git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29790 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
2e44cfce |
|
29-Mar-2009 |
Stephan Aßmus <superstippi@gmx.de> |
Make BView::PopState() (executed at least on every call to Draw()) a lot cheaper by preventing to rebuild the clipping on the app_server side. I think this was commented out, because user clipping was broken until some point and I forgot to reenable it after I fixed it. At least I cannot spot any regressions when running with this patch now would I expect to see regressions, since DrawStates do not mess with the screen clipping, unless they get a clipping region assigned when the (user) clipping changes during the state's life time. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29773 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
7eed63a1 |
|
28-Mar-2009 |
Stephan Aßmus <superstippi@gmx.de> |
Use the view bitmap options also when drawing the bitmap. This way, someone can pass filter options to SetViewBitmap() as well. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29753 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
2b4f382a |
|
24-Feb-2009 |
Stephan Aßmus <superstippi@gmx.de> |
* When painting the view background bitmap, make sure to do this with a reasonable drawing mode. Otherwise the current graphics state setup may not be what we need. * Automatic white space cleanup. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29309 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
|
#
52de6dce |
|
08-Nov-2008 |
Stephan Aßmus <superstippi@gmx.de> |
Moved the gradient_type and color_step structs into the BGradient class/namespace. Renamed the B_GRADIENT_* types to TYPE_* as the context is already given. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28564 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
|
#
3e8d3c5f |
|
13-Sep-2008 |
Michael Lotz <mmlr@mlotz.ch> |
* CID 1090: Check the view pointer for NULL before dereferencing it. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27484 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
581e6786 |
|
09-Jun-2008 |
Stephan Aßmus <superstippi@gmx.de> |
* Change the protocol for sending the affected view tokens during an update session to also include each view's individual update rect (in screen coords). Should actually not be mush slower than the old version, and hopefully makes it possible to have smarter BView::Draw() implementations which should make more than up for any potential speed loss. * Removed unused version of View::AddTokensForViewsInRegion(). git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25879 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
ea2bcbf4 |
|
07-Jun-2008 |
Michael Lotz <mmlr@mlotz.ch> |
* Fix leaking the user and combined screen and user clipping. * Fix using fScreenAndUserClipping directly in CopyBits() that could crash when in fScreenAndUserClipping wasn't used (when there's no user clipping for example). git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25856 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
f0c3c996 |
|
07-Jun-2008 |
Michael Lotz <mmlr@mlotz.ch> |
* Decouple local and user clipping into normal local clipping and a user clipping region pointer. * Provide _ScreenClipping() that only includes local and screen clipping but not user clipping. * Provide ScreenAndUserClipping() that returns screen clipping if no user clipping is present, or returns a combined region that is then cached. * Adapt all places where the former methods are used and decide which one to use depending on the relevance of user clipping. User clipping is now ignored for background clearing and when determining whether or not to call Draw() on a view. This should make Haiku behaviourally compatible with BeOS (confirmed by the ClippingAndRedraw test app) and should also fix the Firefox redraw issues. Stephan please review! git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25854 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
79ef179c |
|
17-Mar-2008 |
Stephan Aßmus <superstippi@gmx.de> |
A test app revealed some bugs with regards to client provided clipping regions: * It is necessary to store the local origin and scale of a view state, at least for the clipping region and especially because the scale affects the clipping region. Ie origin and scale of one state affect the clipping region, at the time the clipping is evaluated, ie SetOrigin(...); ConstrainClippingRegion(...); is equivalent to ConstrainClippingRegion(...); SetOrigin(...); The current client provided clipping region at the time of PushState() always constrains the region of the new state. The previous region and the current local clipping may have their own individual origin and scale. To support all this, I needed to store origin and scale of each state on the stack, but I do cache the combined origin and scale. Caching only the combined region is not possible though. So the new implementation is slower than the previous, but more correct. * Refactored "copy constructor" from DrawState, which is not really a copy constructor anyways, made it private. It is only used by PushState(). * Removed some dead code from DrawState. All this improves Firefox redraw issues a tiny bit, but does not fix them. Either I am not covering Firefox needs with my test app, or the bug is somewhere else. At least Haiku behaves like BeOS with regard to client clipping regions and the state stack now... git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24428 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
437b1927 |
|
08-Mar-2008 |
Axel Dörfler <axeld@pinc-software.de> |
* Removed severly outdated DebugInfoManager. * More "layer" cleanup. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24305 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
953d895e |
|
07-Mar-2008 |
Axel Dörfler <axeld@pinc-software.de> |
* Got rid of the "Layer" part of WindowLayer, ViewLayer, WorkspacesLayer (now WorkspacesView), OffscreenWindowLayer. * Renamed ServerScreen.cpp/h to Screen.cpp/h (the class was already called Screen). git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24303 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
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().
|
#
a01eaea74bd23df74fd56411b94e56888bb7f98d |
|
28-Jan-2014 |
Stephan Aßmus <superstippi@gmx.de> |
app_server: Some cleanup of the new clipping code. * Fixed some coding style issues and use regular pointers like everywhere else in app_server code. * Moved _RenderPicture() from View to AlphaMask.
|
#
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.
|
#
77bf4d8d5156816e701b47476cf4c07bc7a4ebc2 |
|
21-Jan-2014 |
Adrien Destugues <pulkomandy@pulkomandy.tk> |
Style fixes.
|
#
e1a301151feebf3c335202071b5d3c38c40b2f9a |
|
21-Jan-2014 |
Adrien Destugues <pulkomandy@pulkomandy.tk> |
Introduce DrawingContext View superclass In order to properly implement ClipToPicture in BView, we need to render a Picture to a Bitmap. This is currently done client-side, but the overhead for this (creating a BBitmap that accepts views, including a window thread, adding a view to it, and rendering the picture to the view, then sending the result to app_server) isn't acceptable. Moreover, the bitmap drawn this way is clipped to the view size, and the clipping won't work when the view is scaled or translated. So, we need to move the Bitmap creation server-side. However, app_server currently have no means of doing this. Factor out the relevant parts of View: a DrawingState stack with PushState/PopState, a DrawingEngine, and a ConvertToScreen transformation. Another implementation of the DrawingContext will allow us to also draw a picture directly using a Painter and low-level pixel buffer, in a format suitable for use as an AGG alpha mask.
|
#
3fed1a15f58e8d6fe6b492f3b94bb3625ffeddbd |
|
05-Aug-2012 |
Alex Smith <alex@alex-smith.me.uk> |
Get app_server working on x86_64. With this commit, app_server now compiles and runs at boot! Nothing particularly interesting happens, just the blue background and a mouse pointer. Remote backends are broken and not compiled in, see #8834. Note that it won't be possible to build this quite yet, need to get the FreeType package uploaded.
|
#
95e95fee390d4841a7b6c54c69edc958fd73445a |
|
23-Dec-2010 |
Michael Lotz <mmlr@mlotz.ch> |
* CID 10247: Initialize those two members. Didn't do any harm since they depend on a set view bitmap and are set when setting one. * We can safe that resize_frame() call in case no view bitmap is set. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39931 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
bd06a41c3aadc5a6d4b2cd983660254a9479dd77 |
|
02-Aug-2010 |
Clemens Zeidler <clemens.zeidler@googlemail.com> |
Cleanup of the some header includes. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37856 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
4b0459b2eef38f07b8c0c4426860dccb61a1134a |
|
04-Nov-2009 |
Axel Dörfler <axeld@pinc-software.de> |
* Refactored ServerBitmap a bit: it now inherits from Referenceable instead of roling its own solution. * Also removed BitmapManager::DeleteBitmap() - you only call ServerBitmap::RemoveReference(), and that one will notify the manager if needed. * Some more cleanup. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33878 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
85a7877f80790d60e084ba8d7e6f1ae5f9a6fee1 |
|
04-Nov-2009 |
Axel Dörfler <axeld@pinc-software.de> |
* ServerApp's bitmap and picture handling was completely broken, as it ignored concurrency as well as reference counting, causing occasional crashes and memory corruption. * ServerPicture now subclasses Referenceable, and will notify its owner when it's going to be deleted. This might bring some regressions, although I couldn't spot anything wrong yet. * ServerBitmap will now also notify its owner when it's going to be deleted as well. * Switched from the former picture/bitmap lists to a std::map. This also solves the issue of not checking whether or not the bitmap/picture actually belongs to the ServerApp (before, all apps could access and delete all pictures/bitmaps) * Introduced a new fMapLocker that guards the new maps. * ServerWindow now uses GetBitmap()/GetPicture(), and gives up its reference after use. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33876 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
edb6254810123b41166fb49c1a7413b77205694b |
|
03-Sep-2009 |
Michael Lotz <mmlr@mlotz.ch> |
When an app is going down and the windows are destroyed, all views are detached. On detaching the views remove themselves from the app local token space. Since the ServerApp only waits for all ServerWindows to be removed from the window list and not for their actual destruction, it can happen that the ServerApp is deleted before the window destruction and hence the view detaching has finished. The views would then access a stale ServerApp pointer and try to remove their token from the deleted token space. To avoid that we set the ServerApp pointer to NULL when the window is removed from the app (as after that the app can be gone any time) and check for that case when detaching. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32927 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
701dae79c9013ed0f4474c6ef845813678f993d5 |
|
15-Aug-2009 |
Stefano Ceccherini <stefano.ceccherini@gmail.com> |
Squashed a TODO: Added a View::InitCheck() and use it after construction. Removed the check for View->CurrentState() == NULL. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32412 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
19e179ca4ff838084b9abb0dd19932ac5fcd0051 |
|
19-Jun-2009 |
Stephan Aßmus <superstippi@gmx.de> |
* Moved the implementation of SetViewCursor from the thread of the window of the view into the application thread. This solves the race condition with asynchronous SetViewCursor and deleting the cursor immediately afterwards for real. * The ServerApp now requires a reference to the current cursor, just in case... * Added TODOs for caching the BView token, it's currently resolved for every single BView call that talks to the server... not good! git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31133 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
55a88f0c29c97fd028fd1e4dbd57b01f6c286893 |
|
29-Mar-2009 |
Stephan Aßmus <superstippi@gmx.de> |
When a view has B_DRAW_ON_CHILDREN set, do not ignore the user clipping when painting the background. The user may have set that on purpose. For regular views, it doesn't really make sense to use the user clipping for painting the background, since there is no way these parts could ever be painted at all. In Draw() there will be a new view state on the stack, so the client has no way to unset the clipping. On the other hand, there may be useful cases where the user applied a clipping, and wants itself not drawing outside of it, but does want the background painted. (For example BTextView::SetTextRect() may use this in the future.) git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29790 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
2e44cfce6671cbb0a5a1658fbb197899def3c73b |
|
29-Mar-2009 |
Stephan Aßmus <superstippi@gmx.de> |
Make BView::PopState() (executed at least on every call to Draw()) a lot cheaper by preventing to rebuild the clipping on the app_server side. I think this was commented out, because user clipping was broken until some point and I forgot to reenable it after I fixed it. At least I cannot spot any regressions when running with this patch now would I expect to see regressions, since DrawStates do not mess with the screen clipping, unless they get a clipping region assigned when the (user) clipping changes during the state's life time. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29773 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
7eed63a18b55d7b789a38904bc0120105e03cf93 |
|
28-Mar-2009 |
Stephan Aßmus <superstippi@gmx.de> |
Use the view bitmap options also when drawing the bitmap. This way, someone can pass filter options to SetViewBitmap() as well. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29753 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
2b4f382aacd4b995aaa654c08cdb07e1ed1dd5e2 |
|
24-Feb-2009 |
Stephan Aßmus <superstippi@gmx.de> |
* When painting the view background bitmap, make sure to do this with a reasonable drawing mode. Otherwise the current graphics state setup may not be what we need. * Automatic white space cleanup. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29309 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
|
#
52de6dce94e48d957a3bb96d6b256f45a953f4c2 |
|
08-Nov-2008 |
Stephan Aßmus <superstippi@gmx.de> |
Moved the gradient_type and color_step structs into the BGradient class/namespace. Renamed the B_GRADIENT_* types to TYPE_* as the context is already given. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28564 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
|
#
3e8d3c5f9869cab1ec08123fd238b5b2acc575ed |
|
13-Sep-2008 |
Michael Lotz <mmlr@mlotz.ch> |
* CID 1090: Check the view pointer for NULL before dereferencing it. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27484 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
581e67867c88e4dae51de5c30839eabd303cc0a9 |
|
09-Jun-2008 |
Stephan Aßmus <superstippi@gmx.de> |
* Change the protocol for sending the affected view tokens during an update session to also include each view's individual update rect (in screen coords). Should actually not be mush slower than the old version, and hopefully makes it possible to have smarter BView::Draw() implementations which should make more than up for any potential speed loss. * Removed unused version of View::AddTokensForViewsInRegion(). git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25879 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
ea2bcbf4af2a7ad4cd81f4da5eeb2c50a3fd72bc |
|
07-Jun-2008 |
Michael Lotz <mmlr@mlotz.ch> |
* Fix leaking the user and combined screen and user clipping. * Fix using fScreenAndUserClipping directly in CopyBits() that could crash when in fScreenAndUserClipping wasn't used (when there's no user clipping for example). git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25856 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
f0c3c996cd92350f083210e5cc0d161abbbc3aa1 |
|
07-Jun-2008 |
Michael Lotz <mmlr@mlotz.ch> |
* Decouple local and user clipping into normal local clipping and a user clipping region pointer. * Provide _ScreenClipping() that only includes local and screen clipping but not user clipping. * Provide ScreenAndUserClipping() that returns screen clipping if no user clipping is present, or returns a combined region that is then cached. * Adapt all places where the former methods are used and decide which one to use depending on the relevance of user clipping. User clipping is now ignored for background clearing and when determining whether or not to call Draw() on a view. This should make Haiku behaviourally compatible with BeOS (confirmed by the ClippingAndRedraw test app) and should also fix the Firefox redraw issues. Stephan please review! git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25854 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
79ef179c52ff23c1338a34a95452114d51bffeda |
|
17-Mar-2008 |
Stephan Aßmus <superstippi@gmx.de> |
A test app revealed some bugs with regards to client provided clipping regions: * It is necessary to store the local origin and scale of a view state, at least for the clipping region and especially because the scale affects the clipping region. Ie origin and scale of one state affect the clipping region, at the time the clipping is evaluated, ie SetOrigin(...); ConstrainClippingRegion(...); is equivalent to ConstrainClippingRegion(...); SetOrigin(...); The current client provided clipping region at the time of PushState() always constrains the region of the new state. The previous region and the current local clipping may have their own individual origin and scale. To support all this, I needed to store origin and scale of each state on the stack, but I do cache the combined origin and scale. Caching only the combined region is not possible though. So the new implementation is slower than the previous, but more correct. * Refactored "copy constructor" from DrawState, which is not really a copy constructor anyways, made it private. It is only used by PushState(). * Removed some dead code from DrawState. All this improves Firefox redraw issues a tiny bit, but does not fix them. Either I am not covering Firefox needs with my test app, or the bug is somewhere else. At least Haiku behaves like BeOS with regard to client clipping regions and the state stack now... git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24428 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
437b19277feacd48292ca9ec814a38da17e4eb89 |
|
08-Mar-2008 |
Axel Dörfler <axeld@pinc-software.de> |
* Removed severly outdated DebugInfoManager. * More "layer" cleanup. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24305 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
953d895e020ece5d50cfc2e76d9f370ceb5c45e7 |
|
07-Mar-2008 |
Axel Dörfler <axeld@pinc-software.de> |
* Got rid of the "Layer" part of WindowLayer, ViewLayer, WorkspacesLayer (now WorkspacesView), OffscreenWindowLayer. * Renamed ServerScreen.cpp/h to Screen.cpp/h (the class was already called Screen). git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24303 a95241bf-73f2-0310-859d-f6bbb57e9c96
|