//code 1:
var texTransparent = cc.textureCache.addImage(res.textureTransparentPack_png);
this.spriteSheet = cc.SpriteBatchNode.create(texTransparent);
//code:2
this.spriteSheet = cc.SpriteBatchNode.create(res.textureTransparentPack_png);
both the statements are working well, i don't know when to use textureCache and when not ?
Both variants should be OK, as the second one will search texture cache too. For the sake of simplicity, personally I'd use the second one. Regarding the question, don't use texture cache if you're not sure. Cocos will cache textures for you under the hood.
Related
When hiding nodes, the performance seems to slow down quite a lot with larger IFC HVAC models (80000 nodes and upwards). On a standard computer this takes almost 10 seconds. I have two models and want to hide one of them. Currently this is done with rootId. Is there any modifications to be made to make this faster? What would be the fastest way to hide all the nodes?
var vm = new Autodesk.Viewing.Private.VisibilityManager(viewer.impl, viewer.model);
var instanceTree = viewer.model.getData().instanceTree;
var rootId = instanceTree.getRootId();
vm.hide(rootId);
vm.setNodeOff(rootId, true);
When showing parts of the same file, with few thousand nodes this seems to be quite a bit faster. Eventhough the nodes are shown one by one.
var totalNodes = nodesToIsolate.length;
for (var i = 0; i < totalNodes; i++) {
vm.show(nodesToIsolate[i]);
vm.setNodeOff(nodesToIsolate[i], false); // True = hide completely
}
So you are saying that the second approach is quite faster than the first one... in that case what prevents you to use the second approach over the first? You could traverse the model structure from rootId to determine all the node and then use second approach, or am I missing something?
I am guessing that a faster approach would be to affect a custom ShaderMaterial to each fragment of the model and control the visibility from the shader code, however traversing the model to affect the material would also take time, but the operation could potentially be performed at an earlier stage.
Also you could completely unload the model from the scene with viewer.impl.unloadModel(model), obviously if you need to restore it later it will take time.
If I understand well, an EdgeIterator can be used only one time. If this is correct, why can't we simply reset it to avoid creating a new instance of EdgeIterator each time we need to loop over the same node edges ?
Thanks !
The EdgeIterator is reused if you use the EdgeExplorer:
// store somewhere
explorer = graph.createEdgeExplorer();
// use somewhere
EdgeIterator iter = explorer.setBaseNode(x);
while(iter) {..}
Still be very careful with this as you need one edgeExplorer for every thread and every loop e.g. having a double for-loop with one explorer will fail :)
I faced difficulties to replace a string.
var expression:String = '2X3';
var inString:String = expression;
inString=inString.replace("รท","/");
inString=inString.replace("X","*");
trace('Result.....',inString);
Output:-
Result.....2*3
Its alright.
But the problem was when i tried to give input as
var expression:String = '2X3X3X4X5X6';
output:-
Result.....2*3X3X4X5X6
But i need it in form of
Result.....2*3*3*4*5*6
and same for division.
Thanks & Regards
I use this for replacing all
var result:String=inString.split("X").join("*");
I know you've already selected a answer, but it lacked an explanation and a proper solution. The reason you see this happening is that String.replace(), when the pattern is a String, only replaces the first result. The solution is to use RegEx:
var expression:String = '2x3X3x4X5X6';
var result:String = expression.replace(/x/ig, "*");
trace(result); // output 2*3*3*4*5*6
The pattern uses two flags, global and case-insensitivity. That will grab all instances of the letter X, regardless of case, and search the entire string. The benefit with RegEx is that is extremely low level. There is little-to-no overhead when using a regular expression meaning they are incredibly fast. String.split and String.join use loops to function, I believe, which are considerably slower. Additionally, you have to store an additional array in memory.
Granted, these are negligible in most cases (difference in the 10's of microseconds, maybe), but not all. I had a project the required files to be scrambled. Unfortunately, the files were too large (200MB minimum) and the doing the replace().join() method was 4-5 slower than the RegEx method. With RegEx, I managed to reduce the lag while scrambling from a few seconds to 2-3 frames.
did you try inString=inString.replaceAll("X","*");? notice the "All" suffix!
I think of 2 approaches referring to some visual element like movieclip. So suppose i have b_mc ( name="b") lying inside a_mc on the stage :
1st approach :
var mc:MovieClip = a_mc.b_mc
2nd approach :
var mc:MovieClip = a_mc.getChildByName("b")
I generally use 1st approach. What can be good reason to go for 2nd approach. It sometimes seems useless to me, as it involves extra overhead to name the movieclips, when used dynamically.
Thanks
V.
a.getChildByName('b') is slower than getting a.b.
If you don't need to use names it makes no sense to use it, however some programmers might make use of the name, especially when generating content dynamically rather than through the Flash IDE, in which case having this function is helpful, so that the display list doesn't have to be traversed by a custom function (which it does with internal function anyway, ergo it is slower than a.b)
getChildByName is needed if you add something dynamically to a movieclip. For instance:
var mc1:MovieClip = new MovieClip();
var mc2:MovieClip = new MovieClip();
mc2.name = "foobar";
mc1.addChild(mc2);
trace(mc1.foobar); //undefined
trace(mc1["foobar"]); //undefined
trace(mc1.getChildByName("foobar")); //[object MovieClip]
I usually do mc1["foobar"] when referencing objects since that way it's easy to work with items such as mc1["foobar_" + i];
I rarely never use getChildByName since that requires a manual cast whenever you try to pass something as a movieclip/textfield or whatever :)
However, if you do create the instances from the flash editor, then I would usually reference them through some exported class and access them through
mc1.mc2.mc3.optionsView.visible
If you have a list of objects that you need to go through programmatically, getChildByName is great. It would assume you've also named them in some programmatic way to reindex them in the for loop. I can also think of a couple other good ways to use this, like pushing the names or objects in an array, so they wouldn't have to be related, just all have some property or method in common.
for(var i:int = 0;i<numOfMC;i++) {
theParent.getChildByName("child"+i).doSomething();
}
I would like to know what's the difference when I write a temporary variable like this (these are just examples):
version1
for each tempEnemy in enemyManager.enemies {
var tempX:int = tempEnemy.x;
}
or this:
version2
for each tempEnemy in enemyManager.enemies {
tempEnemy.oldX = tempEnemy.x;
}
What's wrong and right? Currently I write it like version 2 and I'm not sure if I should change it to version 1. Can someone help me out with this please? I know most developers write like version 1 but I'm a little bit confused because I am totally unaware about version 1. If I use version 1 does that mean that my value is stored explicitly in a temporary variable that is cleared in every cycle?
Also...
Adding the :variableType (int, String, Number etc) aids in code hinting and debugging.
In version 1 the declaration:
var tempX:int
defines a variable that lasts only as long as that iteration of the for (or for-each) loop it's in. Each iteration tempX is defined, given a value from an Enemy object, and at the end it is left for garbage collection.
In version 2, you reference two variables attached to an Enemy object referenced by the temporary variable named tempEnemy.
In both versions the reference to the Enemy object, tempEnemy, is reassigned the next iteration's Enemy object.
Each method has its advantages. From a memory standpoint, version 2 is probably better, since it changes an existing variable over and over rather than creating a new variable that's discarded at the end of each iteration. On the other hand, version 1 doesn't require you to have oldX defined in its class variables, which can often get mucky enough without these sorts of variables.
Best practices with code are based off of (a) working with other programmers, who need to be able to read and understand the code, and (b) leaving a project and coming back to it later, where you'll need to be able to read and understand your own code. For short projects you don't plan on sharing, version 2 is okay (and probably more memory-efficient), but any large project should use something more like version 1.
Another consideration is, are you going to use that variable anywhere other than the function where it is defined(set)? If not, you don't need to store it in the object, which points again to version 1.