2006-03-18 19:42:14 +03:00
|
|
|
/*
|
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
2008-03-18 03:04:12 +03:00
|
|
|
* Copyright 2001-2008, Haiku.
|
2006-03-18 19:42:14 +03:00
|
|
|
* Distributed under the terms of the MIT License.
|
|
|
|
*
|
|
|
|
* Authors:
|
|
|
|
* DarkWyrm <bpmagic@columbus.rr.com>
|
|
|
|
* Adi Oanca <adioanca@mymail.ro>
|
|
|
|
* Stephan Aßmus <superstippi@gmx.de>
|
|
|
|
* Axel Dörfler, axeld@pinc-software.de
|
|
|
|
*/
|
|
|
|
#ifndef _DRAW_STATE_H_
|
|
|
|
#define _DRAW_STATE_H_
|
|
|
|
|
|
|
|
|
|
|
|
#include <GraphicsDefs.h>
|
|
|
|
#include <InterfaceDefs.h>
|
|
|
|
#include <Point.h>
|
|
|
|
#include <View.h> // for B_FONT_ALL
|
|
|
|
|
|
|
|
#include "FontManager.h"
|
|
|
|
#include "ServerFont.h"
|
|
|
|
#include "PatternHandler.h"
|
|
|
|
|
|
|
|
class BRegion;
|
|
|
|
|
|
|
|
namespace BPrivate {
|
|
|
|
class LinkReceiver;
|
|
|
|
class LinkSender;
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
|
|
class DrawState {
|
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
2008-03-18 03:04:12 +03:00
|
|
|
public:
|
2006-03-18 19:42:14 +03:00
|
|
|
DrawState();
|
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
2008-03-18 03:04:12 +03:00
|
|
|
private:
|
|
|
|
DrawState(DrawState* from);
|
|
|
|
public:
|
2006-03-18 19:42:14 +03:00
|
|
|
virtual ~DrawState();
|
|
|
|
|
|
|
|
DrawState* PushState();
|
|
|
|
DrawState* PopState();
|
|
|
|
DrawState* PreviousState() const { return fPreviousState; }
|
|
|
|
|
|
|
|
void ReadFontFromLink(BPrivate::LinkReceiver& link);
|
|
|
|
// NOTE: ReadFromLink() does not read Font state!!
|
|
|
|
// It was separate in ServerWindow, and I didn't
|
|
|
|
// want to change it without knowing implications.
|
|
|
|
void ReadFromLink(BPrivate::LinkReceiver& link);
|
|
|
|
void WriteToLink(BPrivate::LinkSender& link) const;
|
|
|
|
|
|
|
|
// coordinate transformation
|
|
|
|
void SetOrigin(const BPoint& origin);
|
|
|
|
const BPoint& Origin() const
|
|
|
|
{ return fOrigin; }
|
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
2008-03-18 03:04:12 +03:00
|
|
|
const BPoint& CombinedOrigin() const
|
|
|
|
{ return fCombinedOrigin; }
|
2006-03-18 19:42:14 +03:00
|
|
|
|
|
|
|
void SetScale(float scale);
|
|
|
|
float Scale() const
|
|
|
|
{ return fScale; }
|
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
2008-03-18 03:04:12 +03:00
|
|
|
float CombinedScale() const
|
|
|
|
{ return fCombinedScale; }
|
|
|
|
|
|
|
|
// additional clipping as requested by client
|
|
|
|
void SetClippingRegion(const BRegion* region);
|
|
|
|
|
|
|
|
bool HasClipping() const;
|
2009-03-29 14:51:26 +04:00
|
|
|
bool HasAdditionalClipping() const;
|
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
2008-03-18 03:04:12 +03:00
|
|
|
bool GetCombinedClippingRegion(BRegion* region) const;
|
2006-03-18 19:42:14 +03:00
|
|
|
|
|
|
|
// coordinate transformations
|
|
|
|
void Transform(float* x, float* y) const;
|
|
|
|
void InverseTransform(float* x, float* y) const;
|
|
|
|
|
|
|
|
void Transform(BPoint* point) const;
|
|
|
|
void Transform(BRect* rect) const;
|
|
|
|
void Transform(BRegion* region) const;
|
|
|
|
|
|
|
|
void InverseTransform(BPoint* point) const;
|
|
|
|
|
|
|
|
// color
|
2007-08-17 16:56:20 +04:00
|
|
|
void SetHighColor(const rgb_color& color);
|
|
|
|
const rgb_color& HighColor() const
|
2006-03-18 19:42:14 +03:00
|
|
|
{ return fHighColor; }
|
|
|
|
|
2007-08-17 16:56:20 +04:00
|
|
|
void SetLowColor(const rgb_color& color);
|
|
|
|
const rgb_color& LowColor() const
|
2006-03-18 19:42:14 +03:00
|
|
|
{ return fLowColor; }
|
|
|
|
|
|
|
|
void SetPattern(const Pattern& pattern);
|
|
|
|
const Pattern& GetPattern() const
|
|
|
|
{ return fPattern; }
|
|
|
|
|
|
|
|
// drawing/blending mode
|
|
|
|
void SetDrawingMode(drawing_mode mode);
|
|
|
|
drawing_mode GetDrawingMode() const
|
|
|
|
{ return fDrawingMode; }
|
|
|
|
|
|
|
|
void SetBlendingMode(source_alpha srcMode,
|
|
|
|
alpha_function fncMode);
|
|
|
|
source_alpha AlphaSrcMode() const
|
|
|
|
{ return fAlphaSrcMode; }
|
|
|
|
alpha_function AlphaFncMode() const
|
|
|
|
{ return fAlphaFncMode; }
|
|
|
|
|
|
|
|
// pen
|
|
|
|
void SetPenLocation(const BPoint& location);
|
|
|
|
const BPoint& PenLocation() const;
|
|
|
|
|
|
|
|
void SetPenSize(float size);
|
|
|
|
float PenSize() const;
|
2007-08-08 22:29:09 +04:00
|
|
|
float UnscaledPenSize() const;
|
2006-03-18 19:42:14 +03:00
|
|
|
|
|
|
|
// font
|
|
|
|
void SetFont(const ServerFont& font,
|
|
|
|
uint32 flags = B_FONT_ALL);
|
|
|
|
const ServerFont& Font() const
|
|
|
|
{ return fFont; }
|
|
|
|
|
|
|
|
// overrides aliasing flag contained in SeverFont::Flags())
|
|
|
|
void SetForceFontAliasing(bool aliasing);
|
|
|
|
bool ForceFontAliasing() const
|
|
|
|
{ return fFontAliasing; }
|
|
|
|
|
|
|
|
// postscript style settings
|
|
|
|
void SetLineCapMode(cap_mode mode);
|
|
|
|
cap_mode LineCapMode() const
|
|
|
|
{ return fLineCapMode; }
|
|
|
|
|
|
|
|
void SetLineJoinMode(join_mode mode);
|
|
|
|
join_mode LineJoinMode() const
|
|
|
|
{ return fLineJoinMode; }
|
|
|
|
|
|
|
|
void SetMiterLimit(float limit);
|
|
|
|
float MiterLimit() const
|
|
|
|
{ return fMiterLimit; }
|
|
|
|
|
|
|
|
// convenience functions
|
|
|
|
void PrintToStream() const;
|
|
|
|
|
|
|
|
void SetSubPixelPrecise(bool precise);
|
|
|
|
bool SubPixelPrecise() const
|
|
|
|
{ return fSubPixelPrecise; }
|
|
|
|
|
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
2008-03-18 03:04:12 +03:00
|
|
|
protected:
|
2006-03-18 19:42:14 +03:00
|
|
|
BPoint fOrigin;
|
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
2008-03-18 03:04:12 +03:00
|
|
|
BPoint fCombinedOrigin;
|
2006-03-18 19:42:14 +03:00
|
|
|
float fScale;
|
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
2008-03-18 03:04:12 +03:00
|
|
|
float fCombinedScale;
|
2006-03-18 19:42:14 +03:00
|
|
|
|
|
|
|
BRegion* fClippingRegion;
|
|
|
|
|
2007-08-17 16:56:20 +04:00
|
|
|
rgb_color fHighColor;
|
|
|
|
rgb_color fLowColor;
|
2006-03-18 19:42:14 +03:00
|
|
|
Pattern fPattern;
|
|
|
|
|
|
|
|
drawing_mode fDrawingMode;
|
|
|
|
source_alpha fAlphaSrcMode;
|
|
|
|
alpha_function fAlphaFncMode;
|
|
|
|
|
|
|
|
BPoint fPenLocation;
|
|
|
|
float fPenSize;
|
|
|
|
|
|
|
|
ServerFont fFont;
|
|
|
|
// overrides font aliasing flag
|
|
|
|
bool fFontAliasing;
|
|
|
|
|
|
|
|
// This is not part of the normal state stack.
|
2008-03-08 18:28:31 +03:00
|
|
|
// The view will update it in PushState/PopState.
|
2006-03-18 19:42:14 +03:00
|
|
|
// A BView can have a flag "B_SUBPIXEL_PRECISE",
|
|
|
|
// I never knew what it does on R5, but I can use
|
|
|
|
// it in Painter to actually draw stuff with
|
|
|
|
// sub-pixel coordinates. It means
|
|
|
|
// StrokeLine(BPoint(10, 5), BPoint(20, 9));
|
|
|
|
// will look different from
|
|
|
|
// StrokeLine(BPoint(10.3, 5.8), BPoint(20.6, 9.5));
|
|
|
|
bool fSubPixelPrecise;
|
|
|
|
|
|
|
|
cap_mode fLineCapMode;
|
|
|
|
join_mode fLineJoinMode;
|
|
|
|
float fMiterLimit;
|
|
|
|
// "internal", used to calculate the size
|
|
|
|
// of the font (again) when the scale changes
|
|
|
|
float fUnscaledFontSize;
|
|
|
|
|
|
|
|
DrawState* fPreviousState;
|
|
|
|
};
|
|
|
|
|
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
2008-03-18 03:04:12 +03:00
|
|
|
#endif // _DRAW_STATE_H_
|