It's not obvious that it does this (unless you read the comment or the code), and we don't gain much by doing it.
Also we need to split it up for the next patch in this bug.
Without this patch, patch 2 will cause assertions since
nsFrame::DestroyFrom calls nsFrame::HasCSSAnimations (at a time when the
child frame has been destroyed), which calls into the code modified in
patch 2 to call GetStyleFrame.
--HG--
extra : commitid : EkhtcNIf7ye
This restores the quirky behavior for text inputs, which was removed by
patch 2, but only halfway (for width but not max-width), which matches
Chromium and Edge.
--HG--
extra : commitid : 7uk3XdYc1LC
This just reorders the if-else chain to change which conditions are
tested first. Prior to patch 1, the order didn't matter, but with patch
1, the order does matter, and the order that we happened to have was the
opposite of the one that matches Chromium and Edge.
--HG--
extra : commitid : 6sFft3gnM2g
This reduces the set of elements to which this quirky behavior applies.
This matches the behavior of Chromium and Edge.
--HG--
extra : commitid : 9qz7ODJhNzS
This (modulo changes in later patches) matches the behavior of Chromium
and Edge. It increases the set of elements to which this quirky
behavior applies.
--HG--
extra : commitid : 4nWEgnUB0rt
Displayport margins change by small amounts on almost every single scroll. We do not want to update image visibility nearly that often.
As the comment, and the original bug (bug 1169881) suggest this is only meant to catch rather large changes in display ports as we already have means to trigger an image visibility update via a scroll position change and via any style or layout flush.
Even though the content of the root scroll frame is the root element, the primary frame of the root element is never the root scroll frame. This is even true if the normal primary frame of the root element is not created (say because it is display: none). Leaving the primary frame of the root element to be null even though there are frames (the root scroll frame, and the canvas frame) that have the root element as their content.
This behaviour is more consistent by not ignoring a root scroll frame when it exists.
Instead do it when we first encounter the root scroll frame.
Doing this goes back to bug 635053, where we did it because fixed position items weren't getting included. However in bug 974643 we learned that this was wrong. Displayports aren't relevant to fixed pos content, displayports are only relevant to scrolled content. And we set the dirty rects of fixed pos content specially. The only other thing that should be affected is scrollbars, and we already carefully set their dirty rects too.
Temporarily rename GetDisplayPort to GetDisplayPortRelativeToScrollPort for the duration of this patchset.
This means that every caller of GetDisplayPort is guaranteed to be touched by this patchset (assuming it compiles), and thus each call site can be checked in review to make sure it is relative to the correct coordinate system.
This makes the one caller that needs the displayport rect have to ask for it seperately.
The reason for this is later in the patch series we need to add "RelativeToScrollFrame/Port" to all displayport getters, but there is no semantically good way to do that to the name GetOrMaybeCreateDisplayPort.
This makes the one caller that needs the displayport rect have to ask for it seperately.
The reason for this is later in the patch series we need to add "RelativeToScrollFrame/Port" to all displayport getters, but there is no semantically good way to do that to the name ViewportHasDisplayPort.
XUL documents don't have a root scroll frame, so this would early return and prevent any of the tiling and max texture size code from running.
The root element of XUL documents likely only ever has zero-margin displayports, and they are not scrollable, so it may not be important.
This makes it clearer whether we're just checking if a displayport exists,
or we're actually consuming its value.
--HG--
extra : source : 70bb222e860669a6cf6e803dbd57f088ca4fbc04
AutoTextRun now only needs a DrawTarget instead of an nsRenderingContext, and
similar nsRenderingContext/gfxContext-to-DrawTarget replacements can be
propagated a long way up the call graph. This patch replaces 93 occurrences of
nsRenderingContext and 135 occurrences of gfxContext with DrawTarget; that's
13% of them.
The patch is mostly plumbing changes. A couple of not-entirely-plumbing
changes:
- It adds a comment about the null check in
gfxGlyphExtents::GetTightGlyphExtentsAppUnits().
- A couple of functions simply had an unused gfxContext or nsRenderingContext
parameter removed, e.g. SetLineBreaks().
--HG--
extra : rebase_source : 8f56994bb4d254a86788b17ab2864ebc758a7e6b
A clear separation is introduced between paths that deal with a root
document resolution (at the process boundary in e10s setups) and paths
that deal with a non-root document resolution (elsewhere in Layout code).
This allows both code paths to run on all platforms.
--HG--
extra : source : 22bf09630803392dba3052a3f79691475af0c5e2
This requires adding a new overloading of LayoutDevicePixel::ToAppUnits and a
new PixelCastJustification: LayoutDeviceIsParentLayerForRCDRSF.
--HG--
extra : rebase_source : b6d044619918818815b40c1173aa4e0551db28a1
The only reason we had this in the scrollframe at all was so that it could be
saved/restored as part of the frame state when leaving a page and then going
back to it. However we can accomplish this by just reading/writing the resolution
from/to the presshell instead, so there's no need to keep a second copy of it.
--HG--
extra : commitid : J4QBfG2GGjn
The casts in nsCSSProps.cpp (defining kBoxSizingKTable) and in
nsComputedDOMStyle::DoGetBoxSizing (using
nsCSSProps::ValueToKeywordEnum) are a little bit annoying, though aren't
a net reduction in typesafety.
The casts in nsRuleNode.cpp (SetDiscrete) are a little more annoying,
though the change in this patch should be sufficient for converting all
properties -- but that may also mean reducing typesafety a bit for all
properties.
I'd like to find something better to do about them, but I think I'm ok
landing this before doing that. Bug 1224918 covers doing better.
--HG--
extra : commitid : GEVyZB5b23F
ForceInside shifts the rect first, and then clamps if needed. So the displayport doesn't get shrunk unnecessarily.
Bug 1191539 fixed this bug by applying ForceInside to the screen rect of the display port, which happens before the incorrect Intersect call.
It's better to remove the Intersect call and just do ForceInside once at the end to the final display port rect.
Bug 957668 introduced this bug by using Intersect instead of ForceInside when copying the code from AsyncPanZoomController::CalculatePendingDisplayPort when creating the code that computed a displayport rect from displayport margins.
The displayport was accidentally being calculated as too large. This was
leading to a large number of tiles existing at once, causing very high
memory usage.
The patch renames the existing functions (GetBounds(), GetClientBounds(), etc)
by adding an |Untyped| suffix. It then adds typed equivalents, and uses those
typed equivalents in all the call sites where it's easy to do so. The trickier
remaining call sites are converted to use the Untyped-suffix version.
--HG--
extra : rebase_source : 6bfb15bfc4698e2eba7d4db55497299d3dffcd51
We may want to do this for fixed pos frames in all documents (not just root documents). However, this patch only maintains the previous behaviour on purpose.
Instead of returning the root scroll frame if we encountered the root frame (which is the parent of the root scroll frame).
This allows the use of GetNearestScrollableFrame to walk up the frame tree without getting into a infinite loop going from root scroll frame to root frame and back.
This regresses bug 1105823 in that fixed pos frames will no longer find the root scroll frame of their document. The next patch will fix that.
The only other type of frame that will be affected when calling GetNearestScrollableFrame are viewport (root) frames. However, the only user of SCROLLABLE_ALWAYS_MATCH_ROOT (APZCCallbackHelper) calls GetNearestScrollableFrame on the result of a hit test on a display list. Viewport frames never create any display items whose HitTest function could return the viewport frame.
SCROLLABLE_ALWAYS_MATCH_ROOT should take precendence over SCROLLABLE_ONLY_ASYNC_SCROLLABLE as if we fail to find the root scroll frame we will have no usable scroll frame at all.
Removing the "stop at ancestor" parameter from functions that compute AGR meant that nsLayoutUtils::GetAnimatedGeometryRootFor could no longer pass the display item's reference frame as the "stop at ancestor" which meant that the AGR could cross the reference frame for the item, which we don't want. So we make transformed frames into AGRs.
This makes the computation of display items whose frames are transformed tricky. We need the AGR of the transform item to be the ancestor AGR, not the underlying frame of the transform item (which is now an AGR). So we modify nsLayoutUtils::GetAnimatedGeometryRootFor to handle this. (The patch from bug 1205087 didn't suffer from this problem because it special cased the computation of the AGR of transform items. Leaving anybody who called nsLayoutUtils::GetAnimatedGeometryRootFor to get the wrong result.)
The computation of the AGR for scroll metadata in ContainerState::ProcessDisplayItems specifically bypassed nsLayoutUtils::GetAnimatedGeometryRootFor to avoid it's special processing of fixed background items. However we do want the AGR for scroll metadata to do this special processing of transform items. So we add a flag to bypass the fixed background behaviour and use it for the scroll metadata AGR.
This removes the "aStopAtAncestor" argument to agr computing functions. In most cases an AGR was passed for the stop at ancestor, so we'd stop at it anyway since it was an AGR. Most of the remaining cases the root reference frame was passed. And in a few cases something else was passed, which we probably don't want (returning something that isn't an AGR and isn't the root reference frame as an AGR).
The ShouldFixToViewport case is a little tricky. We want to get the AGR of the nearest viewport frame, but only if we don't have to cross our root reference frame to get it. This happens in practice for example when a select dropdown has background-attachment: fixed inside it.
Except for the ShouldFixToViewport bit, this patch is a subset of part 3 in bug 1205087 (which has more changes, and has been temporarily backed out, the remaining bits can hopefully land soon).
The ShouldFixToViewport part is by Timothy Nikkel <tnikkel@gmail.com>
The bulk of this commit was generated with a script, executed at the top
level of a typical source code checkout. The only non-machine-generated
part was modifying MFBT's moz.build to reflect the new naming.
CLOSED TREE makes big refactorings like this a piece of cake.
# The main substitution.
find . -name '*.cpp' -o -name '*.cc' -o -name '*.h' -o -name '*.mm' -o -name '*.idl'| \
xargs perl -p -i -e '
s/nsRefPtr\.h/RefPtr\.h/g; # handle includes
s/nsRefPtr ?</RefPtr</g; # handle declarations and variables
'
# Handle a special friend declaration in gfx/layers/AtomicRefCountedWithFinalize.h.
perl -p -i -e 's/::nsRefPtr;/::RefPtr;/' gfx/layers/AtomicRefCountedWithFinalize.h
# Handle nsRefPtr.h itself, a couple places that define constructors
# from nsRefPtr, and code generators specially. We do this here, rather
# than indiscriminantly s/nsRefPtr/RefPtr/, because that would rename
# things like nsRefPtrHashtable.
perl -p -i -e 's/nsRefPtr/RefPtr/g' \
mfbt/nsRefPtr.h \
xpcom/glue/nsCOMPtr.h \
xpcom/base/OwningNonNull.h \
ipc/ipdl/ipdl/lower.py \
ipc/ipdl/ipdl/builtin.py \
dom/bindings/Codegen.py \
python/lldbutils/lldbutils/utils.py
# In our indiscriminate substitution above, we renamed
# nsRefPtrGetterAddRefs, the class behind getter_AddRefs. Fix that up.
find . -name '*.cpp' -o -name '*.h' -o -name '*.idl' | \
xargs perl -p -i -e 's/nsRefPtrGetterAddRefs/RefPtrGetterAddRefs/g'
if [ -d .git ]; then
git mv mfbt/nsRefPtr.h mfbt/RefPtr.h
else
hg mv mfbt/nsRefPtr.h mfbt/RefPtr.h
fi
--HG--
rename : mfbt/nsRefPtr.h => mfbt/RefPtr.h
This commit was generated using the following script, executed at the
top level of a typical source code checkout.
# Don't modify select files in mfbt/ because it's not worth trying to
# tease out the dependencies currently.
#
# Don't modify anything in media/gmp-clearkey/0.1/ because those files
# use their own RefPtr, defined in their own RefCounted.h.
find . -name '*.cpp' -o -name '*.h' -o -name '*.mm' -o -name '*.idl'| \
grep -v 'mfbt/RefPtr.h' | \
grep -v 'mfbt/nsRefPtr.h' | \
grep -v 'mfbt/RefCounted.h' | \
grep -v 'media/gmp-clearkey/0.1/' | \
xargs perl -p -i -e '
s/mozilla::RefPtr/nsRefPtr/g; # handle declarations in headers
s/\bRefPtr</nsRefPtr</g; # handle local variables in functions
s#mozilla/RefPtr.h#mozilla/nsRefPtr.h#; # handle #includes
s#mfbt/RefPtr.h#mfbt/nsRefPtr.h#; # handle strange #includes
'
# |using mozilla::RefPtr;| is OK; |using nsRefPtr;| is invalid syntax.
find . -name '*.cpp' -o -name '*.mm' | xargs sed -i -e '/using nsRefPtr/d'
# RefPtr.h used |byRef| for dealing with COM-style outparams.
# nsRefPtr.h uses |getter_AddRefs|.
# Fixup that mismatch.
find . -name '*.cpp' -o -name '*.h'| \
xargs perl -p -i -e 's/byRef/getter_AddRefs/g'
For root scroll frames we need information about the async scrolling (or lack thereof) of the scroll frame before we get to ScrollFrameHelper::BuildDisplayList for the scroll frame. We need it in nsLayoutUtils::PaintFrame and nsSubdocumentFrame::BuildDisplayList. So we factor out all the code responsible for async scrolling decisions into one function we can call from all three places.
The conversion is as follows:
- GraphicsFilter::FILTER_NEAREST == gfx::Filter::POINT
- GraphicsFilter::FILTER_GOOD == gfx::Filter::GOOD
- GraphicsFilter::FILTER_BEST == gfx::Filter::LINEAR
Also typedef GraphicsFilter to gfx::Filter; this will be removed in the next
patch.
These changes mean ToFilter() and ThebesFilter() are no longer needed.
The change breaks some scenarios with APZ scrolling, in particular the code
that layerizes the scroll handoff chain for deeply nested scrollable frames.
--HG--
extra : commitid : KeQX4HyPKXd
In various places SetColor() gets passed an nscolor. These are converted
(either implicitly or explicitly) to a gfxRBGA, and then to a gfx::Color.
This patch changes all these cases to avoid the middle step, by (a)
constructing a gfx::Color directly instead of an nscolor, or (b) by converting
an nscolor with Color::FromABGR().
--HG--
extra : rebase_source : ae423a422b37ada8ca0cb6f130350b4a71d58fc4
gfxIntSize is just a typedef of gfx::IntSize, so this is very mechanical. The
only tricky part is deciding for each occurrence whether to replace it with
IntSize, gfx::IntSize or mozilla::gfx::IntSize; in all cases I went with the
shortest one that worked given the existing "using namespace" declarations.
--HG--
extra : rebase_source : 67fd15f87222b16defa70ef795c6d77dfacf1c36
Remove WrapPreserve3DList() and replaced it by creating a
nsDisplayTransform item for each transformed frame.
- Add an additional item for each top frame extending 3D context to
separate consequence contexts.
- Effective transform of a layer is the accumulation of ancestors in
the same 3D context.
- The layers creating new context and extended by children need a
temporary buffer if it's effective transform is not 2D.
- Clip rects are accumulated along the context chain.
- Visible rects of items are computed from dirty regions of the frame
creating the context and accumulated transforms.
- Bounds of items are computed from accumulated transforms and
accumulated bounds of the descent frames.
- Backface hidden is handled by compositor and BasicLayerManager.
--HG--
extra : rebase_source : 1a894b057a117a8520898c9f83308d92c122b180
Remove WrapPreserve3DList() and replaced it by creating a
nsDisplayTransform item for each transformed frame.
- Add an additional item for each top frame extending 3D context to
separate consequence contexts.
- Effective transform of a layer is the accumulation of ancestors in
the same 3D context.
- The layers creating new context and extended by children need a
temporary buffer if it's effective transform is not 2D.
- Clip rects are accumulated along the context chain.
- Visible rects of items are computed from dirty regions of the frame
creating the context and accumulated transforms.
- Bounds of items are computed from accumulated transforms and
accumulated bounds of the descent frames.
- Backface hidden is handled by compositor and BasicLayerManager.
The special-case was added back when the Fennec dynamic toolbar showing/hiding
behaviour didn't resize the content area. As of bug 1180295 that is no longer
the case, and showing/hiding the dynamic toolbar *does* resize the content area.
Therefore the widget bounds always represents the actual content area and can
be used directly as the composition bounds.
In addition, the special-case code relied on a particular quirk of the Fennec
CSS viewport determination code which was removed in bug 1180267. The quirk was
that the CSS viewport height was always set such that it would cover the
available screen height when the page was zoomed out to the minimum allowed
zoom. This behaviour was technically incorrect as it would ignore any height
properties provided in the meta-viewport tag. Now that this quirk has been
removed, the special-case code breaks because the root frame's height is
independent of the screen height and can result in an incorrect composition
bounds.
--HG--
extra : commitid : 69FDhj50WEN
- Update callsites of Matrix4x4::TransformBounds to use
Matrix4x4::TransformAndClipBounds.
--HG--
extra : rebase_source : a1aa889af56e404b7ca5c7125021171e67a0b8bf
AnimationCollection::HasAnimationOfProperty uses IsFinishedTransition to filter
out transitions that should otherwise be ignored. This is used in the following
places:
1. nsLayoutUtils::HasAnimations
The is only used by nsIFrame::BuildDisplayListForStackingContext to see if
there are any opacity animations
For this case, simply returning *current* animations would be sufficient
(since finished but filling animations should have already filled in the
display opacity)
2. CommonAnimationManager::GetAnimationsForCompositor
This should really only return *current* animations--that is, animations that
are running or scheduled to run. Finished animations never run on the
compositor. Indeed, only *playing* animations run on the compositor but, as
we will see in some of the cases below, it is sometimes useful to know that
an animation *will* run on the compositor in the near future (e.g. so we can
pre-render content).
The places where GetAnimationsForCompositor is used are:
- When building layers to add animations to layers in nsDisplayList--in this
case we skip any animations that aren't playing so if
GetAnimationsForCompositor only returned current animations that would be
more than sufficient.
- In nsLayoutUtils::HasAnimationsForCompositor. This in turn is used:
- In ChooseScaleAndSetTransform to see if the transform is being animated
on the compositor. If so, it calls
nsLayoutUtils::ComputeSuitableScaleForAnimation (which also calls
GetAnimationsForCompositor) and passes the result to
GetMinAndMaxScaleForAnimationProperty which we have already adjusted in
part 4 of this patch series to only deal with *relevant* animations
Relevant animations include both current animations and in effect
animations but we don't run forwards-filling animations on the compositor
so GetAnimationsForCompositor should NOT return them. Current animations
should be enough. In fact, playing animations should be enough but we
might want to pre-render layers at a suitable size during their delay
phase so returning current animations is probably ok.
- In nsDisplayListBuilder::MarkOutOfFlowFrameForDisplay to add a fuzz
factor to the overflow rect for frames undergoing a transform animation
on the compositor. In this case too current animations should be
sufficient.
- In nsDisplayOpacity::NeedsActiveLayer to say "yes" if we are animating
opacity on the compositor. Presumably in this case it would be good to
say "yes" if the animation is in the delay phase too (as it currently
does). After the animation is finished, we should drop the layer, i.e.
current animations should be sufficient.
- In nsDisplayTransform::ShouldPrerenderTransformedContent. As with
nsDisplayOpacity::NeedsActiveLayer, we only need to pre-render
transformed content for animations that are current.
- In nsDisplayTransform::GetLayerState. As with
nsDisplayOpacity::NeedsActiveLayer, we only need to return active here
for current animations.
- In nsIFrame::IsTransformed. Here we test the display style to see if
there is a transform and also check if transform is being animated on the
compositor. As a result, we really only need HasAnimationsForCompositor
to return true for animations that are playing--otherwise the display
style will tell us if we're transformed or not. Returning true for all
current compositor animations (which is a superset of playing), however,
should not cause problems (we already return true for even more than
that).
- In nsIFrame::HasOpacityInternal which is much the same as
nsIFrame::IsTransformed and hence current should be fine.
3. AnimationCollection::CanThrottleAnimation
Here, HasAnimationOfProperty is used when looking for animations that would
disqualify us from throttling the animation by having an out-of-date layer
generation or being a transform animation that affects scroll and so requires
that we do the occasional main thread sample to update scrollbars.
It would seem like current animations are enough here too. One interesting
case is where we *had* a compositor animation but it has finished or been
cancelled. In that case, the animation won't be current and we should not
throttle the animation since we need to take it off its layer.
It turns out checking for current animations is still ok in this case too.
The reasoning is as follows:
- If the animation is newly-finished, we'll pick that up in
Animation::CanThrottle and return false then.
- If the animation is newly-idle then there are two cases:
If the cancelled animation was the only compositor animation then
AnimationCollection::CanPerformOnCompositorThread will notice that there
are no playing compositor animations and return false and
AnimationCollection::CanThrottleAnimation will never be called.
If there are other compositor animations running, then
AnimationCollection::CanThrottleAnimation will still return false because
whatever cancelled the animation will update the animation generation and
we'll notice the mismatch between the layer animation generation and the
animation generation on the collection.
Based on the above analysis it appears that making
AnimationCollection::HasAnimationOfProperty return only current animations (and
simulatneously renaming it to HasCurrentAnimationOfProperty) is safe. Indeed, in
effect, we already do this for transitions but not for animations. This patch
generalizes this behavior to all animations.
This patch also updates test_animations_omta.html since it was incorrectly
testing that a finished opacity animation was still running on the compositor.
Finished animations should not run on the compositor and the changes in this
patch cause that to happen. The reason we don't just update this test to check
for RunningOn.MainThread is that for opacity animations, unlike transform
animations, we can't detect if an opacity on a layer was set by animation or
not. As a result, for opacity animations we typically test the opacity on
either the main thread or compositor in order to allow for the case where an
animation-set opacity is still lingering on the compositor.
GetMinAndMaxScaleForAnimationProperty in nsLayoutUtils uses IsFinishedTransition
to ignore finished transitions since they should not have any effect on current
or future scale values. We can generalize this, however, and say we are only
interested in animations that are *either*:
a) running or scheduled to run in the future, i.e. "current", OR
b) applying a value, including a finished animation with a forwards fill,
i.e. "in effect"
Elsewhere, animations that fulfil *either* of this conditions are referred to as
"relevant animations" so we can simply test for relevance in this function.
The bulk of this commit was generated by running:
run-clang-tidy.py \
-checks='-*,llvm-namespace-comment' \
-header-filter=^/.../mozilla-central/.* \
-fix
The patch works by not handling transform:none specially at all, which
will lead to a scale of 1 (instead of the current 0).
This is the patch that actually fixes the original problem reported in
bug 1122526. This patch also fixes bug 1165196.
This field tells us if this frame metrics should be considered the root APZC for its layers id. Without this there doesn't seem to be a way to compute this from just the layers tree.
We do this by looking at the layer tree after it has been made to see if the root metrics are in it already.
This is needed to ensure that there is always a root AZPC in a process.
ClampRectToScrollFrames generalizes IsRectVisibleInScrollFrames by
returning the clamped rect in scroll frames. IsRectVisibleInScrollFrames
could be implemented by checking whether the clamped rect is empty or
not.
This fixes bug 1153539 with the Firefox download arrow being pixellated
(verified by testing locally).
I also confirmed what happens on a flame device with the transform
unlocking the Firefox OS homescreen (bug 945082 / bug 972310). For that
transform (which had a maximum scale of 2), I see four calls to
GetSuitableScale:
GetSuitableScale: aMaxScale=2.000000, displayVisibleRatio=1.000000
GetSuitableScale: aMaxScale=2.000000, displayVisibleRatio=1.000586
GetSuitableScale: aMaxScale=2.000000, displayVisibleRatio=1.000000
GetSuitableScale: aMaxScale=2.000000, displayVisibleRatio=1.000586
(Presumably the first and third are for width, and the second and fourth
are for height.) I believe this shows that bug 972310 will remain fixed
with this patch.
I chose to use the pres context's visible area rather than the screen
size because it seemed more appropriate, and also because (if memory
serves correctly) it's much cheaper to get.
Cameron McCormack
Wes Kocher
David Anderson
L. David Baron
Boris Chiou
Aidin Gharibnavaz
Timothy Nikkel
Kartikaya Gupta
Robert O'Callahan
Birunthan Mohanathas
Phil Ringnalda
Kyle Huey
Ting-Yu Lin
CJKu
Xidorn Quan
Randall Barker
Nigel Babu
Daniel Holbert
Tooru Fujisawa
Nicholas Nethercote
Eric Rahm
Morris Tseng
Botond Ballo
Lee Salzman
Chris Peterson
Brian Birtles
Boris Zbarsky
Matt Woodrow
Jeff Gilbert
Mason Chang
Tobias Schneider
Bas Schouten
Jamie Nicol
Jonathan Kew
Mats Palmgren
Milan Sreckovic
James Willcox
Nathan Froyd
Benoit Girard
James Kitchener
Carsten "Tomcat" Book
Markus Stange
Thinker K.F. Li
Olli Pettay
Robert Longson
Kearwood (Kip) Gilbert
Masayuki Nakano
Jonathan Watt
Seth Fowler
Kyle
Juan Gomez
Ryan VanderMeulen
Kyle Zentner
Danilo Cesar Lemes de Paula