I'm considering using VirtualSurfaceImageSource in my application, and I've implemented something similar to the Direct2D magazine app sample, but I've run into a problem which occurs when the virtual surface is several times larger than the display area.
Basically, I have a horizontally scrolling ScrollViewer which contains an Image. The source of the image is a wide VirtualSurfaceImageSource (at least ~10000 x 500 px). The width of the ScrollViewer is 1280 px.
When I scroll the scroll viewer with touch panning, the image sometimes flicker - a part of the image disappears and then it's redrawn. This usually happens when the inertial scrolling stops. The image is already fully drawn when it scrolls into the view, but for some reason it's cleared and IVirtualSurfaceUpdatesCallbackNative::UpdatesNeeded() is called.
I've uploaded a video which illustrates the problem. Watch what happens when the scrolling stops (at 0:02, 0:17, etc...)
Any ideas why this is happening?
I've also noticed that the flickering doesn't occur if the image width is ~5000 px or less.
If you want to reproduce this, start from the Direct2D magazine app sample and add more text in the Sample.story, under the <text name="butterfly-body"> tag - just copy the existing text 10 times or so. Try scrolling the butterfly page in both directions and with varying speed, and you should see what appears to be the same problem.
I've asked this question in an MSDN forum, but so far I've gotten no answer.
This is no longer an issue in Windows 8 Release Preview, so it was probably just a bug in the Consumer Preview.
Related
[enter link description here][1]The iOS app Device 6 has really left a mark on me, and as a iOS developer, I am confused as to how the app was created.
Does anyone know how they were able to create parallax scrolling with non-interative text all around the image?
Here's a link demoing the app, in about 16 seconds into the video, you can see the parallax scrolling.
https://www.youtube.com/watch?v=-VdeB9_q9nU
P.S. for anyone confused, basically I created a label with a few lines of text. Now underneath that label, I want to place a box that's 2x2 inches. Inside that box should be a image, and as the user scrolls down, the image inside the box should scroll down too, just at a different speed. I have no idea how to do that! For a visual interpretation, just see the video link I posted above.
TL:DR
What technique does Apple use to make Photo.app so fast, even with large images?
Long Version
I watched Apple's WWDC 2010 video about scroll views to learn how to replicate Photo.app pagination behavior and low memory utilization (PhotoScroller Demo). It works well, but since images are loaded only when they are needed, when I try to paginate to another image, the app locks while the JPEG is being decompressed.
The same video shows a tiling technique to get better performance, but since I'm using photos taken from the camera and stored in the app, that doesn't seem feasible (having multiple copies of each photo, in different resolutions, would consume too much space - 4MB vs 27MB). Also, using iExplorer I noticed Photo.apps has only a copy of each photo (it doesn't even have a small thumbnail copy for the gallery).
What technique did Apple use to make Photos.app so fast? How can I get that same performance in my app?
I'm a bit confused if this should be here or on Programmers,
since there's no code in the question, but F.A.Q. says that algorithm
questions are part of Stackoverflow, and the tags here match it
better.
So if you just show one image fullscreen you can do this:
In the WWDC11 Session 104 - Advanced Scroll View Techniques they talk about infinite scrolling and how to do it. The basic idea is to scroll the view and after scrolling reposition the (UIImage)view inside the scroll view so it appears centered or whatever you layout constraints are.You could then load the new UIImage into the UIImageView. Since you only have one UIImageView it should be pretty low memory consuming. I am not sure about how the loading times of the images will behave though.
Maybe preload the next UIImage to the left and right to the current image and then load it into the UIImageView after reposition the scrollView can help here.
For anyone who is still looking for simply implementation of scroll view that hold lot's of images.
https://github.com/sumofighter666/ReusableScrollView
It is as simply as implementing UITableView
I am facing a strange issue with screen scrolling on 9810 device and simulator.
I have a complete order screen, which is shown when the order of the user is confirmed.
At the top there is Vertical Field Manager which contains another VerticalFieldManager ( containing Label Fields and buttonFields ) and a FlowFieldManager (containing images).
Now the problem that i am facing is that whenever i scroll the screen up and down , there are many gray lines appearing on the screen. It seems as if there is some screen refresh issue with the device. I tested on previous OS (4.5, 4.5 4.7 5.0) version, everything is working just fine on them. The problem is arising on OS version above 6.0 .
While the correct screen must be like
As you can see these gray lines appear whenevr i scroll screen up and down. Any ideas how to rectify this issue ?
In the first image, it looks like you are trying to add a shadow effect at the top of the screen. The vertical field manager uses some graphics optimization to improve scroll performance. Instead of repainting everything, it picks up the pixels on screen in the layout area, and shifts them. This works so long as all the painting code is relative to the virtual extent.
Certain UI effect, like a shadow effect, are relative to the screen, rather than the virtual extent, so this optimization picks up those effects and copies them elsewhere, which looks bad. It also tends to look just like your first image.
There are two ways to fix this:
Turn off the optimization. Override isScrollCopyable to return false. Your visual problems should go away, but scrolling performance will suffer.
Don't add UI effects on top of a scrollable area.
I am very sorry for the late reply. However i fixed the issue by myself. I just overrided the paintBackground method in my class and inside that i wrote graphics.clear(). This seems to fix this scrolling issue. I will try Michael method too though.
We're currently working on an iPad version of our web application at work. We are seeing inconsistent behavior with regards to two-finger scrolling on scrollable areas within others scrollable areas across two iPads. Both devices are iPad2 models.
On one device, dojo grids and trees require one finger to scroll. On the other, they require two fingers to scroll. On both devices Safari is being used to view the website.
What could cause this behavior? Is there some setting we haven't discovered that dictates whether you need to use 1 or 2 fingers?
Looks like it's a difference in IOS versions (one is on 4, the other on 5).
It's important to note that
-webkit-overflow-scrolling:touch is not the same as one-finger scrolling enabled by iOS5.
-webkit-overflow-scrolling uses the iPad's built in functionality (the touch acceleration and bounce). However, if the contents in your div change, or you manually move the contents inside the div (ie you made your own div scrollbar and are scrolling the contents), enabling this will mess things up. What it will do is make the "top" of the scroll able div wherever it happens to be located. What does this mean? If your contents are scrolled half way down and then you add new content to the div, with -webkit-overflow-scrolling:touch, the very top of the touch-scroll area will be half way down your div. You will not be able touch-scroll back to the top.
Does anyone know if the iPad has any limitations on the canvas tag?
Currently I'm working on a creative that uses a flipbook and audio tag combination to simulate inline video content. The animations are drawn to the canvas element and synced with the audio content being played. There are 4 short video clips that get played when someone clicks on the four buttons below.
http://cs.sandbox.millennialmedia.com/~tkirchner/rich/K/kungfupanda2_test/
The problem I'm having though is in iPad. After playing a few animations, mobile safari just suddenly crashes. It never happens when I play it on my iPhone but it happens every time on the iPad. Its not one particular animation either because if I click a different combination of buttons, the previous clip that it crashed on plays fine, and then it decides to crash on another clip.
I think the problem might have to do with the amount of memory Safari gives individual page views. I found a blog post that explains that problem pretty well.
http://roblaplaca.com/blog/2010/05/05/ipad-safari-image-limit-workaround/
According to that post, once mobile Safari reaches a particular threshold of memory, images begin to return blank. This is consistant with my finds so far. The iPad that I'm testing this all on is running iOS 3.2.1 (and before anyone tells me that I should just explain to my boss that nobody uses 3.X anymore, I tried... they still want me to investigate this). I borrowed a co-workers iPad running iOS 4.2.1 and that device didn't crash, but some of the images weren't being drawn to the canvas.
I'm pretty sure its a problem with the canvas tag too, because I tried experimenting with running the animation without drawing anything to the canvas element, and the page never crashed.
Thats why I think maybe its a limitation with Safari's support of the canvas tag. Of course, I'm open to anybody else's suggestions.
Feels kinda weird answering my own question again, buuuut I figured if anyone did a search on this kind of question, an answer would be helpful.
I believe my original hypothesis was correct. The total amount of images that the aniamtions were using was around 600+. I think the older iPad loaded as many as it could and then when it ran out of cache and the canvas tag was trying to draw images that weren't really there anymore, it crashed.
Eventually we ended up serving the ad to devices with iOS 4.2 and higher, since the problem didn't seem to occur on those newer devices. Plus, we compressed the image sizes further, so that helped reduce the amount of images we were storing into memory.
If anybody knows approximately what the cache threshold in iOS 4.2 or higher browsers are, I'd appreciate it if you commented. Just want to get an idea of how many KB of image data I can safely load.