I am using swiffy to use an animation in my webpage but the problem that its size is not static, when the page loads the animation is evolving in size from small to big.
Here is an example - http://neweratravels.in/akriti/rotate-testing.html
I want to make the animation stop expanding.
You have the size for the swiffycontainer div at "width: 407; height:400;". You need to say those are pixels, otherwise they don't take effect and the swiffy canvas will fill the screen. Change it to "width: 407px; height:400px;" and it works.
Related
I have a QML GridView, with a huge number of simple icons in it. The number can be in the millions, but only around a thousand will be visible at the same time, and there are only a few dozen types of images, so I guess they should be cached well.
If I use PNG images, everything is fine. The startup time is relatively long, but after everything is rendered, the application runs fine even on low-spec machines, and scrolling / resizing / zooming in the GridView is also fast and smooth.
However, if I use SVG instead, it slows my system down significantly. Even after everything is rendered, the responsiveness of the application is horrible, even GUI elements unrelated to the GridView are showing significant lag, the mouse cursor can barely be moved, etc. I thought after they are rendered, SVGs are presented just as any other image. Why must the CPU be busy if I don't even interact with them? And, most importantly, is there anything I can do about it? The same thing happens if I have SVG images containing nothing but a single rectangle, and use the same image in every cell. So it must mean the objects themselves are doing something.
"The number can be in the millions" and *"The startup time is relatively long"- those statement warrant a discussion about the design of your data model and bitmap caching strategy. But you didn't provide any code. So the following is a guess.
I'm not sure if you are loading the SVG images in C++ code or through QML, but I suspect you aren't setting the sourceSize (width and height) properties when you import your SVG. Hence, it's getting mapped into memory at a much larger size than it's getting rendered at. That is, it's eating up a lot more memory than it was with pre-sized PNG files. Or perhaps it's getting mapped in at a smaller size and Qt is is spending a lot of time having to resize these images at runtime as it scrolls in/out of view.
Open up one of your SVG files with notepad and look at at the attribute to see what the import size is.
In any case, try making sure your sourceSize.width and sourceSize.height match your render width/height.
Image {
id: icon
anchors.centerIn: parent
source: "cloud.svg"
sourceSize.width: 50
sourceSize.height: 50
width: 50
height: 50
}
Loading SVG's is an expensive operation...
Gridview manage dynamic objects.. creating visible items and destroying invisible items each time ....so, must render SVG each time you move the grid
One very bad idea is use that:
GridVIew{
cacheBuffer : 6000
//create 6000 items ...long startup time and memory expensive
...
}
This is a much better option:
Image {
id: icon
asynchronous : true //load image in asyncronus thread
sourceSize.width: width //scale as item size
sourceSize.height: height //scale as item size
...
}
If the load is too slow, you can add something like "LOADING..." text in the item background...
So as far as I'm concerned, overflow:hidden does hide the scrollbar, but makes it impossible to scroll (at least scrolling doesn't work in Firefox).
I have a scroller-slider on my homepage - it scrolls automaticaly to lower full-screen elements one by one and then comes back to the first element and starts over. It looks really nice in my opinion, but the scrollbar is visible - I would like to make it invisible. With overflow: hidden the scrolling mechanism doesn't work.
Any idea how to do it?
You can hide scrollbar with CSS - wrap your scrollable container into another one with overflow:hidden and less height/width (depending on scroll you want to hide - vertical or horizontal one). This way helps if you have static container/content sizes. If container can be resized or size depends on content - you will have to use JS solution to calculate container size.
there is a task to spread some raster cubes (PNG, with transparent background) along
the canvas based on Paper.JS platform.
I did it, however, there is a bug – canvas is bigger than browser window and when you are scrolling it to the right, animated cubes go glitchy, see attached screenshot. It seems that
the renderer doesn't clear previous frames. The same bug occurs in all browsers.
Is anyone knows how to overcome it? When I am trying to resize window and call onResize, everything becomes good unless I am not trying to scroll it again.
artefact image
Try using symbols instead of recreating the same rasters over and over:
In you 'building cubes' setup:
sprites[s] = new Symbol(new Raster(urls[s]));
and in hive():
var tmpRaster = sprites[selector].place();
Also, I believe paper.js tries to not animate off-screen elements to save on processing time. Instead of having the canvas be larger than the viewport, you may be better off using view.scrollBy(point)
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 having issues with all the animations on the page lagging when I choose to display this picture. I have tried displaying it with fadeIn, visibility, animate:opacity, display:block, and no matter which way I reveal it still causes the browser to choke. There has to be a way around this. (I've also tried preloading the image and it makes no difference!)
Is it just the size of the image?
http://jsfiddle.net/ZJpmT/2/
I suspect it is the image size. Doing a quick test showed that a fadeIn with a duration of 5 seconds, could be shown, but using a duration of 1 second wouldn't show any fade effect at all, but just show the the image at once.
Animating an image which is 1MB in size isn't what you want to do. If you really need this image to be that large, try to add a background to each frame, which matches the pages background and save it as JPG. That could reduce the size a bit, but it's not guaranteed that it will stop the browser from choking.