Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Component ratio support #62
There are several places where we can optimize to make Jasonette scroll smoothly.
One of those cases is handling component dimension. To understand why this is so, I need to discuss how this is implemented internally. You can skip this part and jump to the next "proposal" section if you're just curious about the proposed solution.
1. How app layout works
How Jasonette handles layout
All mobile devices implement some sort of "autolayout" features (both iOS and Android). This makes sure components without a dimension attribute will be automatically resized to "just work".
But sometimes the autolayout feature gets confused how exactly to lay them out. This is especially the case when you're loading an image. If you don't set the width and height directly on the image, Jasonette will try to figure it out AFTER the image has loaded by looking at the image file itself.
This normally does a good job but in some cases this resolution is visible and that's what makes it feel "jerky" when scrolling. Currently you can get around this if you use fixed width and height (must set both width and height)
How most native apps handle layout
Also note that this is not a "native vs. non-native" problem. Just take a look at a google search page for https://www.google.com/search?q=ios+scroll+jerky&oq=ios+scroll+&aqs=chrome.0.69i59j69i57j0l4.16386j0j7&sourceid=chrome&ie=UTF-8#q=ios+scroll+stutter This is a very common problem even among native ios developers.
And this is why a lot of apps have uniform components (Instagram used to only allow square images and many apps have fixed media sizes just to not worry about all the complexity that arise by allowing variable component sizes).
And even the apps that do have variable component sizes have to work hard to implement custom optimization logic for their apps. While difficult this is possible if you have a specific business logic because you can build your optimization logic around this assumption.
But the goal of Jasonette is to try to come up with a reusable approach to handling these things, so the optimization needs to be universal and shouldn't depend on a specific business logic.
We can get around a lot of layout performance issues by:
But in many cases we want to have variable sized components AND make it work. Like I mentioned in the previous section, this is not an easy task and there is no silver bullet approach to solving this in one fell swoop, so I think the best approach is to keep improving the most obvious use cases.
One such case is components where we know:
Here are some examples:
An image with width of
An image with width of
Because of the way components are implemented I think we can apply this not just to images but all components, which would improve the performance for this specific case.
If you have better ideas about the JSON syntax, or any other ideas, feel free to share.
I really like this @gliechtenstein, I also think that while we're at it (and if it's not too much trouble) we should be looking at image scaling:
Or negative (zoom out):
This was referenced
Jul 21, 2017
added a commit
Jul 21, 2017
Guys, please check out the ratio branch (Currently only on iOS)
I would appreciate it if someone could try it out and share feedback. I think this will improve rendering for situations mentioned above, but I don't personally have an example where this actually matters.
I will give it a try, some initial feedback on syntax:
But it would be useful maybe to also support in the syntax math equations to avoid having to make the ratio calculation because my use case where I do server-side templating is easy to come up with the image ratio is probably atypical - what would be more typical would be someone knowing the image actual dimensions (and not the ratio). My proposal would be supporting in ratio an actual ratio as in:
Probably that would make it easier to use the feature. Going one small step further, I would suggest since I can never remember anything, to put into the key name what the ratio direction is, as in:
As an aside, I found that the jumping around and resizing of images is far less noticeable on Android that iOS, no idea why, just the feedback I've seen.
Do you think this branch will address the timing issue where sometimes images get stretched improperly - ending up with the incorrect aspect ratio? It seems as though that's got to be some kind of timing because it's inconsistent and impossible to reproduce for you.
You can do
I am guessing this happens when you only specify just width or just height. Which means if you know the width and the ratio, or the height and the ratio, the stretch wouldn't happen. But this assumes that you know the ratio.
That said, I do think we need to fix that bug even if it happens occasionally. From my experience, a lot of bugs are symptoms of something more fundamental, so if you ever come across a case where this can be replicated with higher chance please share and I'll take a look.