So we have this major project and we aim to create a simple wayfinding system through the use of inline SVG that includes zooming and panning feature and is targeted to be deployed on touchscreen units. We wanted to create something similar like google maps or something like this: http://bl.ocks.org/mbostock/3892919
We really wanted to use this plugin but everything are predefined in the script and we really don't know how to do it on inline SVGs (or maybe someone help us explain how the whole code works and maybe teach how to make it work on inline SVGs because we're pure amateurs.). I've looked for a lot of plugins but they all seem to not fit the need.
When in doubt, just scale/move everything.
Zooming essentially involves making the elements bigger/smaller
according to your zoom level and panning involves making the elements
move in relation to your viewport.
So:
On each zoom level, iterate over all your paths and scale them by the
appropriate coefficient.
For panning you can just translate(move) your SVG elements to the
opposite direction of which you are panning towards.
You can learn more about scaling/translating SVG elements by having a look at: SVG transformations
On the other hand some Googling(meaning the 1st result that pops), turns this neat library, which looks pretty straightforward for your purposes.
Related
I'm trying to build myself a very simple framework to manage drawing content to the same webgl canvas via multiple views and react. I want to able to use the same resource in different areas of the window, so i'm trying to avoid using multiple canvases.
The end result should be something like this example from three.js.
I'm pretty confused with how to manage this from the html side and am struggling to figure out if any limitations of this approach should be considered.
<WebGLContext.Provider value={contextState}>
<canvas ref={canvasRef} style={canvasStyle} />
{children}
</WebGLContext.Provider>
This is my top level wrapper. With this, i can instantiate a <WebGLView/> wherever and get the rectangle to be used as the "viewport" into the canvas. Just like in the example i scissor out that rect and draw some content there. Because my entire react app renders on top of this, i can put any content over that view. But... i can also obscure it. This only works if divs above it are transparent, or there is hardly any overlap between these viewports.
The view is something like:
<div ref={viewRef}>
{children}
</div>
Another approach that i had in mind is to use react portals to manage another layer, above the canvas.
Something like this:
<WebGLContext.Provider value={contextState}>
{children}
<canvas ref={canvasRef} style={canvasStyle} />
<div ref={aboveCanvasPortal}/>
</WebGLContext.Provider>
Since i know the rectangle of the viewport for my webgl drawing, i can manage the html above it in a similar way, draw an absolutely positioned div in it, and put some UI content in there. This also doesn't feel like it would scale very well, but i could at least have a scrollable column with a background color, a webgl view in it, and some ui on top of it. Overlapping components would probably crash this.
The view is something like:
<div ref={viewRef}>
{ReactDOM.createPortal(children, aboveWebgl)
</div>
I've been thinking of using toDataURL() and then passing it as an image background to the views. This seems like it would solve the stacking/overlapping issue, and i could have a very simple html structure. But this is also a tremendous amount of overhead to add to webgl? If so, is there a way to do it cheaper, since the browser has to compose all of this somehow anyway?
Use case wise, my main use case is to use it with something like react-mosaic, where i just have a bunch of rectangles, very flat within one viewport, a div or the window. The second approach feels like it would work best. And then perhaps if i put a modal on top of that, creating another layer of below,canvas,above, html, would make sense, but like no more than that?
When taking a deeper look into the code of the three.js example you have provided, you will note, that there's just a simple <canvas id="c"></canvas> without any wrapping at all.
The key to your question is not to think primarily about viewports, but about Scissor Boxes -- as used in the aforementioned example in its function render(). If you prefer (like me) to use raw WebGL instead of three.js, take a look at the MDN Doc on WebGLRenderingContext.scissor() and on basic scissoring as a starting point.
That should reduce the complexity of your problem and return it back to the level of (a more performant) WebGL, instead of trying to patchwork on HTML level.
So... I have some sets of 6 pictures, like these http://www.humus.name/index.php?page=Textures , and I basically want to render them on an html5 canvas like this: http://www.allforthecode.co.uk/aftc/forum/user/modules/forum/article.php?index=5&subindex=4&aid=303
But I'd rather not use any 3d library such as webgl or three.js, since that's the only 3d-related feature I need and I want the whole thing to be as lightweight as possible.
I thought, "c'mon, it's just a rotating cube, can't be that hard!"
WRONG.
My original planwas to keep the camera position fixed, ant then to keep track of the x and y offset (in radians) of each vertex, and then to project them on my canvas and to deform the context accordingly to render each face of the cube.
That approach doesn't seem to work, tho, so... can someone give me a pseudocode algorithm?
I think a good way to tackle this problem is to use CSS3 3d transformations. There's quite a few turorials to be found on the web giving details on how to build a 3d cube with CSS. Instead of using <div>s to build the cube's sides, you could use <img> or even <canvas> elements. By playing around with perspective attributes you should be able to place the 'camera' inside the cube looking out.
I'm implementing a HTML5 game using canvas. Now I'm thinking about making all text overlays like tooltips, speechbubbles, infowindows and so on using HTML elements with position absolute over the canvas. So I can use many effects and transitions CSS3 offers.
But I'm not sure about performance. These overlays have to be added and removed frecuently (is something MMORPG like, so there will be a lot of speechbubbles and so on).
There are probably 2 questions regarding performance:
DOM traversal to add/remove. Maybe a cache can help?
HTML and CSS3 itself.
The other option is to manage these elements in the canvas itself, drawing them each frame. But maybe I have then again a performance penalty, because of the extra code, timeouts and stuff I would have to add, to achieve similar effects like in CSS3. And traversal of some data structure would be needed anyways.
Any advices, opinions, experiences?
Thanks in advance.
Consider using only one of the mentioned two technology. May be you can release that application in mobile or tablet. I think on these devices would be issues with handling both the same time. And another thing: if you stay in canvas there would be no worries about compatibility. Its not a techy but a thought-provoking answer.
The single best reason for using the DOM for UI elements in HTML5 games is event handling.
If you draw everything on canvas you will need to write your own logic to handle clicks and decide what has been clicked on, which can soon become very complex, expecialy if you have multiple layers of interface.
With DOM elements (especially when using a library like jQuery) this is trivial, and you can create a rich and interactive UI with minimal effort.
The only downside I can think of is that you may encounter browser inconsistencies, especially if using CSS3, but again jQuery will help with this.
I suppose another downside is that once you go down the DOM route, your game is always going to be a browser game, whereas if it was 100% canvas, there would always be the possibility of porting the code to another language and making it native, but I guess that would only be a downside for some people.
One way to approach this is to use a "dynamic" image map behind your canvas object. Then you can use the dom as required. Note you will need to pass the clicks on the canvas through to the image map.
Bit of background
I've been producing a Flash-driven webcomic for three years now, incorporating some basic animation, a synced soundtrack and zoom-drag page viewing. The recent Flash-bashing, my desire to reach iHandhelds and my preference for open versus proprietary means that I want to make the move to HTML5 techniques this year. In the long-term, I think the writing's on the wall for Adobe's product, and I'm not entirely convinced that's a bad thing.
I'm relatively comfortably with both CSS and HTML, having worked a little in web design before. However, JavaScript is a foreign country to me, and I simply wanted to get some advice as to
whether what I want to achieve can be accomplished consistently across all browsers and
what the best techniques/approaches to the problem would be.
Any advice, even general principles, are very welcome. I've already sought out several HTML5 tutorials and introductions, which lead me to believe that the canvas element will be foundational to my plan; however while all the individual problems I face have been answered by many blogposts and guides, combining the various solutions into a single entity is something I'm not currently able to figure out, as I'm not certain of the limitations of the new HTML5 tags, or of best practice.
If I'm successful in achieving what I'm after, I'm going to post the full code online with an explanation of all the elements. Webcomics might not be a huge domain, but having a resource that did this would have made my life a lot easier - hopefully it'll help someone else in a similar position.
What I'm after
Here's a diagram giving the basics of the design requirements. I'll explain the elements, and the desired extras, below.
(Perhaps the simplest way to demonstrate what I'm after would be for interested folks head over to my website and see how my comic currently works. This isn't a plug - it would simply give the quickest insight.)
At core, I'm after a viewer that will:
display text (SVG image) in a canvas element above an raster image the page's panel art
both images should be zoom-and-draggable in sync but should ideally fade in separately, with the raster image coming first, followed by the SVG image
I'm guessing that the best way to accomplish this would be to layer two canvas elements one above the other using z-index, with the SVG file in the uppermost element. These could then be nested, as in the diagram, within a div element that would carry the zoom-drag function. Is this a reasonable approach, or are there more efficient options?
The next and previous buttons are self-explanatory. Would it best to have each page (bearing in mind some will involve animation and music) on a separate page, or to have all pages within a chapter on a single page, with the buttons making them visible progressively? I imagine this would have a great impact on loading speeds.
Finally, I'd like to have the viewer capable of displaying fullscreen if the reader desires. I imagine this could be accomplished by using Javascript to make the canvas elements and their surrounding div switch between different CSS giving a px-defined size and 100% height and width. Is this a good approach? Is it possible to apply the size change to the div element only and have the canvas elements automatically follow suit, possibly by defining their size via % in CSS?
Desired extras
At various points in the comic I make use of basic animation techniques - simple movements of layered raster images across the viewing pane. This would be simple to accomplish, I imagine, using Javascript; am I correct in thinking that applying overflow:hidden to the wrapping div will prevent images larger than the viewing area from spilling outside the viewer area?
I also want to synchronise audio with some of these animations. I understand that synchronising canvas events with the audio would be the best way to do this on, permitting both to begin activity only upon page loading or next button click.
That's about everything. As said, any advice at whatever level would be greatly appreciated, even if it's 'yes' or 'no' to the various questions I've asked. At root, it would also be good to know if HTML5 is the best option for what I'm after or whether (with gritted teeth) I should stick to Flash for now and go after handhelds using Adobe AIR.
I'm developing a web application that has a certain layout.
I'm mainly using CSS for styling the buttons and using divs and styling them for other layout items.
The problem is that sometimes I need a layout item to be non-rectangular.
Also- designing SVG is easeer and sometimes may produce better results.
My question is: should I use CSS always for the layout, and for instance- combine divs to achieve the non-rectangular effect- or should I use SVG for some of the layout items?
Also- what about the buttons- CSS or SVG?
Thanks!
Bear in mind that SVG isn't supported in older browsers. In particular, in IE8 and earlier. Using SVG will therefore limit your audience.
It is possible to rig older versions of IE to support SVG - there are a number of Javascript libraries which can convert SVG into VML, which was Microsoft's proprietary alternative to SVG. However, this does mean you're running Javascript code unnecessarily; you could cause performance issues in IE, or worse, it could load slow enough that the layout redraws after its loaded.
Therefore, for cross-browser compatiblity reasons, I would suggest not using SVG for your basic page layout.
Where I would use SVG is for graphs and charts, etc. For these, I would use the Raphael javascript library, which makes drawing SVG very easy, and also renders it as VML in IE, without you having to do any explicit conversion.
For creating non-square elements in CSS, there is a hack which uses the CSS borders to draw triangles and other shapes. This works in all browsers (with some minor caveats in IE6), so is great for creating spot-effects like marker arrows and speech bubbles.
See http://jonrohan.me/guide/css/creating-triangles-in-css/ for more info on this.
Great for spot effects, but should stress that I wouldn't recommend it for complex shapes; I have seen some people drawing entire pictures using it -- see http://www.cssplay.co.uk/menu/fivestar and other hacks on the same site -- but as I say, I wouldn't suggest actually doing this, except just to demo a hack like this guy.
Hope that helps.
[EDIT]
Per the OP's comments, he only wants to add a rectangular protruding part to a larger rectangular <div>, so in fact the shape he's trying to create isn't all that complex after all; in fact, it sounds a lot like a tab. Given this, the best recommendation by far is to forget about drawing it with SVG, and simply create two divs: one for the main content and one for the tab. If necessary, a third div can be created to wrap the other two. This may be helpful for referencing the two others together via CSS or Javascript.
I tend to advise you not using SVG for the layout, it's not really its purpose. It's best suited for diagrams, pictograms, charts or maps etc.
using SVG will have disavantages:
-First, support: IE<9 doesnt support SVG, or you'd need an external plugin.
-Integration: it's easy to have SVG inside HTML, but emmbeding HTML in SVG is quite unpractical.
-flow in layout: you can draw shapes easily, but placing blocks/text has to be done manually. in html two consecutive blocks will be displayed one below the second. In SVG you have to place them absolutely, ensure text inside them isn't too long cause their size won't adjust automatically.
I'm almost sure it would be easier to layout with HTML+CSS. And now with CSS3 you can rotate blocks, round borders, cast shadow. I would like to know which particular layout cause you problems.
We are in 2017 now, I belive that all major browsers support SVG.
So I would say SVG is a good option. You will probably need to use JavaScript to adjust elements on the screen and make them responsive, because SVG does not provide things such as flexbox, tables, float, etc. The advantage with that is that you will have more flexibility and will not have to deal with the limitations and side effects of CSS.