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 ...
Related
I am working on improving the performance of a complex React app with many components. The app loads user created "lists" (details unimportant) each item of which is rendered as a React component. If there are very many items in the list, performance begins to suffer.
If I run the Chrome profiler while not interacting with the app whatsoever, the performance profile looks like this:
As you can see, during much of the idle time, the CPU appears close to maxed out "rendering", though almost no actual painting is occurring. This only occurs when the list is so long that it overflows the screen. Why does this happen and what is the cure?
I don't know exactly why Chrome behaves this way, but it appears that the more content is outside of the viewport, the more CPU cycles Chrome spends on this rendering process. It turns out this can be fixed by using the CSS property:
content-visibility: auto;
Basically what it does is tell Chrome not to bother doing the complex work of rendering elements with this property set if they are off-screen. It simply reserves space for them (in much the same way as visibility: hidden does). More information here.
In my case, as soon as this property was applied to the <li> elements in the list, the idle rendering process observed in the Chrome profiler almost completely stopped, and the app became significantly more responsive.
Note that if the height of the content is not set, you need to also set the contain-intrinsic-size property, which is your best guess at the vertical space the element will occupy. Chrome will use that until the element is scrolled into view, at which point it will work out the actual height.
One caveat: it seems that Chrome (and I assume other browsers that implement the property) will not recalculate the size of elements with this property set, even if they are on-screen. Thus I needed to set content-visibility: visible on those <li> elements where the height might need to change dynamically.
While that did the trick for me, I'd love to hear from anyone who knows why Chrome does so much work for offscreen elements even while the application is idle.
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.
I'm an engineer and we are currently porting our Red5 + Flash game into a Node.js + Easeljs html5 application.
Basicly: it's a board game, not an rpg. The layer system means we have multiple canvasses, based on functionally. For example there is a static background stage, with images. There is a layer for just the timers.
At default, all canvas size is 1920x1080, if needed we downscale to fit to the resolution.
The first approach used kinetic.js, but the performance fallen when the game got complex. Then we switched to easel, because it's abstraction level is lower, so we can decide how to implement some more function, not just use the provided robust one.
I was optimistic, but now it's starting to show slowness again, that's why I want to look deeper inside and do fine performance tuning. (Of course everything is fine in Chrome, Firefox is the problem, but the game must run smoothly on all modern browser).
The main layer (stage) is the map, contains ~30 containers, in each there is a complex custom shape, ~10 images. The containers are listening to mouse events, like mouseover, out, click. Currently, for example on mouseover I refill the shape with gradient.
Somehow, when I use cache, like the way in the tuts the performance get even worse, so I assume I'm messing up something.
I collected some advanced questions:
In the described situation when can I use cache and how? I've already tried cache on init, cacheUpdate after fill with other color or gradient, then stage.update(). No impact.
If I have a static, never changing stage cache doesn't make sense on that layer, right?
What stage.update() exactly do? Triggering the full layer redraw? The doc mentions some kind of intelligent if changed then redraw effect.
If I want to refill a custom shape with new color or gradient I have to completely redraw its graphics, not just use a setFill method, right?
In easel there is no possibility to redraw just a container for example, so how can I manage to not update the whole stage, but just the one container that changed? I thought I can achieve this with caching, cache all containers the just update the one that changed, but this way didn't work at all for me.
Does it make sense to cache bitmap images? If there are custom shapes and images in a container what is better? Cache the container or just the shape in container.
I found a strange bug, or at least an interesting clue. My canvas layers totally overlapping. On the inferior layers the mouseover listening is working well, but the click isn't on the very same container/object.
How can I produce a click event propagation to overlapped layers those have click listeners? I've tried it with simple DOM, jquery, but the event objects were far away from what canvas listeners wanted to get.
In brief, methods and props I've already played with bare success when tried tuning: cache(), updateCache(), update(), mouseEnabled, snapToPixel, clear(), autoClear, enableMouseOver, useRAF, setFPS().
Any answer, suggestion, starting point appreciated.
UPDATE:
This free board game is a strategy game, so you are facing a world map, with ~30 territories. The custom shapes are the territories and a container holds a territory shape and the icons that should be over the territory. This container overlapping is minimal.
An example mouse event is a hover effect. The player navigate over the territory shape then the shape is getting recolored, resized, etc and a bubble showing up with details about the place.
Basically, maximum amount of 1-3 container could change at once (except the init phase -> all at this time). Not just the animations and recoloring slow in FF, but the listener delay is high too.
I wrote a change handler, so I only stage.update() up on tick the modified stages and the stages where an animation is running (tweenjs).
In my first approach I put every image to the container that could be needed at least once during the game, so I only set visible flags on images (not vectors).
Regarding caching:
There are some strange caching-issues, somehow the performance can drop with certain sizes of the caching rectangle: CreateJS / EaselJS Strange Performance with certain size shapes
(2) Depending on how often you call stage.update();
(3)
Each time the update method is called, the stage will tick any
descendants exposing a tick method (ex. BitmapAnimation) and render
its entire display list to the canvas. Any parameters passed to update
will be passed on to any onTick handlers.
=> Afaik it rerenders everything if not cached
(4) Yes.
(5) No. (I don't know of any)
(6) If the content's of the container don't change often, I'd cache the whole container, otherwise the container will be reconstructed every frame.
I have a question though: Why do you use multiple canvases? How many do you use? I could imagine that using multiple canvases might slow down the game.
How many sprites do you use in total?
2: if your layer or stage doesn't change, don't call stage.update() for that layer (so it doesn't gets rerendered, gives me a much lower cpu!)
For example, keep a global "stagechanged" variable and set this to true when something has changed:
createjs.Ticker.addEventListener("tick",
function() {
if (stagechanged)
{
stagechanged = false;
stage.update();
}
});
(or do you already use this, as stated in your "update"?)
4: I found a way to update for example the fill color :)
contaier1.shape1.graphics._fillInstructions[0].params[1] = '#FFFFFF';
(use chrome debugger to look at the _fillInstructions array to see which array position contains your color)
5: I found a way to just paint one container :)
//manual draw 1 component (!)
var a = stage.canvas.getContext("2d");
a.save();
container1.updateContext(a); //set position(x,y) on context
container1.draw(a);
a.restore();
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 have an element, with a child container which is initially hidden. When I hover over the parent, the child should be displayed. Simple.
Now, for real browsers, I want to add some flair and have the child fade in — while still keeping basic functionality for non-CSS3 compliant browsers. For old browsers, I simply toggle display, while I animate the opacity for all the kids with cool browsers. Should be a simple operation, right?
To my great surprise and disappointment, this is kind of buggy.
In Firefox, when I hover on, the child element switches to being fully opaque, before fading out. But hey, I want it to start as fully transparent, and then fade in!
In Webkit, the animation does not trigger — only the display toggle.
In IE (including IE10 PP) it also simply toggles display (as expected, though I had hoped it would animate in IE10).
In Opera everything works swell. <3 <3
Now, if I remove the display:none; from the initial declaration, the animation works beautifully in Fx, but then I will have problems with uncool browsers, which is sadly predominant among the visitors of this particular project.
Since I possess the powers of Modernizr, I can simply make a conditional style so that I use the display toggle only on the silly browsers, and life is great again, but the question remains:
Is this a bug in Fx/Webkitz, or is it intentional?
Here's a fiddle for you to look at: http://jsfiddle.net/TheNix/q5bAZ/4/
The problem is that transitions happen on computed value changes, and browsers don't compute values for most properties when display: none is set.
There is some ... lively discussion about what the spec should say about this. See the thread starting http://lists.w3.org/Archives/Public/www-style/2011Dec/0353.html and going over the last 4 months or so.
Simply omit the display declaration and add
-moz-opacity: 0.5;
-khtml-opacity: 0.5;
filter: alpha(opacity=x); // x = 0 ... 100.
Now with targeting the IEs and other older browsers, you should be fine.
If you want to be extra-accurate you put the filter into an extra IE-stylesheet so you don't invalidate your stylesheet with stupid IE-stuff. ( But with proprietary prefixes only xD )