I'm using a particle.js plugin. And when I switch from canvas to window mode it makes the effect not sync with the mouse. I found out that you need to change the clientx/y to pagex/y in something called Mousemove. Does anyone know how to do that?
I looked over the internet but I couldn't find anything
Related
Since I´m working on a project where I need to be able to drag objects around my canvas but also to scroll the entire page by dragging the actual canvas 'background' behind my PIXI Sprites, i followed the findings of this guy here:
https://github.com/pixijs/pixi.js/issues/2483 :
By default, the Pixi canvas/display-area cannot be used to scroll the
webpage that contains it. Which is important on touch screens. (eg. If
you use the rest of the web-page to pinch-zoom into the Pixi canvas,
you can become trapped and unable to zoom back out (or pan away),
because there's no non-Pixi-canvas area of the page to "grab" with
your pinch gesture).
To enable this functionality, I use autoPreventDefault. But this comes
with some undesirable side-effects, like scroll/pinch-zoom actions
over the canvas registering "taps" or clicks in a way that doesn't
make sense. (ie. I'm attempting to zoom or scroll the outer page at
that point, not interact with the Pixi canvas)
To work around that, I modify and compile my own custom version of
Pixi where I can apply preventDefault in a more granular way...
To get page-scrolling functionality it seems I only need to
preventDefault in the InteractionManager.prototype.onTouchEnd
function. Whereas autoPreventDefault will also preventDefault on 3
other events. (onMouseDown, onTouchMove, onTouchStart).
Leaving autoPreventDefault = false and applying preventDefault only to
onTouchEnd, gives me the functionality I need. But it'd be nice to not
have to customize and rebuild Pixi in this way every release. (Sorry
if there's something else I'm missing here; I don't completely
understand the event system in Pixi, or what else to do about this
scroll-touch problem)
So i disabled e.preventDefault() on 'onTouchStart' and on 'onMouseMove' but left it as is on 'onTouchEnd'
This works perfect on IOS devices but not on Android, the only exception being a Samsung A7 using Adblock browser (fails on Chrome).
Would really appreciate some help on this.
TLDR:
Disabling PIXI´s e.preventDefault on onTouchStart and onMouseMove works on IOS devices and lets me scroll the page by draggin my canvas around but not on Android devices.
My solution for that was to use
renderer.plugins.interaction.autoPreventDefault = false
This should work on iOS and Android.
Docs for autoPreventDefault reads:
Should the manager automatically prevent default browser actions.
Using PIXI 4.5.6.
Take a look at the docs:
http://pixijs.download/dev/docs/PIXI.CanvasRenderer.html#plugins
http://pixijs.download/dev/docs/PIXI.interaction.InteractionManager.html
Using renderer.plugins.interaction.autoPreventDefault=true should do the trick.
I try to explain my problem and behavior.
Enter touchpunch vertical slider demo-page (http://touchpunch.furf.com/content.php?/slider/vertical-slider) on your smartphone. Zoom to the max and touch somewhere one the slider - the result is that the handler moves but not to the point you were touched but higher. The distance between touch and handler position after touch is bigger when the zoom is bigger and opposite - on default 100% view everything is ok. I notice it in my project and this is a problem becouse on mobile devices zooming site is common and then slider got crazy. Do you have any ideas guys how to resolve this?
Question is rather old, but today I stumbled upon the same problem and I decided to share the solution I've found ;)
What I've done is:
added position: relative on the container
modified touch-punch plugin, adding scroll offset to clientX and clientY coordinates of simulated mouse event.
Here is fork with updated code, also added some test cases you can check out in live browser:
https://github.com/Kocik/jquery-ui-touch-punch-zoom-fork
As the canvas uses its own local coordinate system, I've tried several methods to ascertain the global X,Y of mouse clicks and translate them to the coordinate system. I do this by subtracting the left margin and top margin from the canvas itself via either jQuery
.offset()
or by using
getBoundingClientRect()
in Javascript.
Sadly, both of these will be affected by browser scrolling. I may just be missing a property (I use e.clientX and e.clientY because I know they're cross-browser capable) that would give me a more definite value... I have been perusing all the properties of a DOM element and none of them seem to quite give me what I need...
I need a scroll-independent way of determining how far from the document top I am to relate mouse clicks to a coordinate system.
...or am I being an idiot and there's a cross-browser way to detect mouse clicks relative to an object? Thanks in advance.
Best method I can find would be to use a jQuery method such as $('#').offset() and then account for scrolling. Alternatively, Object.getBoundingClientRect() can be used, but I'm not sure on the cross-browser compatibility.
Nobody else felt like chiming in, lol.
I need some advice on how to set up zooming in and out of a HTML5 JavaScript canvas. I have the functions and switch statement set up just need advice on how to actually enable zoom.
I was considering just making it use the browsers zoom function as I only need it to work on Chrome. Is this recommended?
Thanks
Just use ctx.scale(x, y)
Here is a direct link on MDN, however I advise you to read the whole article.
You can scale in the canvas using the browser's zoom, but just be warned that a canvas is a raster image, so zooming in will introduce aliasing (jaggies). I haven't yet seen a way to draw on a zoomed-in canvas (i.e. canvas pixels are larger than display pixels) without aliasing. And it turns out to be very hard to even work out how much you are zoomed in: How to detect page zoom level in all modern browsers?
If, however, you zoom by redrawing on some event, even using ctx.scale(x, y) as #rezoner points out, rather than allowing the browser to zoom, then you can still draw without aliasing. For a smooth zoom, I would suggest using scale as a quick zoom while the use is zooming quickly, and performing a full-redraw every 1.3x or so and again when they stop zooming. That should give you something like the Google Maps behaviour where you get a rough zoom immediately (good responsiveness), but it updates the view as you continue to zoom.
I'm trying to get this effect to work with touch events on an ipad, here is what it should look like with mouse events on jsfiddle http://jsfiddle.net/FwsV4/1/
This is what I've tried http://jsfiddle.net/FwsV4/3/ which isn't working for me.
To be honest I'm a little lost with touch events and how to translate mouse clicks/moves to them. I'm actually not sure how to best utilise this effect, but I want to keep the elements underneath interactive using touch start/end events.
Can anyone point me in the right direction?
Your first problem is that you will need to bind to touchstart to prevent the page from scrolling. You could just do:
$('myElement').htmlElement.bind("touchstart", function(event) {
event.preventDefault();
}
);
It's probably better to get the co-ords from this as well though.
Here is a good tutorial on touch events:
http://www.sitepen.com/blog/2008/07/10/touching-and-gesturing-on-the-iphone/
Your second problem is setting the element to 5000px height and width, as by default iOS will zoom to include the entire page. You should adjust this OR use the viewport tag to change zoom behaviour (see viewport apple docs).
The following code is also incorrect and returns a Boolean value, not one of the objects.
var touch = e.originalEvent.touches[0] || e.originalEvent.changedTouches[0];
This should be:
var touch = e.originalEvent.touches[0] ? e.originalEvent.touches[0] : e.originalEvent.changedTouches[0];
BUT with touchmove you're interested in e.originalEvent.touches[0] (assuming only single finger touch events are of interest).
You should also avoid using inline js and separate file js in this manner (there are reasons to do so in some circumstances perhaps). It makes it harder to follow.
I'm not sure using touch events with jfiddle is a great plan either (I might be wrong), i'd just use a normal webserver/local files to develop on.