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.
Related
My project needs a UI like Google Chrome's Tab Switcher. There was such a question in the past but the responses are mostly irrelevant, as it was written 5 years ago and the responses had to do with a static and overlapping Evernote UI (here). I've been trying for days, but the best I could get was something really sluggish. Also interestingly, when coded, at some areas it worked, then it didn't. I didn't choose any code because honestly my code probably is more wrong than right and I should start fresh from the beginning.
What is it that makes it so confusing? Bottom down must be initially 100% visible, next up 50%, next 25% (relative to their height) and also obviously it's scrollable. The scroll direction like chrome is first (latest) at bottom and last at the top. However, I would also like the distance between the first and second to increase, should you scroll down to see less recent views, the second would have to be able to be 100% visible, as the bottom app disappears off screen.
Yes, it's a jailbreak project but that's irrelevant as I've coded a replica in the iOS simulator for this part. It's just a layout problem for a UICollectionView. All of the rest of the project, has been coded
I think that you can you the following library to achieve the desired result.
StickyCollectionView-Swift
Working on an AIR iOS app and noticed a strange thing.
In my app I have a navigation panel that displays over the main content-holding Sprite. Having this panel display was causing the app to crash on iPad1 (guessing too much memory). So I added a function to basically draw the content-holder Sprite (via BitmapData draw function) into a Sprite above it, and turn the content-holder visibility off. Basically, taking a screenshot.
However, I'm seeing on 2 different iPads now that any dynamically added text in the content-holder isn't being drawn. Sometimes, the first time it does, but not after.
One thing noticed is that turning off the cacheAsBitmap property of the text fields fixes the problem. Unfortunately, that is not an option as the app is very text heavy and the performance is noticeably slower if the dynamically generated text isn't bitmapped.
Any ideas on what may be going on?
Thanks in advance for any help.
-Mark
Looks like cacheAsBitmap on the dynamic text fields was the problem. By turning that off temporarily, taking the screenshot and then turning back on when done with screenshot, I was able to work around the issue.
Not sure if it's an AIR/iOS issue or maybe a lack of memory?
FYI, in case somebody sees similar problem. Hope that helps.
I'm using Qt 5.1 beta on iOS. I am deploying my app on an ipad.
The problems I am having regard how touch events are sensed and processed by qt. As long as I keep the ipad oriented straight (i.e. frontal camera is up), everything works fine. In that configuration, if I touch the screen, the coordinates of the point of touch sensed through mousePressedEvent(QMouseEvent *e) indicates that, as expected, the origin of the coordinate system is in the upper left corner of the screen.
When I turn my ipad, let's say left, so that the camera is to the left, my ui correctly rotates so that the buttons that I have are aligned to the screen. However, if I sense the touch events as described above, the origin of the coordinate system has not changed, so now it is in the lower left corner of the screen. Because of this, the buttons act as if they were not aligned to the screen but as if they turned around the same way I turned the screen (even if they are rendered aligned) So, if I tap on the visualized button it won't sense the touch, but it will if I tap were they would be if they would have not changed orientation as the screen did.
Does anyone have any idea what might cause this or how it could be fixed?
Please ask if you would like to see code. I did not put any as I would not know what might be of interest and my app is quite big already.
Thanks,
Corneliu
You file a bug report to the trolls about it. And also check to see if there is a bug report about it already.
http://bugreports.qt-project.org/
For the mean time you could push your coordinates through a mapping function of some sort based on the orientation of the device.
Also calling 'adjustSize()` on widgets tends to fix sizing and positioning with layouts.
Hope that helps.
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.
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.