I'm making an TV Guide. See http://i.tv/guide for an example implementation using Canvas.
I need to make lots of little boxes representing each show. I need to be able to scroll them around, both vertically (channels) and horizontally (time). To make it with Canvas, my understanding is that the only way to implement scrolling is to intercept the correct events, and redraw the canvas smoothly with new offsets many times a second.
If I were to use divs, I could slap scrollbars on it and let it scroll normally. I could position them once, and let the scrolling move them around, rather than re-calculating their new offsets.
Which should I pick for this kind of project? If I use divs will it be too slow? Some lineups have 500 channels. I want to display up to 4 hours at once.
Thanks!
I would strongly recommend using plain HTML in preference to canvas, for interactive elements. Apart from the speed issue (divs are usually going to be faster than drawing it all manually yourself), HTML is designed to offer accessibility and usability features for free, which you'd have to do a lot of work to get even partially from canvas.
The canvas-based guide as linked has the following drawbacks:
very slow to render/scroll, for me;
impervious to keyboard navigation;
no HTML link actions (like middle-click-link-to-open-in-new-tab or right-click-bookmark);
text not copy/pastable;
a dead loss for accessibility tools like screen-readers;
reduced browser compatibility;
invisible to search engines.
Use canvas for pretty graphical and interactive effects you can't achieve with plain HTML. To be honest I don't even see any of that on i.tv's site; I have no idea why they have implemented it in this seemingly-crazy way.
Doing it with DIV's wont have issues with speed. Browsers rendering engines are built to render elements. DOM rendering is faster than canvas rendering in a lot of cases, take isogenicengine they use DOM based rendering to render thousands of elements to make games You should implement it based on your technical ability. Both technologies will be able to do what you want. Personally I would choose canvas but I see no issue with DOM rendering.
Good Luck.
Related
I'm getting into web animations, WebGL, Canvas, ThreeJS, GSAP and all those fun tools. I'm investigating different websites and how they're able to achieve certain effects.
I am mind blown by these two sites: https://14islands.com/ & https://www.hellomonday.com/.
Their animations look simple(ish). Liquid effect on images. I know with ThreeJS filters or WebGL or other Canvas libraries you can achieve the effects. What I don't understand is that both of these sites have a full-sized <canvas> element fixed to the background. And render almost all the images on the site through the <canvas> rather than pure HTML elements.
This allows to have all images to have really dope effects. But what I don't understand is how can they sync the positions and sizes of the images with HTML DOM elements so perfectly?
This seems like a nightmare to code. Also wouldn't it be a huge performance burden to update every image on the canvas when the user scrolls or resizes the page?
I believe I'm missing something. Perhaps there's a library that handles most of this?
If there are any simple examples, I'd love to see them.
Thank you for your time :)
Welp turns out this can be done quite simply with ThreeJS. Perhaps there are ways as well but this seems easiest to me.
TL;DR: You can create a scene for a div, and you can do this multiple times with ThreeJS so that it renders a scene within the specified div.
Demo: https://threejs.org/examples/?q=multiple#webgl_multiple_elements
Code: https://github.com/mrdoob/three.js/blob/master/examples/webgl_multiple_elements.html
I am developing a website with React which has what we called "snippets", basically a modal window displaying some kind of media (audios, videos, slides, text quotations, pdfs). These media have "positions", as a page number, an image number, a playback position, or a scroll position. If she likes the user may store these snippets together with their positions in a "locker" and come back later to whatever is in there. Visually the locker will hold a "thumbnail" of the snippet representing the appearance of the snippet at the time of storing it. My question is how to go about making such a on-the-fly thumbnail. Two approaches come to my mind, however, if you have other ideas I am eager to hear them.
Component approach: Since I already have the component, I could reuse or rather clone it, scale it down, disable it for mouse interaction. Would React.cloneElement() be the way to go?
Advantage: Easy to do.
Disadvantage: Too many duplicates of potentially resource-heavy components may slow down website. Styling may become non-trivial as some embedded media (audio, video) bring their own potentially inaccessible styling with them.
Image generation approach: Since I only need an image, I could take a screenshot of the snippet area, scale it down and use it. Can this be done fully (from generation to usage) on the client side? Is there a good library which does the heavy-work for me?
Advantage: Resource-heavy only during the making of the thumbnail, resource-light in the locker. Accessible for any styling.
Disadvantage: Potentially difficult to do?
After some research I found a solution. Interestingly, it is a mixture of the two approaches I was able to think of. It is possible to access and rasterize the DOM elements which make up the snippets, draw them on a canvas and turn it into an image. The most popular library for this seems to be html2canvas, however, there are a number of others among which rasterizeHTML and html-to-image seem to stand out. Often wrappers for React exist, in the case of html2canvas, for example, use-react-screenshot.
A very common question, but almost all comparison I've seen is mainly focused on games with a lot of interaction.
What I'll be working on is a web application that manipulate objects one at a time. For example, the object can be either an image or a text, then it can be replaced, resized, rotated, zoomed in, and deleted.
If the manipulations applied to many objects, I know that canvas will be a better choice but here the manipulation only can be done one at a time to one object only. Each container will at most have about 30 object in it, and I'll be working on multiple containers (maybe around 20 containers) that will be hidden or shown depends on the interaction.
The question is whether to use Canvas or CSS3? What I'm looking is the performance issue and complexity of the app.
I don't have a lot of experience with canvas but as far as I know if you use it together with requestAnimationFrame the performance is pretty similar to CSS animations. You should also consider that CSS animations are very limited when it comes to working with complex animations.
I think there are two diffrent solutions for the problem:
1) First the solution shown by aves Engine, which renders the whole game with html elements and external stylesheets e.g. CSS3 transfomations. Pro's are that the event-handling is much easier when working with div's than by rendering on canvas.
2) Like isogenicengine.com shows you could render the game on html5 canvas element. Mabye that's the better solution, because rendering on canvas is the way that millions of 2D-games were written before and in future the industry will optimize the drawing methods e.g. with hardware acceleration. At the moment the contra is that rendering on canvas is slow if you would like to render in fullscreen. If you would like to render only in a specific area of 200x200px that's okay, but in fullscreen you get stuck with a framerate of 10fps.
What do you think is the better way to create a game for the web?
Thanks for your opinion!
PS: If you have some articles about the topic please paste some links
I don't think it's a clear one size fits all kind of thing. I really think it depends on what you want to do with your game.
If you are doing a lot of vector graphic manipulation, perhaps canvas is a better choice vs engine like aves. For tiled based, maybe aves will work better.
You can render fast on fullscreen canvas if you're clever about only re-rendering dirty regions. But if your whole canvas needs to change every frame this obviously isn't going to help much.
I've spent alot of time recently looking into this issue and my conclusion is pretty simple.
Use HTML Elements, lets say that HTML5 actually makes progress and in one year the major browser support it. How long does it then take to get the general user base of the web on the latest browser (IE6 still has a choke hold in some sectors). So making the game available to as many people as possible is key! (In my mind anyways)
If however, your looking to learn and develop, go with canvas.
What is the best cross-browser way to get a flat mouse coordinate input data and simple callback for mouse events for my rectangular game area on my web page, even when it has loads of larger and smaller images and text string overlaid haphazard onto it?
And what is the best way to insert or remove a text string or semi-transparent image overlay at an arbitrary location (and Z order, specified relative to existing objects) in a board game rectangle with cross-browser DHTML?
And how can I stop the user selecting part or all of my montage of images (I just want them to interact with it as if it was Flash), and can I stop the right click menus coming up in IE, FF etc?
I want to do this without Flash because I want something that will work both on desktops and on iPhone and potentially other mobile platforms too.
I appreciate there are serious limitations (eg less image scaling capabilities, not vector, no rotation capability) to what I can do if I'm not using Flash but I'm very interested to know what capabilities are available.
Are there perhaps any frameworks available to make it easier than coding from scratch?
Would J/Query be a good match for some of the requirements? What else do I need?
I would recommend Google Web Toolkit. It lets you program in Java, which gives you all the type-safety and nice IDE functionality that Java entails, but compiles to Javascript so that you can just run it in a browser. It also does a ton of optimization and supports tons of features.
jQuery is excellent at doing this. I used jQuery's UI and Ajax functionality to implement the frontend for a game of chess.
I made it a little easier by creating an 8-by-8 table with unique div names for each tile, so Javascript can access them by getting the elements by id. If you can't create something like that, you do have the option of placing elements anywhere on the page (either absolute or relative to a given element). You can also easily change the z-index, including when the use is dragging a piece or when they have dropped it.
As far as disable right click and item selection goes, that's something that I didn't figure out how to do. You might want to take a look at some other Ajax games like Grand Strategy, which are much more polished than my experiment and may have figured out how to do this.
There are two main APIs for working with arbitrary drawing and positioning on the web, Canvas and SVG.
Take a look at Chrome Canvas Experiments and the Raphael Javascript toolkit to see some examples and Javascript abstractions.
The key is element.style.position = 'absolute'. To illustrate just what's possible here's how far I've managed to push javascript (and from scratch at that!):
http://slebetman.110mb.com/tank3.html - RTS in DOM! Click on units/squads then click somewhere else to tell them where to go. You can control both sides.