2015-05-03 22:32:37 +03:00
|
|
|
/* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
|
|
|
|
/* vim: set ts=8 sts=2 et sw=2 tw=80: */
|
2013-09-20 14:21:04 +04:00
|
|
|
/* This Source Code Form is subject to the terms of the Mozilla Public
|
|
|
|
* License, v. 2.0. If a copy of the MPL was not distributed with this
|
|
|
|
* file, You can obtain one at http://mozilla.org/MPL/2.0/. */
|
|
|
|
|
|
|
|
#include "mozilla/dom/DOMQuad.h"
|
|
|
|
|
|
|
|
#include "mozilla/dom/DOMQuadBinding.h"
|
|
|
|
#include "mozilla/dom/DOMPoint.h"
|
|
|
|
#include "mozilla/dom/DOMRect.h"
|
|
|
|
#include <algorithm>
|
|
|
|
|
|
|
|
using namespace mozilla;
|
|
|
|
using namespace mozilla::dom;
|
|
|
|
using namespace mozilla::gfx;
|
|
|
|
|
2018-05-24 02:56:22 +03:00
|
|
|
NS_IMPL_CYCLE_COLLECTION_WRAPPERCACHE(DOMQuad, mParent, mBounds, mPoints[0],
|
2014-04-29 12:57:00 +04:00
|
|
|
mPoints[1], mPoints[2], mPoints[3])
|
2013-09-20 14:21:04 +04:00
|
|
|
|
|
|
|
NS_IMPL_CYCLE_COLLECTION_ROOT_NATIVE(DOMQuad, AddRef)
|
|
|
|
NS_IMPL_CYCLE_COLLECTION_UNROOT_NATIVE(DOMQuad, Release)
|
|
|
|
|
|
|
|
DOMQuad::DOMQuad(nsISupports* aParent, CSSPoint aPoints[4])
|
|
|
|
: mParent(aParent)
|
|
|
|
{
|
|
|
|
for (uint32_t i = 0; i < 4; ++i) {
|
|
|
|
mPoints[i] = new DOMPoint(aParent, aPoints[i].x, aPoints[i].y);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
DOMQuad::DOMQuad(nsISupports* aParent)
|
|
|
|
: mParent(aParent)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
DOMQuad::~DOMQuad()
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
JSObject*
|
Bug 1117172 part 3. Change the wrappercached WrapObject methods to allow passing in aGivenProto. r=peterv
The only manual changes here are to BindingUtils.h, BindingUtils.cpp,
Codegen.py, Element.cpp, IDBFileRequest.cpp, IDBObjectStore.cpp,
dom/workers/Navigator.cpp, WorkerPrivate.cpp, DeviceStorageRequestChild.cpp,
Notification.cpp, nsGlobalWindow.cpp, MessagePort.cpp, nsJSEnvironment.cpp,
Sandbox.cpp, XPCConvert.cpp, ExportHelpers.cpp, and DataStoreService.cpp. The
rest of this diff was generated by running the following commands:
find . -name "*.h" -o -name "*.cpp" | xargs perl -pi -e 'BEGIN { $/ = undef } s/(WrapObjectInternal\(JSContext *\* *(?:aCx|cx|aContext|aCtx|js))\)/\1, JS::Handle<JSObject*> aGivenProto)/g'
find . -name "*.h" -o -name "*.cpp" | xargs perl -pi -e 'BEGIN { $/ = undef } s/(WrapObjectInternal\((?:aCx|cx|aContext|aCtx|js))\)/\1, aGivenProto)/g'
find . -name "*.h" -o -name "*.cpp" | xargs perl -pi -e 'BEGIN { $/ = undef } s/(WrapNode\(JSContext *\* *(?:aCx|cx|aContext|aCtx|js))\)/\1, JS::Handle<JSObject*> aGivenProto)/g'
find . -name "*.h" -o -name "*.cpp" | xargs perl -pi -e 'BEGIN { $/ = undef } s/(WrapNode\((?:aCx|cx|aContext|aCtx|js))\)/\1, aGivenProto)/g'
find . -name "*.h" -o -name "*.cpp" | xargs perl -pi -e 'BEGIN { $/ = undef } s/(WrapObject\(JSContext *\* *(?:aCx|cx|aContext|aCtx|js))\)/\1, JS::Handle<JSObject*> aGivenProto)/g'
find . -name "*.h" -o -name "*.cpp" | xargs perl -pi -e 'BEGIN { $/ = undef } s/(Binding(?:_workers)?::Wrap\((?:aCx|cx|aContext|aCtx|js), [^,)]+)\)/\1, aGivenProto)/g'
2015-03-19 17:13:33 +03:00
|
|
|
DOMQuad::WrapObject(JSContext* aCx, JS::Handle<JSObject*> aGivenProto)
|
2013-09-20 14:21:04 +04:00
|
|
|
{
|
2018-06-26 00:20:54 +03:00
|
|
|
return DOMQuad_Binding::Wrap(aCx, this, aGivenProto);
|
2013-09-20 14:21:04 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
already_AddRefed<DOMQuad>
|
|
|
|
DOMQuad::Constructor(const GlobalObject& aGlobal,
|
|
|
|
const DOMPointInit& aP1,
|
|
|
|
const DOMPointInit& aP2,
|
|
|
|
const DOMPointInit& aP3,
|
|
|
|
const DOMPointInit& aP4,
|
|
|
|
ErrorResult& aRV)
|
|
|
|
{
|
2015-10-18 08:24:48 +03:00
|
|
|
RefPtr<DOMQuad> obj = new DOMQuad(aGlobal.GetAsSupports());
|
Bug 1186265 - Partially update DOMPoint, DOMQuad, DOMRect, DOMMatrix. r=bz
Some notes: this does not fully bring us to compliance to the current spec.
Instead, these are the fixes that I needed to make in order to make
css/geometry/interfaces.html pass with the DOMPoint changes in the previous
patches. I don't fully understand why that patch caused the test to fail the
way it did, but it ended up being easier to fix our code than understand why
the harness was falling over.
The DOMQuad::QuadBounds class was the source of some confusion for me. Now
that DOMRectReadOnly is a concrete class with members, I wanted to avoid
wasting them. However, the spec is unclear as to whether a DOMQuad's bound's
should be live -- that is because DOMQuad exposes DOMPoint, we can set its
points after retrieving a QuadBounds object. Our current code is live, setting
the points changes the QuadBounds. Chromium's current behavior is to never
update the QuadBounds object. I've left our behavior untouched in this patch
(and waste 4 doubles per QuadBounds object), but I am intending to file a bug
to understand what the intent of the spec is. I wonder if the author intended
the points to be DOMPointReadOnly instead. If so, we could simplify the
DOMRectReadOnly code and get rid of the virtual getters, which would be nice.
I also wasn't thrilled to put the DOMMatrix setters on the DOMMatrixReadOnly
class, but for brevity and simplicity of implementation, I've made them
public. I briefly considered making the setters protected on the ReadOnly
version of the class, but I'm not convinced that having to explicitly make
them public on the derived class is worth the extra copies of the names.
MozReview-Commit-ID: CjdW4Nbnc6A
--HG--
extra : rebase_source : 44489693afebff571a415b487e29fa6153288421
2018-03-30 02:19:31 +03:00
|
|
|
obj->mPoints[0] = DOMPoint::FromPoint(aGlobal, aP1);
|
|
|
|
obj->mPoints[1] = DOMPoint::FromPoint(aGlobal, aP2);
|
|
|
|
obj->mPoints[2] = DOMPoint::FromPoint(aGlobal, aP3);
|
|
|
|
obj->mPoints[3] = DOMPoint::FromPoint(aGlobal, aP4);
|
2013-09-20 14:21:04 +04:00
|
|
|
return obj.forget();
|
|
|
|
}
|
|
|
|
|
|
|
|
already_AddRefed<DOMQuad>
|
|
|
|
DOMQuad::Constructor(const GlobalObject& aGlobal, const DOMRectReadOnly& aRect,
|
|
|
|
ErrorResult& aRV)
|
|
|
|
{
|
|
|
|
CSSPoint points[4];
|
|
|
|
Float x = aRect.X(), y = aRect.Y(), w = aRect.Width(), h = aRect.Height();
|
|
|
|
points[0] = CSSPoint(x, y);
|
|
|
|
points[1] = CSSPoint(x + w, y);
|
|
|
|
points[2] = CSSPoint(x + w, y + h);
|
|
|
|
points[3] = CSSPoint(x, y + h);
|
2015-10-18 08:24:48 +03:00
|
|
|
RefPtr<DOMQuad> obj = new DOMQuad(aGlobal.GetAsSupports(), points);
|
2013-09-20 14:21:04 +04:00
|
|
|
return obj.forget();
|
|
|
|
}
|
|
|
|
|
Bug 1186265 - Partially update DOMPoint, DOMQuad, DOMRect, DOMMatrix. r=bz
Some notes: this does not fully bring us to compliance to the current spec.
Instead, these are the fixes that I needed to make in order to make
css/geometry/interfaces.html pass with the DOMPoint changes in the previous
patches. I don't fully understand why that patch caused the test to fail the
way it did, but it ended up being easier to fix our code than understand why
the harness was falling over.
The DOMQuad::QuadBounds class was the source of some confusion for me. Now
that DOMRectReadOnly is a concrete class with members, I wanted to avoid
wasting them. However, the spec is unclear as to whether a DOMQuad's bound's
should be live -- that is because DOMQuad exposes DOMPoint, we can set its
points after retrieving a QuadBounds object. Our current code is live, setting
the points changes the QuadBounds. Chromium's current behavior is to never
update the QuadBounds object. I've left our behavior untouched in this patch
(and waste 4 doubles per QuadBounds object), but I am intending to file a bug
to understand what the intent of the spec is. I wonder if the author intended
the points to be DOMPointReadOnly instead. If so, we could simplify the
DOMRectReadOnly code and get rid of the virtual getters, which would be nice.
I also wasn't thrilled to put the DOMMatrix setters on the DOMMatrixReadOnly
class, but for brevity and simplicity of implementation, I've made them
public. I briefly considered making the setters protected on the ReadOnly
version of the class, but I'm not convinced that having to explicitly make
them public on the derived class is worth the extra copies of the names.
MozReview-Commit-ID: CjdW4Nbnc6A
--HG--
extra : rebase_source : 44489693afebff571a415b487e29fa6153288421
2018-03-30 02:19:31 +03:00
|
|
|
void
|
|
|
|
DOMQuad::GetHorizontalMinMax(double* aX1, double* aX2) const
|
2013-09-20 14:21:04 +04:00
|
|
|
{
|
Bug 1186265 - Partially update DOMPoint, DOMQuad, DOMRect, DOMMatrix. r=bz
Some notes: this does not fully bring us to compliance to the current spec.
Instead, these are the fixes that I needed to make in order to make
css/geometry/interfaces.html pass with the DOMPoint changes in the previous
patches. I don't fully understand why that patch caused the test to fail the
way it did, but it ended up being easier to fix our code than understand why
the harness was falling over.
The DOMQuad::QuadBounds class was the source of some confusion for me. Now
that DOMRectReadOnly is a concrete class with members, I wanted to avoid
wasting them. However, the spec is unclear as to whether a DOMQuad's bound's
should be live -- that is because DOMQuad exposes DOMPoint, we can set its
points after retrieving a QuadBounds object. Our current code is live, setting
the points changes the QuadBounds. Chromium's current behavior is to never
update the QuadBounds object. I've left our behavior untouched in this patch
(and waste 4 doubles per QuadBounds object), but I am intending to file a bug
to understand what the intent of the spec is. I wonder if the author intended
the points to be DOMPointReadOnly instead. If so, we could simplify the
DOMRectReadOnly code and get rid of the virtual getters, which would be nice.
I also wasn't thrilled to put the DOMMatrix setters on the DOMMatrixReadOnly
class, but for brevity and simplicity of implementation, I've made them
public. I briefly considered making the setters protected on the ReadOnly
version of the class, but I'm not convinced that having to explicitly make
them public on the derived class is worth the extra copies of the names.
MozReview-Commit-ID: CjdW4Nbnc6A
--HG--
extra : rebase_source : 44489693afebff571a415b487e29fa6153288421
2018-03-30 02:19:31 +03:00
|
|
|
double x1, x2;
|
|
|
|
x1 = x2 = Point(0)->X();
|
|
|
|
for (uint32_t i = 1; i < 4; ++i) {
|
|
|
|
double x = Point(i)->X();
|
|
|
|
x1 = std::min(x1, x);
|
|
|
|
x2 = std::max(x2, x);
|
2013-09-20 14:21:04 +04:00
|
|
|
}
|
Bug 1186265 - Partially update DOMPoint, DOMQuad, DOMRect, DOMMatrix. r=bz
Some notes: this does not fully bring us to compliance to the current spec.
Instead, these are the fixes that I needed to make in order to make
css/geometry/interfaces.html pass with the DOMPoint changes in the previous
patches. I don't fully understand why that patch caused the test to fail the
way it did, but it ended up being easier to fix our code than understand why
the harness was falling over.
The DOMQuad::QuadBounds class was the source of some confusion for me. Now
that DOMRectReadOnly is a concrete class with members, I wanted to avoid
wasting them. However, the spec is unclear as to whether a DOMQuad's bound's
should be live -- that is because DOMQuad exposes DOMPoint, we can set its
points after retrieving a QuadBounds object. Our current code is live, setting
the points changes the QuadBounds. Chromium's current behavior is to never
update the QuadBounds object. I've left our behavior untouched in this patch
(and waste 4 doubles per QuadBounds object), but I am intending to file a bug
to understand what the intent of the spec is. I wonder if the author intended
the points to be DOMPointReadOnly instead. If so, we could simplify the
DOMRectReadOnly code and get rid of the virtual getters, which would be nice.
I also wasn't thrilled to put the DOMMatrix setters on the DOMMatrixReadOnly
class, but for brevity and simplicity of implementation, I've made them
public. I briefly considered making the setters protected on the ReadOnly
version of the class, but I'm not convinced that having to explicitly make
them public on the derived class is worth the extra copies of the names.
MozReview-Commit-ID: CjdW4Nbnc6A
--HG--
extra : rebase_source : 44489693afebff571a415b487e29fa6153288421
2018-03-30 02:19:31 +03:00
|
|
|
*aX1 = x1;
|
|
|
|
*aX2 = x2;
|
|
|
|
}
|
2013-09-20 14:21:04 +04:00
|
|
|
|
Bug 1186265 - Partially update DOMPoint, DOMQuad, DOMRect, DOMMatrix. r=bz
Some notes: this does not fully bring us to compliance to the current spec.
Instead, these are the fixes that I needed to make in order to make
css/geometry/interfaces.html pass with the DOMPoint changes in the previous
patches. I don't fully understand why that patch caused the test to fail the
way it did, but it ended up being easier to fix our code than understand why
the harness was falling over.
The DOMQuad::QuadBounds class was the source of some confusion for me. Now
that DOMRectReadOnly is a concrete class with members, I wanted to avoid
wasting them. However, the spec is unclear as to whether a DOMQuad's bound's
should be live -- that is because DOMQuad exposes DOMPoint, we can set its
points after retrieving a QuadBounds object. Our current code is live, setting
the points changes the QuadBounds. Chromium's current behavior is to never
update the QuadBounds object. I've left our behavior untouched in this patch
(and waste 4 doubles per QuadBounds object), but I am intending to file a bug
to understand what the intent of the spec is. I wonder if the author intended
the points to be DOMPointReadOnly instead. If so, we could simplify the
DOMRectReadOnly code and get rid of the virtual getters, which would be nice.
I also wasn't thrilled to put the DOMMatrix setters on the DOMMatrixReadOnly
class, but for brevity and simplicity of implementation, I've made them
public. I briefly considered making the setters protected on the ReadOnly
version of the class, but I'm not convinced that having to explicitly make
them public on the derived class is worth the extra copies of the names.
MozReview-Commit-ID: CjdW4Nbnc6A
--HG--
extra : rebase_source : 44489693afebff571a415b487e29fa6153288421
2018-03-30 02:19:31 +03:00
|
|
|
void
|
|
|
|
DOMQuad::GetVerticalMinMax(double* aY1, double* aY2) const
|
|
|
|
{
|
|
|
|
double y1, y2;
|
|
|
|
y1 = y2 = Point(0)->Y();
|
|
|
|
for (uint32_t i = 1; i < 4; ++i) {
|
|
|
|
double y = Point(i)->Y();
|
|
|
|
y1 = std::min(y1, y);
|
|
|
|
y2 = std::max(y2, y);
|
2018-05-24 02:56:22 +03:00
|
|
|
}
|
Bug 1186265 - Partially update DOMPoint, DOMQuad, DOMRect, DOMMatrix. r=bz
Some notes: this does not fully bring us to compliance to the current spec.
Instead, these are the fixes that I needed to make in order to make
css/geometry/interfaces.html pass with the DOMPoint changes in the previous
patches. I don't fully understand why that patch caused the test to fail the
way it did, but it ended up being easier to fix our code than understand why
the harness was falling over.
The DOMQuad::QuadBounds class was the source of some confusion for me. Now
that DOMRectReadOnly is a concrete class with members, I wanted to avoid
wasting them. However, the spec is unclear as to whether a DOMQuad's bound's
should be live -- that is because DOMQuad exposes DOMPoint, we can set its
points after retrieving a QuadBounds object. Our current code is live, setting
the points changes the QuadBounds. Chromium's current behavior is to never
update the QuadBounds object. I've left our behavior untouched in this patch
(and waste 4 doubles per QuadBounds object), but I am intending to file a bug
to understand what the intent of the spec is. I wonder if the author intended
the points to be DOMPointReadOnly instead. If so, we could simplify the
DOMRectReadOnly code and get rid of the virtual getters, which would be nice.
I also wasn't thrilled to put the DOMMatrix setters on the DOMMatrixReadOnly
class, but for brevity and simplicity of implementation, I've made them
public. I briefly considered making the setters protected on the ReadOnly
version of the class, but I'm not convinced that having to explicitly make
them public on the derived class is worth the extra copies of the names.
MozReview-Commit-ID: CjdW4Nbnc6A
--HG--
extra : rebase_source : 44489693afebff571a415b487e29fa6153288421
2018-03-30 02:19:31 +03:00
|
|
|
*aY1 = y1;
|
|
|
|
*aY2 = y2;
|
|
|
|
}
|
2018-05-24 02:56:22 +03:00
|
|
|
|
2018-05-24 02:56:22 +03:00
|
|
|
DOMRectReadOnly*
|
|
|
|
DOMQuad::Bounds()
|
|
|
|
{
|
|
|
|
if (!mBounds) {
|
|
|
|
mBounds = GetBounds();
|
|
|
|
}
|
|
|
|
return mBounds;
|
|
|
|
}
|
|
|
|
|
Bug 1186265 - Partially update DOMPoint, DOMQuad, DOMRect, DOMMatrix. r=bz
Some notes: this does not fully bring us to compliance to the current spec.
Instead, these are the fixes that I needed to make in order to make
css/geometry/interfaces.html pass with the DOMPoint changes in the previous
patches. I don't fully understand why that patch caused the test to fail the
way it did, but it ended up being easier to fix our code than understand why
the harness was falling over.
The DOMQuad::QuadBounds class was the source of some confusion for me. Now
that DOMRectReadOnly is a concrete class with members, I wanted to avoid
wasting them. However, the spec is unclear as to whether a DOMQuad's bound's
should be live -- that is because DOMQuad exposes DOMPoint, we can set its
points after retrieving a QuadBounds object. Our current code is live, setting
the points changes the QuadBounds. Chromium's current behavior is to never
update the QuadBounds object. I've left our behavior untouched in this patch
(and waste 4 doubles per QuadBounds object), but I am intending to file a bug
to understand what the intent of the spec is. I wonder if the author intended
the points to be DOMPointReadOnly instead. If so, we could simplify the
DOMRectReadOnly code and get rid of the virtual getters, which would be nice.
I also wasn't thrilled to put the DOMMatrix setters on the DOMMatrixReadOnly
class, but for brevity and simplicity of implementation, I've made them
public. I briefly considered making the setters protected on the ReadOnly
version of the class, but I'm not convinced that having to explicitly make
them public on the derived class is worth the extra copies of the names.
MozReview-Commit-ID: CjdW4Nbnc6A
--HG--
extra : rebase_source : 44489693afebff571a415b487e29fa6153288421
2018-03-30 02:19:31 +03:00
|
|
|
already_AddRefed<DOMRectReadOnly>
|
|
|
|
DOMQuad::GetBounds() const
|
|
|
|
{
|
|
|
|
double x1, x2;
|
|
|
|
double y1, y2;
|
2018-05-25 05:36:52 +03:00
|
|
|
|
Bug 1186265 - Partially update DOMPoint, DOMQuad, DOMRect, DOMMatrix. r=bz
Some notes: this does not fully bring us to compliance to the current spec.
Instead, these are the fixes that I needed to make in order to make
css/geometry/interfaces.html pass with the DOMPoint changes in the previous
patches. I don't fully understand why that patch caused the test to fail the
way it did, but it ended up being easier to fix our code than understand why
the harness was falling over.
The DOMQuad::QuadBounds class was the source of some confusion for me. Now
that DOMRectReadOnly is a concrete class with members, I wanted to avoid
wasting them. However, the spec is unclear as to whether a DOMQuad's bound's
should be live -- that is because DOMQuad exposes DOMPoint, we can set its
points after retrieving a QuadBounds object. Our current code is live, setting
the points changes the QuadBounds. Chromium's current behavior is to never
update the QuadBounds object. I've left our behavior untouched in this patch
(and waste 4 doubles per QuadBounds object), but I am intending to file a bug
to understand what the intent of the spec is. I wonder if the author intended
the points to be DOMPointReadOnly instead. If so, we could simplify the
DOMRectReadOnly code and get rid of the virtual getters, which would be nice.
I also wasn't thrilled to put the DOMMatrix setters on the DOMMatrixReadOnly
class, but for brevity and simplicity of implementation, I've made them
public. I briefly considered making the setters protected on the ReadOnly
version of the class, but I'm not convinced that having to explicitly make
them public on the derived class is worth the extra copies of the names.
MozReview-Commit-ID: CjdW4Nbnc6A
--HG--
extra : rebase_source : 44489693afebff571a415b487e29fa6153288421
2018-03-30 02:19:31 +03:00
|
|
|
GetHorizontalMinMax(&x1, &x2);
|
|
|
|
GetVerticalMinMax(&y1, &y2);
|
2018-05-24 02:56:22 +03:00
|
|
|
|
Bug 1186265 - Partially update DOMPoint, DOMQuad, DOMRect, DOMMatrix. r=bz
Some notes: this does not fully bring us to compliance to the current spec.
Instead, these are the fixes that I needed to make in order to make
css/geometry/interfaces.html pass with the DOMPoint changes in the previous
patches. I don't fully understand why that patch caused the test to fail the
way it did, but it ended up being easier to fix our code than understand why
the harness was falling over.
The DOMQuad::QuadBounds class was the source of some confusion for me. Now
that DOMRectReadOnly is a concrete class with members, I wanted to avoid
wasting them. However, the spec is unclear as to whether a DOMQuad's bound's
should be live -- that is because DOMQuad exposes DOMPoint, we can set its
points after retrieving a QuadBounds object. Our current code is live, setting
the points changes the QuadBounds. Chromium's current behavior is to never
update the QuadBounds object. I've left our behavior untouched in this patch
(and waste 4 doubles per QuadBounds object), but I am intending to file a bug
to understand what the intent of the spec is. I wonder if the author intended
the points to be DOMPointReadOnly instead. If so, we could simplify the
DOMRectReadOnly code and get rid of the virtual getters, which would be nice.
I also wasn't thrilled to put the DOMMatrix setters on the DOMMatrixReadOnly
class, but for brevity and simplicity of implementation, I've made them
public. I briefly considered making the setters protected on the ReadOnly
version of the class, but I'm not convinced that having to explicitly make
them public on the derived class is worth the extra copies of the names.
MozReview-Commit-ID: CjdW4Nbnc6A
--HG--
extra : rebase_source : 44489693afebff571a415b487e29fa6153288421
2018-03-30 02:19:31 +03:00
|
|
|
RefPtr<DOMRectReadOnly> rval = new DOMRectReadOnly(GetParentObject(),
|
|
|
|
x1, y1, x2 - x1, y2 - y1);
|
|
|
|
return rval.forget();
|
2018-05-24 02:56:22 +03:00
|
|
|
}
|
2018-05-24 02:56:22 +03:00
|
|
|
|
|
|
|
void
|
|
|
|
DOMQuad::ToJSON(DOMQuadJSON& aInit)
|
|
|
|
{
|
|
|
|
aInit.mP1.Construct(RefPtr<DOMPoint>(P1()).forget());
|
|
|
|
aInit.mP2.Construct(RefPtr<DOMPoint>(P2()).forget());
|
|
|
|
aInit.mP3.Construct(RefPtr<DOMPoint>(P3()).forget());
|
|
|
|
aInit.mP4.Construct(RefPtr<DOMPoint>(P4()).forget());
|
|
|
|
}
|