Configuration is as follows :
_ four independent zones, top_left, left, top_right and right.
_ the scroll should be linked horizontally for a top and its area below
_ the scroll should be linked vertically for each zone and its sibling (on an horizontal axis)
This configuration is described in the picture linked below. Same color means synchronized scroll. A zone to be synchronized with is referred as "scroll-buddy" for the remaining of this question.
I have tried several methods, all of which focuses on user experience using platform-browser-native scroll solutions. In this situation, frameworks like iScroll should be considered as a last resort.
The most obvious solution is to set the scrollTop/scrollLeft of the appropriate scroll-buddy whenever onScroll is called. This is expensive as reading scrollTop/scrollLeft forces the browser to layout. However, performances can be greatly improved by calling requestionAnimationFrame() on this operation. The biggest limitation is probably due to the different ways a browser has to handle scroll events. The result is sparse, at best, with a laggy/"always trying to catch up" synchronization on mobile devices (chrome/safari) due to the specific implementation of inertial scroll.
I have also tried to intercept, clone and redispatch user events to the appropriate scroll-buddy. I am unsuccessful at this point, plus the inertial scrolling is a floating point operation, which results could be very sligthly different even when triggered by the same user event. This could cause a little delta between two scrolling buddies and could be very well perceived on very large scroll zones. A periodic sync is always possible but at this point I simply could not make it work.
I have also considered putting everything in the same scrollable zone but the complexity of this solution is quite remarkable.
My question therefore is very simple : could anybody come up with a better strategy for this problem ? Or simply provide me with an implementation of the first solution that could do the trick, maybe by using something I missed.
Related
I'm handling touch events on a <canvas> area (using jQuery). I'd like to only handle single touch events, leaving multiple touch events uncancelled (e.g. so you can pinch-and-zoom).
The problem is that no matter how simultaneous the touches are, I get a touchstart with one point, followed by a touchmove with one point, and finally a touchstart with 2 points.
If I cancel the first touchdown event with preventDefault(), there's no zooming, even if I don't cancel after the touchmove nor the second touchdown.
If I don't preventDefault() on that first event, then touchmove events will scroll the page up and down in addition to my handling of the touch movement.
(testing on Android 8.1.0 - Samsung Galaxy Tab A)
I've looked around at various postings and web searches, e.g.:
jquery preventdefault on first touch only
or How to prevent default handling of touch events? or Javascript support for touch without blocking browsers pinch support
... and while not specific to this situation, I get the feeling that I'm out of luck. Seems a shortcoming of touch event handling, however, insofar as it makes multiple touches impossible to detect on the first event.
------------ EDIT -----------
Thanks for the suggestions folks! I do hope someone finds the answer useful, but unfortunately it doesn't fit my purposes, and I thought I should explain why (superfluous, perhaps, but may provide someone more insight).
To give some background, this is for a reusable module that provides an API for elements, including drawing 'sprites' and handling mouse/touch events like 'down', 'up', 'drag', etc. As such, I need to consider pros and cons carefully in the context of reusability and clarity.
The solutions mentioned here, and all others that I've found or indeed can conceive of, require a delay. There are two problems with this:
The minor problem is that any delay-based implementation of "multiple touch" is subjective. Multiple-touching is not timed out — you can theoretically touch with one finger, take a leisurely sip of your coffee (presumably with your other hand), then touch with another finger, and still be able to (e.g.) zoom. If this were the only problem, I could probably live with a pre-determined time-out, but it would be based on my perception of users' habits. (I could forsee, for instance, someone touching a 'sprite' over a dense background like a geographical map, realizing there's some detail they want to focus on, and then trying to zoom in.)
If I did delay on down, say by choosing a 300ms delay, it becomes a bit of a rabbit hole. A lot can happen in about a third of a second; likely, they could start a 'sprite' drag. There are then two choices:
If I wait to make sure it's a single touch, I miss (or cache) at least one 'move' event, and all dragging would then show a slight hesitation at the start. A third of a second is well within the bounds of perceptibility, so this is unacceptable.
Or, I could detect slight movement and assume that it's the start of a motion gesture like dragging. I'd then have to raise the API's 'down' and 'move' events simultaneously, a distasteful twiddle but again tolerable. More ambiguous is the threshold for determining it's actual motion. A very steady touch can easily get 4-6 pixels of movement on a touch screen, and I've seen well over 12 pixels for shaky touches. The gap could well be large enough to show an unseemly jitter.
As you can imagine, this is already a very processor-intensive module, especially problematic on mobile devices. Considering the increased code complexity and size (and further divergence of mouse vs touch event code paths), the possible need to introduce several tweakable settings that may be rather opaque to the user, and the fact that any solution is a compromise (point 1), I've decided that the least bad choice is to live with this limitation. The highest priorities here are smooth graphics handling and lean code (both size and processor intensiveness).
So at this point I'm willing to forego multiple touch gestures on the element. Zooming outside the element works fine, and is not unexpected behaviour — witness Google Maps.
For simpler applications, it should often be acceptable to delay detection of 'touchdown' to check for further touches.
Add a timer for your second tap in the middle of your first tap function.
For example:
$(myzone).touchstart(function(e){
e.preventDefault();
$(myzone).bind('touchstart',myeventTouch)
action = setTimeout(function(e){
$(myzone).unbind('touchstart',myeventTouch)
clearTimeout(action);
}, 500);
})
function myeventTouch(){
//When double tap do..
}
If you don't want to do this, you can also add a jQuery plugin in your page, for example I searched for one and found jquery.doubletap.js https://gist.github.com/attenzione/7098476
Use this:
$(SELECTOR).on('doubletap',function(event){
alert('doubletap');
});
Link 1 - http://horebmultimedia.com/Sam3/
Link 2 - http://horebmultimedia.com/Sam5/
In the above links, i have added a set of numbers added in separate containers in each file and u can find the FPS on the top right. The issue is when i mouse over in this Link 1 and click any numbers, as u see the FPS is getting slower & slower, making the world to rotate slower on the left side.
While on this link, Link 2, I added only one mouse over and 5 mouse over, but there is not much difference in FPS, why it lags so much when i have 37 containers. I can give my code if u need to resolve.
I had a rough look at your code, but digging through an entire project is not a fantastic way to debug an optimization problem.
The first thing to consider is if you have mouseOver enabled on your stage, I would recommend a liberal use of mouseChildren=false on interactive elements, and mouseEnabled=mouseChildren=false on anything not interactive. The rollover could be a big cause, as it requires everything to be drawn 20 times per second (in your usage). Text and vectors can be expensive to redraw.
// Non-interactive elements (block all mouse interactions)
element.mouseEnabled = element.mouseChildren = false;
// Interactive elements (reduce mouse-checking children individually)
element.mouseChildren = false;
If they don't change, you might consider caching text elements, or button graphics. I think I saw some caching in the source - but its generally a good thing to consider.
--
With that said, debugging optimization can be tough.. If removing all the buttons brings your performance up, consider how your buttons are being constructed, and what their cost is.
* Mouse over is expensive
* Vectors and text can be expensive
* Caching can help when used right, but can be expensive if it happens too often.
* Review what is happening on tick(). Sometimes, code is running constantly, which doesn't need to.
--
A few other notes:
This does not do what you think: _oButton.off("mousedown"); -- You need to pass the result of the on() call. If you are just cleaning up, call _oButton.removeAllEventListeners().
You don't need to set the cursor on mouseover. The cursor will only change when it rolls over -- so just set it once, and then get rid of your buttonover stuff.
It might make sense to just extend EventDispatcher for your custom classes, which gives you things like the on() method, which supports a data param. I might recommend this in place of your addEventListener stuff in CTextButton
Note that RAF does not support a framerate property (it just uses the browser's RAF rate, which is usually 60fps). Use createjs.Ticker.timingMode instead of the deprecated useRAF.
Hope that helps a little.
I have a react-virtualized's infinite scroll list, (Most of the setup is copied from this example). I'm providing it with a rowRenderer function like the specs requires. this works fine if the rowRenderer function is very lightweight (i.e returns a very basic component as row).
but the rendering of my RowComponent includes some Array.map over some properties. this shouldn't cause any problem except that the rowRenderer functions is being called tens or even hundreds of times while scrolling. this causes a performance issue, making the scroll not smooth enough.
So far I tried:
Caching my rowRenderer this works, but I don't like this solution as it may cause problems in the future.
Make my RowComponent's render function pure and implement shouldComponentUpdate using react-addons-shallow-compare. this slightly improved the performance but not enough.
In this example, the rowRenderer function is also being called many times per scroll (no perf issues there as the function is very lightweight), which makes me believe this behavior is by design. so:
Is caching a good solution? any advice in how to sync it with my app's state (I use redux for state management)? is there something I missed in the docs that can reduce calls to rowRenderer (there's no reason for my rows to change while scrolling)?
Author of react-virtualized here.
Your rowRenderer methods should be lightweight because, as you've found, they may be called rapidly when a user is scrolling. The good news is that- since browsers manage scrolling in a separate thread from the UI, this usually doesn't cause any performance problems. If anything, you may notice some empty/white space at the edge of the list in the direction you're scrolling- indicating that your renderers aren't able to keep up with the user's scrolling speed.
One caveat to be aware of though is that if you attach touch or wheel event handlers to a react-virtualized component or one of its DOM ancestors, this will force the browser to scroll in the main/UI thread. That can definitely cause slowness.
I'm currently in the middle of a major update (version 7) which, among other things, will passed named arguments to user-functions like rowRenderer. This will enable me to pass meta information (like whether or not the list is currently scrolling) which could enable you to defer "heavy" logic while a scroll is in progress. Unfortunately this isn't possible in version 6 unless you're willing to use a timeout as doron-zavelevsky mentions.
Edit: You may be happy to learn that with this commit cell caching has made its way into the upcoming version 7 release.
From my experience with this library (I'm not using the latest version though) - this is by design.
It makes sense - in order to avoid rendering all the list at once - and to allow you infinite scroll - it asks you every time to render the currently viewed item.
Your goal is to optimize the render function - as you yourself mentioned.
One more thing that can improve your overall experience is to check and see if your item contains some complex code in its componentDidMount life-cycle method - or any other code that runs post-render. If that's the case - you can optimize for fast scrolling by delaying these calculations with a timeout - and only let them run if the component is still mounted when the timeout passes.
Consider the case that you fast scroll over items to get to the bottom - there's no sense in fully populating all the items you scroll past on the way there. So you return the render result as fast as you can - and inside the item you wait ~200ms - and then you check whether the component is still mounted and do the real work.
Since isMounted is obsolete you can simply set a variable to true during componentDidMount and back to false of componentWillUnmount.
My page is running a touchmove event which captures the position of the user's finger on the screen via:
xPos = e.originalEvent.touches[0].pageX;
yPos = e.originalEvent.touches[0].pageY;
The page has many layers (created with position:absolute divs) and at this point, I want to calculte how many such layers exist below the user's current position on the screen.
The only method I can think of is to have an array of all the layers' positions and loop through that. However that seems rather processor intensive when there may be hundreds of layers on screen at once.
Is there a simple way in js or JQuery to count the items that exist in a position, or a better practise way to do it than my array suggestion.
As far as I know, there is no such way. My approach would be to give all layers a certain class, select them all and iterate through them. Depending on what you are trying to achieve with this and how often you'll have to perform this calculation, it may be possible to use caching and approximation (e.g. not checking a certain pixel but an area of x^2 pixels and caching the result, etc) to make things run faster.
That being said, I encourage you to first try the solution that you've thought of and see how fast it actually runs. Browsers are pretty fast for such standard operations (think layer drag & drop with boundary checks), so I'm pretty confident that it won't be as slow as you think it will be :)
my site looks fine untill people start zooming in and out and after hours of work on it and messing with its css I am clueless on how to fix this zoom problem. Should I somehow fix the zoom to a certain level? if so, how can I do it? I tried fixing this zoom issue but putting everything into a table but that isnt really working so I dont know what to do..help..
This is how it looks on safari, its fixed if i adjust my zoom level but initially looks like this:
Then on firefox and chrome looks perfect:
The zoom level of the browser is something that is strictly the domain of the user - it is bad practice to interfere with user-level choices such as page zoom, and usually you are technically unable to do so anyway. A user will zoom a webpage because they wanted to enlarge it, the reasons are their own and an individual site should not (and can not) interfere with that choice.
Instead of fighting the user, you should seek to design your site in such a way so as to make the content the most important thing. You should craft your design in such a way so that when a user zooms (or makes other changes like disabling CSS or Javascript), the content (presumably the point of having a website at all) is the focus.
Using percentages for your layout, using em for font sizes, and other such techniques will increase the accessibility of your site. See articles like http://24ways.org/2007/css-for-accessibility or http://www.w3.org/TR/WCAG10-CSS-TECHS/ for information on using accessible web design techniques.
EDIT
The screenshots demonstrate one of the many pitfalls in trying to prevent accessibility support - different browsers implement zoom in different ways. Some only increase the font size, some enlarge the images, it is not consistent. The trick is to make it not matter, not to prevent it from happening.
Here's an IE fix
http://www.bennadel.com/blog/1354-The-Power-Of-ZOOM-Fixing-CSS-Issues-In-Internet-Explorer.htm
.css
{
zoom: 1
}
Short answer: No, You cannot modify the end user's browser setting for zoom level.
Maybe you should look into CSS patterns for designing sites that zoom nicely. For example I beleive em's zoom better than point based font sizes. etc
take a look at articles like these: http://kyleschaeffer.com/best-practices/css-font-size-em-vs-px-vs-pt-vs/
Also, if you post specific problems we may be able to help solve them on a one off basis