My question is how to disable the bouncing effect while scrolling in Figma? I can't find any information about it in the documentation and I was thinking if is it possible to remove that effect at all. I mean scrolling in the emulator of figma.
To date, there is no way to disable that effect.
Workaround:
To demonstrate scrolling without the bounce effect, you have to present part of your prototype as an animation, specific to that scrolling scenario. Then explain to the viewers that all scrolling behavior should follow that.
Related
Capturing an image of an off-screen window with CGWindowListCreateImage is a common way to create QuickLook style zoom-in animations, but this seems create an image with the wrong background colour, slightly lighter than the real window.
This causes a flash at the end of the animation which kind of ruins the effect.
Does anyone have any idea why this happens and what can be done about it?
EDIT: I created a demonstration app for this problem. It is a bit large and complex for a Stack Overflow question, but the relevant code is probably in the ZoomingWindow.m methods takeSnapshot and makeAndPrepareSnapshotWindow.
Setting the window appearance to textured in Interface Builder fixed this. Of course that also changes the color of the window, but that is acceptable in this particular case.
I have a problem with the <canvas> in Firefox. Second time I remove and add it with Javascript, nothing will be drawn. I've checked the code and it seems find, it's even working in Chromium and Opera without any problems. Does anyone recognize this? I don't know how to debug the canvas.
I wish I could provide a code snippet, but I haven't been able to reproduce the bug outside it's code base.
Canvas is passive to changes that may affect the content. It doesn't keep track of these things.
The solution is to always update the content when a change occur such as in this case.
You can also tap into window.resize (Chrome for example may clear the canvas if you use the dialogs etc.) and there can be other unknown factors. So never assume canvas will contain what is drawn but always redraw everything in those cases.
IE8 has a horrible time collapsing a medium sized tree panel with multiple columns. It is way too slow.
I am looking for ways to speedup the transitions from expandAll to collapseAll states.
One such way would seem to me is cancelling animation for IE8. It seems that in previous versions there were options that maybe specified on expand/collpase methods to enable or disable animation. However I don't see these options anymore.
Has anyone done this on 4.1x?
TreePanel has animate property that can be set to disable the animation:
animate:!Ext.isIE
Tried this and it works. However the effect is opposite to what I expected :(
With no animation IE just sits there and thinks it over, and over and over until it calculates every node and then repaints the entire tree at once. This makes it look like it takes longer not shorter, since with animation you can at least see IE struggling ...
I have been working on getting this seat mapping chart for a while and have created a few iterations, and the problem I keep finding is when I get to IE8 the panning for this is way to slow and delayed.
What I have at this point to cut down on load time is created a png to replace my "strokes" since I assume ie8 wanted to re-render each time I dragged the map.
I also added controls hoping to force IE8 users this option, but still there is a delay in the pan, and if I can have users with IE8 (and ie7 if possible) still drag/pan without the controls and the respond time a little faster that would be great.
Here is my current JSFiddle
I am still a little green with JS so if you have any suggestions it would be much appreciated. (PS Chrome frame is awesome but is not a option for me)
Update
I have removed the original dragging function and replaced the code using jqueryui's draggable function. Martin had suggested to just drag the div, and not the Raphael elements. Doing so lets this thing fly in ie6-8 which is great, but then came my concern about scaling. What I was seeing before on zoom my paper element WxH would stay the same ratio, cutting off my drawing when it zoomed in. After digging through the Raphael documentation I came across paper.setSize. setSize was exactly what I needed to allow this project to move and groove in ie6-8 and pretty much conquer all browsers in its path.
So in short, using jqueryui's draggable and paper.setSize has cured my cross browser zoom n' pan blues.
From what can be seen in the Fiddle, you are triggering a new rendering of the image by calling .translate() inside of a mousemove event handler:
mapContainer.translate(currentMapPosX, currentMapPosY);
rsrGroupies.translate(currentMapPosX, currentMapPosY);
This approach is toxic for performance in all browsers, let alone IE8. When dealing with VML in IE8 you should consider that each and every DOM change inside the image will result in the image being rendered again. Doing that while panning will always be painfully slow.
I see that you are already using jQuery in your Fiddle. If you want to increase performance of your panning, you should consider doing the following:
Render the image in Raphaël exactly once for the current zoom level. Do not attempt to change transformations in your VML/SVG image at any point in time while panning.
With the mousemove implementation of panning you already have, move or scroll the HTML container that holds your VML/SVG image instead. Imagine a <div> with overflow: hidden and simply move the image inside relatively, or scroll to the appropriate position.
This will require some adjustment of your coordinate calculations, but it will improve your performance in all browsers.
I'm using css animations on my page and Safari seems to change unrelated font weights elsewhere on the page when animations are running. Any idea why this happens? All other browsers work fine, include webkit ones like Chrome.
I've detailed the bug in a video here - http://www.screenr.com/gZN8
The site is also here - http://airport-r7.appspot.com/ but it might keep changing rapidly.
I'm using compass (#transition-property, #transition-duration) on the arrow icons. No transitions applied on the heading that's flashing. On a Mac - so it might be the hardware acceleration, but I'm still trying to figure it out.
When you trigger GPU compositing (eg, through CSS animation), the browser sends that element to the GPU, but also anything that would appear on top of that element if its top/left properties were changed. This includes any position:relative elements that appear after the animating one.
The solution is to give the animating element position:relative and a z-index that puts it above everything else. That way you get your animation but keep the (superior IMO) sub-pixel font rendering on unrelated elements.
Here's a demo of the problem and solution http://www.youtube.com/watch?v=9Woaz-cKPCE&hd=1
Update: Newer versions of Chrome retain sub-pixel antialiasing on GPU composited elements as long as the element has no transparency, eg has a background with no transparent or semi-transparent pixels. Note that things like border-radius introduce semi-transparent pixels.
Apparently, that's the price you pay for hardware acceleration: all text momentarily turns into images, which causes the drop in render quality.
However, applying html {-webkit-font-smoothing: antialiased} to turn off the sub-pixel anti-aliasing makes this problem go away. That's what I'm doing for now.
UPDATE: Since then, I've also come to learn that this happens only when the browser can't be sure if the section being animated is going to affect the text. This can usually be handled by having the text above (higher z-index than) the elements being animated, and/or making sure the text has a fully opaque background.
I've faced this issue numerous times and have had success adding the following css to the animated element:
z-index: 60000;
position: relative;
It seems it needs both z-index and position to be effective. In my case I was using it with Font Awesome animated spinners.