I am using a JavaScript library called PIXI and am looking for a way to "zoom" in my game. A search on the internet suggested that I put everything inside a DisplayObjectContainerand then resize it to simulate a zoom-effect.
The thing is that I already have Container (aka stage), and I think that is resizable too. So I don't understand the reason behind using a DisplayObjectContainerwhen you have a Containeralready. And frankly, I don't even see the difference between them.
This page says the following about DisplayObjectContainer:
A DisplayObjectContainer represents a collection of display objects. It is the base class of all display objects that act as a container for other objects.
This other page says the following about Container:
A Container represents a collection of display objects. It is the base class of all display objects that act as a container for other objects.
The only possible scenario I can imagine is that one of these container-objects is outdated and belongs to an older version of PIXI, which isn't too unrealistic since PIXI is rather new and could change a lot. But this is just a guess.
The guess is correct. DisplayObjectContainer is outdated and replaced with Container.
Related
I extract several blocks that are spread across the page, draw them onto a canvas, via CanvasRenderingContext2D.drawImage(), and then I export the canvas to PDF/JPG.
Now, while drawing them, I also want to tidy their looks and/or remove/display parts of some blocks, because the styling no longer makes sense from a static point of view.
I can append a class on body, style blocks differently while body has that class, build the canvas, export it to a content type of choice and remove body class, but this makes the page look quirky for 1 - 2 seconds. (I could just cover the page with a loader, I guess)
I can clone the block, style it differently or apply whatever styling (inline or via classes) and draw an image from that, but this is not optimal.
Any idea on how to do this properly? I'm inclined to go for something like emulation. Have the whole "export styling" under the native #print and emulate that before drawing the blocks onto the canvas, without affecting what gets rendered in the browser, but I'm not sure if this is possible.
I know these don't answer your specific question, but perhaps these are viable alternatives to the problem.
It sounds like you're trying to make something printable. I assume this is triggered by a user interaction of some kind so...
This means you have a few interface options. For example, you could "hide" the screen by placing a modal over the entire thing with a message that says "processing just a moment". Then the body (or another element) class solution works.
You could copy the elements as you suggested. If you go that route I would move the copies off the screen while you change them.
.element {
position: fixed;
left: -100vw;
}
Without knowing how many duplicates you need to make it's hard to recommend this option.
Alternately, could you offload the effort to a service worker? This would require a copy into memory BUT its completely detached from the DOM and runs in a different thread.
It's a really interesting problem though!
I think you can use node.cloneNode(true) to make a deep clone for all these blocks, put them in a classname scoped common root that's hide away from user's view, then you mod their style secretly.
Since you mod the cloned version of nodes, the original remains untouched. Plus, using the classname scope, your css can target these clones accurately.
I have noticed that in javascript frameworks elements such as dialogs, tooltips and alerts mostly appear at end of body.
I'm making my own implementation of these elements and trying to make it failproof. I'm repeating some techniques like using transparent iframe to overlay embeded objects in old browsers, and so on.
What restrictions could I face if I place my dialog/tooltip somewhere deep inside of the DOM tree with {position: fixed}? I'm afraid if there are some dangers to this approach, because big frameworks never use it.
I want to support IE8+.
Aside from z-ordering that is a very valid point made by Teemu, another major consideration in JS frameworks is speed of execution / speed of lookup.
The DOM in JS terms is one large object. The deeper into an object javascript needs to go to get what it's being asked for, the less performant the script gets, take a look at this answer.
Therefore it makes sense to keep everything that is probably going to be cloned or deep copied at a sensible nesting level and in the correct z-order. That happens to be toward the end of the body and usually wrapped by at most one containing element.
There may be other reasons but the depth / nesting sprung to mind as a consideration I'd take into account.
Short answer - very few techniques like this are "always necessary". JavaScript can easily remove items from their natural position in the DOM and relocate them at will.
Long answer - I don't think approaching this from a JavaScript first angle is correct. Look at it in terms of where the content belongs naturally within the hierarchy of the rest of the DOM.
For example, if you are talking about a modal dialog, then the chrome (the container elements) usually do not belong within the rest of the DOM - they exist only to contain and provide modal overlay functionality for the content within. This chrome does not participate in the outline of the DOM and the rest of the content. In that case, unless you are able to load them separately via ajax or embed the chrome HTML within the JavaScript, then the closest you will come to removing them from the main DOM is to append them to the bottom of the main DOM content. Note that this disregards the upcoming TEMPLATE element (http://www.html5rocks.com/en/tutorials/webcomponents/template/) which is designed for just this purpose.
However, the content of your dialog might very well belong within the main content of the DOM - either as an element, or as an attribute (i.e. title or data-) to an associated element. This would especially be true for tooltip text.
Hi folks I'm using dojo tree with ForestStoreModel and ItemFileWriteStore. I'm seeking some out of the box way of adding tree items to the top of the Tree root. The default behaviour is to add items to the bottom of the tree. This is how I add stuffs on to the tree. (Dojo V 1.8)
this.model.newItem({ name:''+item.name+'', type: ''+item.type+''},parent);
answering this for future searchers. I'm quite new for js stuffs so I was mainly relying on DOJO API and documentations attached with them. I've tried to newItem insertion to a specific index using additional parameters as per the API. ie. (args,parent Item, insertIndex, before Item). I've also tried pasteitem method with these parameters (childItem , old parent Item,new parent Item,bcopy, insertIndex, before Item). Neither of them were successful. On the debugger, I tried to step in to these methods and found dojo treat bit differently when you pass root object as your parent object. So i've created a default root level element used that as the root element for my tree. Problem solved. All these functions started working. Unfortunately I couldn't find any documentation that specifies these functions doesn't support Root as the parent parameter. At least for these indexed based insertion purpose. I find it really strange though. I could be still wrong so may be some reader can elaborate on this later. Just putting this forward
I'm trying to figure out how layers in Ext work. The documentation is very concise and I can't find a lot about them anywhere else, other than a forum thread where Jack Slocum says they're very simple.
I have a working tree panel, and what I'm now trying to do is put that in a layer so it floats over the page (it's meant as a helper dialog that pops up next to a form element). I've only gotten as far as creating a simple layer with a <div> element in it, but can't get it to contain more advanced stuff. Looking at the Combo source, which uses a Layer for the option list, also didn't make me much wiser.
So, can someone with a little more experience on this subject please tell me: how are you really supposed to use Ext.Layer? Or am I "doing it wrong"? :)
An Ext.Layer is an extension of Ext.element, rather than being an extension of Ext.Component.
Ext.Element doesn't benefit from all the component config options and methods that say an Ext.Panel does, and so you're going to have a much harder time adding a tree panel to an Ext.Layer than if you added the tree panel to an Ext.Window which already benefits from shim and shadow (the two main reasons you would want to use an Ext.Layer).
But before I would resort to using Ext.Window to wrap the tree panel, I would take a look at the shadow config option in tree panel which should provide the 'floating' effect you want...
true (or a valid Ext.Shadow Ext.Shadow.mode value) to display a shadow behind the panel, false to display no shadow (defaults to 'sides'). Note that this option only applies when floating = true.
First off, I use the term "classes" to mean functions with prototypes that might be in a separate file from the main initializing file for what I'm working on.
Now for my question/issue:
I'm working on building something in JavaScript/HTML5, and trying to program it "properly" (ie. using prototypes with formats that are, I hope, standard). In my main JavaScript file, I have methods that have create use an instance (basically the root instance of my OOP/prototype based script) that sets up the canvas.
I also have another file that is loaded which contains a 'class' for creating clickable buttons. As of right now, I'm just trying to get the buttons to draw on the canvas, however, I can't access the instance of the canvas because I believe the instance is out of scope (which is fine, I don't want everything I do to contain a long dot-notation for referencing instances). However, this is giving me trouble when trying to draw a rectangle on the canvas, considering the 'class' the button is in, isn't able to reference the context outside of it.
I found a way around this by using something along the lines of:
function CreateButton(btn_x, btn_y, btn_width, btn_height, btn_txt) {
// ... (check and define parameters)
CreateButton.prototype.custom_canvas = document.getElementById('root_canvas');
CreateButton.prototype.ctxt = this.custom_canvas.getContext('2d');
CreateButton.prototype.ctxt.fillStyle = '#666666';
CreateButton.prototype.ctxt.fillRect(this.x, this.y, this.width, this.height);
}
Basically, it's writing on top of the canvas with a canvas of the same name? I'd assume that I can still manipulate the regular canvas afterwards and it would just act as if it was a single canvas element. I worried that redrawing on the canvas might use up a lot of memory when many things are added, however, no matter the method, writing on top of the canvas can't be avoided (even when in the same scope).
Any suggestions, or help? Or is my method of using the same canvas within a different class acceptable?
Thanks for any feedback.
[UPDATE]
Hmm, maybe I should try passing the context as a parameter and just using that.
...Or should I just make the canvas a global object? Any suggestions?
I guess you could try to implement some sort of "WidgetManager" that retains reference to canvas and your widgets. It will use a callback mechanism to render widgets. Each widget (ie. in this case Button) will have certain kind of rendering states (pressed, released) and some kind of internal state. Other widgets might have more complicated states.
Note that "WidgetManager" should probably keep track of widget "z" and user presses (which widget was hit). Based on this it should be able to trigger handlers bound to widgets. In a way you have to reinvent what basic UI libs do already. :)
I think you are better off by working out your design this way before moving into the implementation phase. A lot depends on what you really want to with it. :)
Note that you can simplify rendering and checks a lot by using multiple canvasii instead of just one. In this case you'll have to deal with z-index and absolute positioning but at least you get to piggyback on some of the existing stuff without having to implement it yourself.