Summary:
We were always getting LEFT explicitly, and, due to RTL support, we
should be asking for START instead.
Reviewed By: sriramramani
Differential Revision: D3836816
Summary:
@public
Setting the line height with the help of Android-provided StaticLayout is incorrect. A
simple example app will display the following when `setLineSpacing(50.f, 0.f)`
is set: {F62987699}. You'll notice that the height of the first line is a few
pixels shorter than the other lines.
So we use a custom LineHeightSpan instead, which needs to be applied to the text
itself, and no height-related attributes need to be set on the TextView itself.
Reviewed By: lexs
Differential Revision: D3841658
Summary:
Fix TextInput padding on Nodes. We used to not call super and used
to manually do the setting of padding. This stops us from running the same
logic that non-Nodes runs (we bypassed it), so this fixes it.
Reviewed By: astreet
Differential Revision: D3825227
Summary:
Due to the RTL implementation, the ViewProps spacing array has START
and END, whereas Nodes should deal with RIGHT and LEFT directly (just like
non-Nodes does). This is the same implementation in use by non-Nodes.
Reviewed By: astreet
Differential Revision: D3809028
Summary:
Nodes historically had two image implementations -
DrawImageWithDrawee and DrawImageWithPipeline. The drawee implementation
was the default (per request of the Fresco team). At this point, there is
no point of having two (especially since updates to one need to be made to
the other), so this patch removes pipeline.
Reviewed By: sriramramani
Differential Revision: D3755523
Summary:
Nodes would typically clip its images, and then Fresco would then
re-clip as part of ScaleTypeDrawable - in addition to being unnecessary,
it's also incorrect, beacuse it causes the image to be smaller than it
should be.
Reviewed By: sriramramani
Differential Revision: D3754778
Summary:
@public
Setting the line height with the help of Android-provided StaticLayout is incorrect. A
simple example app will display the following when `setLineSpacing(50.f, 0.f)`
is set: {F62987699}. You'll notice that the height of the first line is a few
pixels shorter than the other lines.
So we use a custom LineHeightSpan instead, which needs to be applied to the text
itself, and no height-related attributes need to be set on the TextView itself.
Reviewed By: lexs
Differential Revision: D3751097
Summary:
@public
Setting the line height with the help of Android-provided StaticLayout is incorrect. A
simple example app will display the following when `setLineSpacing(50.f, 0.f)`
is set: {F62987699}. You'll notice that the height of the first line is a few
pixels shorter than the other lines.
So we use a custom LineHeightSpan instead, which needs to be applied to the text
itself, and no height-related attributes need to be set on the TextView itself.
Reviewed By: lexs
Differential Revision: D3751097
Summary:
This is just a minor cleanup, use constants for the LEFT
and RIGHT alignments, since they are hide.
Reviewed By: sriramramani
Differential Revision: D3746019
Summary: Adds a flag that can be set in FlatViewGroup to see known performance issues in Nodes objects. This is mostly useful in internal development of Nodes, and will be a dead code path when not set.
Reviewed By: ahmedre
Differential Revision: D3732675
Summary: Node region bounds are assumed to equal the underlying node bounds. In the case of hit slop, these need to be abstracted.
Reviewed By: ahmedre
Differential Revision: D3713430
Summary:
This is minor, but for our use case a SparseArray is going to be faster as long as we have less than 10,000 clipped subviews, and will also use much less memory.
Faster because of the boxing, unboxing and hash caching; less memory as it is two arrays instead of the object overhead of the HashMap.
Reviewed By: ahmedre
Differential Revision: D3704326
Summary: Previously, the first time we collected a draw view, we would make a clone, even though the draw view had never been mutated. This refactors draw view to avoid this extra allocate.
Reviewed By: ahmedre
Differential Revision: D3719056
Summary:
In Nodes, there were certain cases where text wasn't drawn due to an
optimization that skipped measuring because the size was already known.
Reviewed By: emilsjolander
Differential Revision: D3713841
Summary:
For Nodes that don't mount to views, measureLayout wasn't working
because our calls for getting the width and height would return the view delta
bounds, which won't exist for Nodes. #accept2ship
Differential Revision: D3707880
Summary:
Nodes currently doesn't ask Fresco to resize images, but this is
potentially problematic (ex having a camera photo of 6000x1500 causes a crash
due to the massive size).
Differential Revision: D3687944
Summary: Adds support for horizontal clipping, though the FlatViewGroup needs to be made aware still of which it is.
Reviewed By: ahmedre
Differential Revision: D3673501
Summary: This optimizes node region searches in clipping cases, and does position calculation for drawCommands off of the UI thread.
Reviewed By: ahmedre
Differential Revision: D3665301
Summary: Add jni bindings for csslayout. First step in many of removing LayoutEngine.java and performing all layout in native.
Reviewed By: lucasr
Differential Revision: D3648793
Summary:
Use ImageRequestBuilder directly in Nodes, just like we do for
non-Nodes.
Reviewed By: sriramramani
Differential Revision:
D3660610
Ninja: Sandcastle is broken. 25 denizens of the Facebook republic are affected by this unrelated issue today.
Summary: Add directional aware clipping to DrawCommandManager. Currently not attached to FlatViewGroup logic, with the plan to keep this unattached until we are clipping the way we want to in the final state.
Reviewed By: ahmedre
Differential Revision: D3622253
Summary: @public Make UIOperation public so that custom implementations can expose instances of it.
Reviewed By: ahmedre
Differential Revision: D3618197
Summary:
Support rounded clipping in Nodes. Before, if a view had
a radius and had overflow of hidden, its children could still draw
outside of it (specifically, in the area between the rounded rect
and square rect) - this is due to the fact that clipping is, by
default, rectangular. This patch supports this type of rounded
clipping.
Differential Revision: D3634861
Summary: Previously, we had no information about the positioning of the view until after we had attached it. We have the position information attached to the shadow node, but this attaches it to the DrawView as well. It also removes the need for AbstractClippingDrawCommand.
Reviewed By: ahmedre
Differential Revision: D3609092
Summary: @public Change the textalign setter to support RTL. In order to support text alignment according to layout style, move the textalign setter bridge function from ReactTextViewManager.java to ReactTextShadowNode.java and calculate it correctly on RCTTextUpdate.
Reviewed By: dmmiller
Differential Revision: D3597494
Summary:
This patch fixes measureInWindow for Nodes backed by Views.
Whereas the intention was to call the super implementation when we have a
Node backed by a View, we instead called the super implementation of
measure, which doesn't measure relative to window.
Differential Revision: D3607890
Summary:
Currently we have race conditions in DrawView related to isViewGroupClipped, where we create a copy of the DrawView before we update the clipping state, and think the view is unclipped in the next iteration.
Also we are sometimes creating a DrawView with a reactTag of 0.
This fixes both, and is part of the upcoming DrawView bounds change, but is a separate issue that is live in current source.
Reviewed By: ahmedre
Differential Revision: D3598499
Summary:
@public
This is pure cleanup so that we can make sure that all events are living in the same time space (currently nano seconds).
Reviewed By: foghina
Differential Revision: D3593884
Summary:
View the comment thread for discussion:
https://www.facebook.com/groups/1505872839725322/permalink/1630102823968989
Our current behaviour of add then immediately remove if a view is clipped pretty much guarantees that we kill network requests for images in feed. We have a better fix for that in the pipeline, but this is a low risk fix in the meantime.
Reviewed By: ahmedre
Differential Revision: D3597785
Summary:
This PR was split from a commit originally in #8619. /cc dmmiller
When an inline image was larger than the specified line height,
the image would be clipped. This changes the behavior so
that the line height is changed to make room for the inline
image. This is consistent with the behavior of RN for iOS.
Here's how the change works.
ReactTextView now receives its line height from the layout thread
rather than directly from JavaScript.
The reason is that the layout thread may pick a different line height.
In the case that the tallest inline image is larger than the line
height supplied by JavaScript, we want to use that image's height as
the line height rather than the supplied line height.
Also fixed a bug where the image, which is supposed to be baseline
aligned, would be positioned at the wrong y location. To fix this,
we use `y` (the baseline) in the `draw` method rather than trying
to calculate the baseline from `bottom`. For more information
see https://code.google.com/p/andro
Closes https://github.com/facebook/react-native/pull/8907
Differential Revision: D3592781
Pulled By: dmmiller
Summary:
DrawImageWithDrawee has caused NPEs when using Nodes in various cases
in RNFeed. This patch explicitly throws a RuntimeException, so that we can
debug as to whether this is coming from bad sources or a bad size for the
image.
Differential Revision: D3574998
Andrew Y. Chen
Ahmed El-Helw
Andrei Coman
Sriram Ramasubramanian
Seth Kirby
Emil Sjolander
Mengjue Wang
Dave Miller
Adam Comella