It seems like applying a webkit-transform property on an element or it's parent that has webkit-over-flowing-scrolling: touch completely breaks the scrolling in that scrolling doesn't work at all.
Has anyone experienced this bug and know of a solution?
My current (hacky) solution looks like this:
$container.one 'webkitAnimationEnd', ->
$container.find('.contents').remove()
$container.append('.contents')
Basically i'm removing and then re-adding the contents of the scrollable div after the animation ends. Hopefully someone has a better solution for this.
I'm having the exact same problem, and it only goes away if I ditch -webkit-transform and switch to absolute positioning.
This would be fine, except that absolute positioning leads to lousy performance and choppy animation on iOS, which in iOS 6+ cannot be remedied w/ the previously popular translateZ and translate3D forced hardware acceleration hacks.
I figured out a hack, but it is so hideous and actually ugly that you might not want to read any further:
Take the element we want to apply -webkit-overflow-scrolling:touch to and separate it completely from the element we are applying -webkit-transform to. Use z-index manipulation to cause the scrolling element to appear in the same place it would have originally, while retaining -webkit-transform to cause the original container (now an empty container) to animate into place naturally. In my case this hack falls short though, because the scrollable content will appear suddenly on top of the animated container, instead of sliding in along with it.
Related
I am working on a game using GTK3 as a rendering technique (terrible idea, but it's a school project).
My gameobjects are made of Image widgets and are placed in a Fixed container. It's working pretty well, however when i move widgets beoynd right or bottom border, the window automatically grows along with it.
I want the window to stay at the sam size, event if widget leaves its area and becomes invisible. It works when i move widget past the upper or left border.
I tried using gtk_widget_set_vexpand and gtk_widget_set_hexpand. My window is set as not resizable (gtk_window_set_resizable).
Is there any way I can achieve this?
This isn't the right way to use GTK+. GTK+ is intended for laying out widgets in a GUI program.
There are better options for animating 2D elements. One that works with GTK+ natively is the Clutter library. You can also integrate SDL or OpenGL or something like that if you so choose.
That being said, you can also use GtkLayout instead of GtkFixed, or put the GtkFixed in a GtkScrolledWindow and hide the scrollbars and set the scroll policy to prevent scrolling. It's still technically misuse, and in fact GtkFixed (and possibly GtkLayout too but the docs don't say) is really not supposed to be used anymore unless absolutely necessary because it doesn't give you automatic support for tricky UI layout problems, but it doesn't have extra dependencies.
I have an infinite scrollview in which I add images as the user scrolls. Those images have varying heights and I've been trying to come up with the best way of finding a clear space inside the current bounds of the view that would allow me to add the image view.
Is there anything built-in that would make my search more efficient?
The problem is I want the images to be sort of glued to one another with no blank space between them. Making the search through 320x480 pixels tends to be quite a CPU hog. Does anyone know an efficient method to do it?
Thanks!
It seems that you're scrolling this thing vertically (you mentioned varying image heights).
There's nothing built in to UIScrollView that will do this for you. You'll have to track your UIImageView subviews manually. You could simply maintain the max y coordinate occupied by you images as you add them.
You might consider using UITableView instead, and implementing a very customized tableView:heightForRowAtIndexPath: in your delegate. You would probably need to do something special with the actual cells as well, but it would seem to make your job a little easier.
Also, for what it's worth, you might find a way to avoid making your solution infinite. Be careful about your memory footprint! iOS will shut your app off if things get out of hand.
UPDATE
Ok, now I understand what you're going for. I had imagined that you were presenting photographs or something rectangular like that. If I were trying to cover a scroll view with UILeafs (wah wah) I would take a statistical approach. I would 'paint' leaves randomly along horizontal/vertical strips as the user scrolls. Perhaps that's what you're doing already? Whatever you're doing I think it looks good.
Now I guess that the reason you're asking is to prevent the little random white spots that show through - is that right? If I may suggest a different solution: try to color the background of your scroll view to something earthy that looks good if it shows through here and there.
Also, it occurred to me that you could use a larger template image -- something that already has a nice distribution of leaves -- with transparency all along the outside outline of the leaves but nowhere else. Then you could tile these, but with overlap, so that the alpha just shows through to the leaves below. You could have a number of these images so that it doesn't look obvious. This would take away all of the uncertainty and make your retiling very efficient.
Also, consider learning about CoreAnimation (CALayer in particular) and CoreGraphics/Quartz 2D ). Proper use of these libraries will probably yield great improvements in rendering speed.
UPDATE 2:
If your images are all 150px wide, then split your scrollview into columns and add/remove based on those (as discussed in chat).
Good luck!
I'm trying to develop a scrollable tile map in Cocos2D which uses an UIPanGestureRecognizer to do the dirty work, but while developing it, stumbled upon some problems for which I would like to ask for an advice.
The basic scrolling management works fine, it's precise and accurate and works by adding the translation recognized by the pan gesture manager to the tiles of the map. The problem is that the map is large and I just draw a small viewport of it, while I want to manage it like it's scrollable without any problem.
What I was thinking about is that, as soon as a whole row or column get out of the visible screen, it is moved to the opposite side, the corresponding texture rects are updated (I'm working entirely with a CCSpriteBatchNode), so that it will continuously update the viewport to make the whole thing work. This seems fine but I've found many problems in dealing with when to move the row/column, how to keep track of this issue (eg when pan changes direction from forth to back) and many little details which make me think that I should find a better approach.
Is there a common solution to my problem? That is: managing a scrollable viewport of a tilemap which should move over the whole map so the to the end user it seems like as if the map is infinite.
Thanks in advance
I solved my issue by developing a viewport in which rows and columns are effectively moved from left side to right side and from top side to bottom side.
This is done automatically when a new column or row enters the viewport and it's made by expanding the drawn viewport over the real one by an amount which is enough to avoid any graphical issue to the user.
I'm trying to make a level-of-detail line chart, where the user can zoom in/out horizontally by using two fingers, and grow the contentSize attribute of the the UIScrollView field. They can also scroll horizontally to shift left or right and see more of the chart (check any stock on Google Finance charts to get an idea of what I'm talking about). Potentially, the scroll view could grow to up to 100x its original size, as the user is zooming in.
My questions are:
- Has anyone had any experience with UIScrollViews that have such large contentSize restrictions? Will it work?
- The view for the scroll view could potentially be really huge, since the user is zooming in. How is this handled in memory?
- Just a thought, but would it be possible to use UITableViewCells, oriented to scroll horizontally, to page in/out the data?
This is kind of an open ended question right now - I'm still brainstorming myself. If anyone has any ideas or has implemented such a thing before, please respond with your experience. Thanks!
This is quite an old topic, but still I want to share some my experiences.
Using such a large UIView (100x than its origin size) in UIScrollView could cause Memory Warning. You should avoid render the entire UIView at once.
A better way to implement this is to render the only area which you can see and the area just around it. So, UIViewScroll can scroll within this area smoothly. But what if user scrolled out of the area that has been rendered? Use delegate to get notified when user scroll out of the pre-rendered area and try to render the new area which is going to be showed.
The basic idea under this implementation is to use 9 UIViews (or more) to tile a bigger area, when user scrolled (or moved) from old position to new position. Just move some UIViews to new place to make sure that one of UIView is the main view which you can see mostly, and other 8 UIViews are just around it.
Hope it is useful.
I have something similar, although probably not to the size your talking about. The UIScrollView isn't a problem. The problem is that if you're drawing UIViews on it (rather than drawing lines yourself) UIViews that are well, well off the screen continue to exist in memory. If you're actually drawing the lines by creating your own UIView and responding to drawRect, it's fine.
Assuming that you're a reasonably experienced programmer, getting a big scroll view working that draws pars of the chart is only a days work, so my recommendation would be to create a prototype for it, and run the prototype under the object allocations tool and see if that indicates any problems.
Sorry for the vagueness of my answer; it's a brainstorming question
But still, this approach (in the example above) is not good enough in some cases. Cause we only rendered a limited area in the UIScrollView.
User can use different gestures in UIScrollView: drag or fling. With drag, the pre-rendered 8 small UIViews is enough for covering the scrolling area in most of the case. But with flinging, UIScrollView could scroll over a very large area when user made a quick movement, and this area is totally blank (cause we didn't render it) while scrolling. Even we can display the right content after the UIScrollView stops scrolling, the blank during scrolling isn't very UI friendly to user.
For some apps, this is Ok, for example Google map. Since the data couldn't be downloaded immediately. Waiting before downloading is reasonable.
But if the data is local, we should eliminate this blank area as possible as we can. So, pre-render the area that is going to be scrolled is crucial. Unlike UITableView, UIScrollView doesn't have the ability to tell us which cell is going to be displayed and which cell is going to be recycled. So, we have to do it ourselves. Method [UIScrollViewDelegate scrollViewWillEndDragging:withVelocity:targetContentOffset:] will be called when UIScrollView starts to decelerating (actually, scrollViewWillBeginDecelerating is the method been called before decelerating, but in this method we don't know the information about what content will be displayed or scrolled). So based on the UIScrollView.contentOffset.x and parameter targetContentOffset, we can know exactly where the UIScrollView starts and where the UIScrollView will stop, then pre-render this area to makes the scrolling more smoothly.
I have horizontal list for which I'm implementing my own scrolling logic. I have the "touch and drag" scrolling working great, but I'm having trouble with the "flick" gesture. All the built in scrollable views have the feature that if you "flick" the view it scrolls faster or slower based on the intensity of the flick.
Does anyone has any suggestion how do that for my view?
What I'm doing right now is changing the UIView.center.x coordinate of my custom UIView to scroll it across the screen
I would strongly suggest you figure out how to make use of the built in UIScrollView class. Apple has invested a LOT of effort to make scrolling feel 'right'. You may be able to recreate some, or even all, of that feel, but it'll take a lot of work. Better to piggy back off of what's already been done.
If you want to implement your own scroll view, you'll have to make the view scroll based on the length of the sweeping distance and the speed at witch it went across the screen. Taking these parameters as input and using simple geometry math you could calculate how much further the view should scroll after the sweep has ended(touchesEnded event).
Ofcourse this is not as simple as it sounds, making the flick gesture just feel right and natural is much harder.
If you really are set on doing this yourself, Drew McCormack has a great article on MacResearch where he explains some of the physics behind momentum-based scrolling. His implementation uses HTML, CSS, and JavaScript, but the core principles could be brought across to your custom UIView subclass.