I'm building an application using Sencha Touch that's targeting iPads. The only way to achieve a smooth animation that I know is to use -webkit-transform css property. That works for moving things around with translate3d and scaling them, however I'm looking to change elements' dimensions (width and height). Imagine an element that grows in size to accomodate for a new child - that's what I'm after
You won't have any luck with width and height, as any transitions for these properties won't be hardware accelerated. What you'll get instead in Safari is a jerky animation that isn't even scaled properly. In my tests, the browser would first transition the height, then the width would snap into place abruptly, or vice versa. If all you want to do is scale an element (change its dimensions) then you should us -webkit-transform: scale(x, y).
Related
I'm trying to create a 2D cross-platform game (primarily for android & ios in portrait mode, however compatibility with a tablet/desktop would be a bonus) and I'm trying to wrap my head around scaling of my sprites.
I've looked online, and I've ended up setting the following in my Project Settings > Stretch
'Mode' : 2D
'Aspect' : keep-height.
According to https://www.mydevice.io the viewport of my android phone is 360 x 640px (the standard 16:9 ratio for mobiles). But obviously phones/tablet screens come in all sorts of dimensions.
If I wanted to create a sprite with a width exactly 1/3rd of that of my screen/viewport, how should I go about doing this? Should I be creating multiple sprites of various dimensions (in say, GraphicsGale) to account for different screen sizes, or should I be purely doing this scaling in Godot?
I know there's a 'scale' property in Godot, but I can't see a way of setting my image width and height via pixels or by a percentage of the viewport.
Have you tried setting the sprite size depending on the viewport height and width ?
$sprite.size.x = get_viewport().size.x * 0.33
$sprite.size.y = get_viewport().size.y * 0.33
You can check out this reddit post if this is not working.
I've the following constraints which are working perfectly fine over Chrome in Desktop (simulating mobile resolution)
const constraints = {
audio: false,
video: {
width: screen.width,
height: screen.height
}
};
navigator.mediaDevices.getUserMedia(constraints).then(stream => {})
However when actually trying this on iPhone / Safari the camera doesn't respects this at all and gets super small or distorted - removing the width / height from the constraints makes it better ratio but not full screen at all, just centralized.
I've also tried with min / max constraints without lucky.
Is there any way to get this working on iPhones?
I have built a few AR Websites which are mobile first. When you request a resolution the web browser sees if the resolution exists, and if it doesn't it then decides if it should emulate the feed for you. Not all browsers do emulation (even though it is part of the spec). This is why it may work in some browsers and not others. Safari won't emulate the resolution you are asking for with the camera you have picked (I presume the front).
You can read more about this here (different problem, but provides a deeper explaination): Why the difference in native camera resolution -vs- getUserMedia on iPad / iOS?
Solution
The way I tackled this is:
Without canvas
Ask for a 720p feed, fallback to 480p feed if 720 gives an over-constrained error. This will work cross-browser.
Have a div element which is 100% width and height, fills the screen, and sets overlay to hidden.
Place the video element connected to the MediaStream inside, make it 100% height of the container. The parent div overlay hidden will in effect crop the sides. There will be no feed distortion.
With canvas
Do not show the video element, use a canvas as the video view. Make the canvas the same size as your screen or the same aspect ratio and use CSS to make it fill the screen (latter is more performant).
Calculate the top, left, width and height variables to draw the video in the canvas (make sure your calculation centers the video). Make sure you do a cover calculation vs fill. The aim is to crop the parts of the video which do not need to be shown (I.e. like the descriptions of various methods in https://css-tricks.com/almanac/properties/o/object-fit) . Example on how to draw video into a canvas here: http://html5doctor.com/video-canvas-magic/
This will give you the same effect of what you are looking for. Production examples of something similar.
https://www.maxfactor.com/vmua/
https://demo.holitionbeauty.com/
P.s. when I get time I can code an example, short on hours this week.
There are a couple of quirks on mobile gUM() you need to know about.
First, if the device is in portrait orientation things work weirdly. You need to swap the width and height. So, let's say you're on a 480x640 device (do those even exist? who cares? it's an example). To get the appropriate size video you need
const constraints = {
audio: false,
video: {
width: screen.height,
height: screen.width
}
};
I can't figure out exactly why it's like this. But it is. On iOS and Android devices.
Second, it's hard to get the cameras to deliver exactly the same resolution as the device screen size. I tweak the width and height to make them divisible by eight and I get a decent result.
Third, I figure the sizes I need by putting a <video ...> tag in my little web app with CSS that makes it fill the browser screen, then querying its size with
const rect = videoElement.getBoundingClientRect()
const width = rect.width > rect.height ? rect.width : rect.height
const height = rect.width > rect.height ? rect.height : rect.width
This makes the mobile browser do the work of figuring out what size you actually need, and adapts nicely to the browser's various toolbars.
Every time the window is sized from big:
http://res.cloudinary.com/liberationfront/image/upload/v1497626018/vb1_t29xlz.png
To small:
https://res.cloudinary.com/liberationfront/image/upload/v1497625905/vb2_gtmjrl.png
There is all of a sudden a gap.
The problem is likely that your images don't all have the exact same aspect ratio, so some of them end up a pixel taller than others in some cases. Then the floated columns don't clear properly.
You can either re-crop your images, which is a fragile solution since you then rely on all future images being perfectly cropped, or you can set your cards' height through CSS and let the images flow to fit. Often using background images gives much more flexibility.
I suggest looking into Bootstrap's responsive embed and setting your images as backgrounds on a child element. Create your own 1:1 class if needed.
I have been working on an iPad app that performs animations on very large images (full screen images that can be zoomed at 2x and still be retina quality). I have spent a lot of time getting smooth transitions when zooming and panning. When running the app on iOS7 however, the animations become really jerky (slow frame rate).
Further testing shows that it is the zoom animation that causes the problem (panning does not cause a problem). Interestingly, I have been able to fix it by setting the alpha of the image being scaled to 0.995 (instead of 1.0).
I have two questions
What has changed in iOS7 to make this happen?
Why does changing the opacity of the view make a difference?
Further information for the above questions:
Animation Setup
The animations are all pre-defined and are played upon user interaction. The animations are all a mix of pan and zoom. The animations are really simple:
[UIView animateWithDuration:animationDuration delay:animationDelay options:UIViewAnimationOptionCurveEaseInOut animations:^{
self.frame = nextFrame;
//...
} completion:^(BOOL finished) {
//...
}];
To fix the jerky animation, I set the alpha before the animation
self.alpha = 0.99;
Some interesting points:
Setting the alpha inside of the animation works as well
Setting the alpha back to 1.0 after the animation and then doing the reverse animation with a 1.0 alpha does not give a smooth reverse animation.
Opacity fix
I have previously used the opacity fix to make animations smooth when scaling and panning multiple images. For example, I had two large images panning and scaling at different speeds with one on top of the other. When a previously un-rendered part of the lower image (the image on the bottom) became visible, the animation would become jerky (panning as well as scaling). My thought for why alpha helps in this case is, if the top image has a bit of transparency, the bottom image must always be rendered, which means it can be cached before the animation takes place. This thought is backed by doing the reverse animation and not seeing the jerky animation. (I guess I would be interested to know if anyone has different thoughts on this as well).
Having said the above, I don't know how this would have an affect when there is just one image (as in the situation I am describing in my question). Particularly when after getting the jerky animation, the reverse animation is still jerky. Another point of difference between the two situations is that it is only scaling that causes the problem in the current issue, while in the double image issue it was panning as well as scaling.
I hope the above is clear - any insights appreciated.
Look at Group Opacity. iOS 7 has that turned ON by default and this changes the way views/layers are composited:
When the UIViewGroupOpacity key is not present, the default value is
now YES. The default was previously NO.
This means that subviews of a transparent view will first be
composited onto that transparent view, then the precomposited subtree
will be drawn as a whole onto the background. A NO setting results in
less expensive, but also less accurate, compositing: each view in the
transparent subtree is composited onto what’s underneath it, according
to the parent’s opacity, in the normal painter’s algorithm order.
(source: iOS7 Release Notes)
With this setting on, compositing - also during animations - is way more expensive.
Also, have a look at the CoreGraphics Instruments tool to check if you have lots of off-screen images compositing going on.
Are you having any sort of changes going on in the view being animated? That would trigger more discarding of the rendered layer image from the backing store.
How does Safari determine what size to output an svg in the following scenario;
SVG code
viewBox 0 0 800 800
height 100%
width 100%
css
svg width 100%
containing div width 60%
Safari outputs a much smaller svg than the 60% of screen, ok this is a bug. But what determines the size of this smaller svg, it has no connection to anything I can think of.
Just to give some background info. Safari needs both width and height in px for it to do what you want. % don-t work. But it does output the svg, and so it must make a decision somewhere about its size.
It's not a bug you're seeing. That's the correct behavior. The browser by default scales the SVG viewbox (careful with the terminology now, we're not talking about the browser viewport) to fill the CSS-determined dimensions of the SVG element. The fill behavior is determined by the SVG preserveAspectRatio attribute. By default it's set to meet, which keeps the whole SVG viewable, and the aspect ratio preserved. The alternative is slice which scales the viewbox up to cover the element, even when that means cropping. (slice behaves similarly to background-size:cover in CSS3.)
What you need to do is:
a) Don't declare explicit height or width in the SVG file. If your graphics editor is generating them, just go in by hand and delete them. According to the spec, if no width and height are specified, a value of 100% is assumed, so your pseudocode is redundant at best.
b) Make sure you're setting an explicit height for the svg element in CSS. I recommend developer or Canary builds of Chrome for troubleshooting responsive svg sizing, as there is a bug in Chrome 18 Dev Tools that has since been fixed. Once you've got it working in Chrome, it will almost certainly also work in Safari.
c) Figure out how you want to set preserveAspectRatio and manually edit the svg to put in the declaration.
If you're still having trouble, please post a jsfiddle. It's much easier for other people to comment on.