Introduction
I'm currently developing a small drawing application similar to MugTug's Sketchpad. There's one pretty annoying issue I haven't managed to get around yet, though.
Drawing Algorithm
My basic draw algorithm is similar to the one used by MugTug. Basically it just stamps images using drawImage while the user is drawing. There's one serious handicap. The algorithm begins to fail with low alpha.
You can see this easily in the MugTug's tool by setting brush settings in the following way: diameter -> 100, hardness -> 1, flow -> 100, opacity -> 2 (1 is too small! bug in the app?).
There are two main issues: 1. Visible banding. 2. Color shifts (give different colors a go to see how this works...)
Questions
Could the issue have something to do with color precision? It seems to me the Canvas API treats colors using 8 bit channels (ie. 0-255). Is there any way around this limitation? I would prefer to use pure float colors (0.0-1.0) instead if possible.
Any ideas on how to deal with this are welcome. If color is indeed limited to 8 bit channels I guess I'm out of luck...
This problem seems entirely due to color precision. I think most Canvas API implementations use 8 bit RGBA channels. 1% or 2% opacity means that you are applying a very small amount of color to the image, only about 2-5 levels of difference - so even after a lot of repeated applications of the brush, any colors you use will end up being quantised down to a smaller number.
You could make your own a floating point canvas and copy it into a normal canvas after every change. That will make the problem completely unnoticeable for most operations. You'd have to implement your own drawing operations (not too bad if you only use drawImage) and they are likely to be slower than the canvas ones.
Do you see similar issues on MugTug's Sketchpad?
I tried with a 4% alpha blue brush over an orange background, and there is banding and such.
If it does better than you code then you are doing something wrong.
I've always seen canvas working with 32bit graphics (24 for color + 8 for alpha) so I doubt this can be solved.
Related
I'll start with the pictures:
Comparison Of Different Publishing Methods From Flash CC
It seems like there is a huge difference between what's published by through Flash CC HTML5 with CreateJS and what's actually created on the program although they are exact copies (I'm not talking about the pose of the character)
The shapes making up the body parts are all triangles with a solid fill and no stroke.
However, in the HTML5 published versions it looks like all those shapes now have a thin transparent stroke around them in between each other.
Any explanation or official support is greatly appreciated!
UPDATE:
The accepted answer definitely improved some of the problem but unfortunately not enough.
Since it's a platform limitation, I decided to work around it by doubling up all the assets of every layer and minutely overlapping them as best as I can.
Here's a link of the work around being implemented if you wanted an update:
link
This is an unfortunate issue with Canvas. The SWF format actually draws lines with fills on both sides, which enables the SWF (and Flash/Animate IDE) to create seamless edges when drawing shapes with edges that line up. Canvas can not do that, so the antialiasing causes the effect you are seeing.
A possible approach would be to cache it at a larger size, and scale it down.
var bounds = character.nominalBounds; // Added by Flash export
character.cache(bounds.x, bounds.y, bounds.width, bounds.height, 2);
The last parameter is the cache scale factor (in this case it doubles the cache size). It will still draw at the expected scale though.
I made a quick sample to show the difference, and it does help. Note that caching is also a good way to get rid of aliasing on edges. You can download the sample here. Uses Adobe Animate 2016.
Plain shapes exported from Adobe Animate
Cached the shape container
Doubled the cache size
You also might want to consider dropping in a shape behind it that is closer to the color of the shapes, so if the edges show through, it is not the dark grey background.
I've spent several hours trying to work around this issue... when rendering really simple shape (ie. a cube with very low complexity) and using a texture map feature of Three.js, when you rotate the cube the image seems to be distorted while in rotation, and then you can see a line which runs across the surface of the cube which appears as distortion.
http://screencast.com/t/VpSPRsr1Jkss
I understand that is a limitation of canvas rendering - but it seems like this is is a really simple thing to do - rotate a cube that has an image on one face without the distortion.
Is there another canvas library or approach i can take? I was really looking forward to using Three.js for animating some logos and other elemnets - but we can't have distortion like that in a logo or a customer facing landing page.
Thanks for reading, I'm open to suggestions here.
I don't accept increasing the complexity of the face as a solution because that just distributes the distortion through out the face. I really just want to render the image to a flat surface and be able to rotate that object.
The distortion you see is because only two triangles make that plane.
A quick fix is to have more detailed plane.
If you are using PlaneGeometry, increase the number of segments.
If you are using CubeGeometry, increase the number of segments on the plane you need (2 out of 3).
It will take a bit of fiddling to find the best balance between a decent look and optimal performance (as more segments will require more computing). Hopefully for simple scene you'll get away with no major delays.
i want to make to make a granite like background like http://www.tivli.com/ with a gradient at the center. i have found how to do gradient with both in the w3c tutorials, but are there any tutorials on how to make granite backgrounds in html5 canvas or svg? Thanks.
The site you referenced actually uses a simple 'noize.png' and then uses css3 radial gradients to buildup that background. I know you already knew that, I'm mentioning this for future readers.
Given this fact, I'll assume in the rest of my answer you want to learn, not a copy-pasta solution.
I've given up on svg looong time ago. But in canvas it's easy and fun... (especially now flash is FINALLY officially dead. Hurray).
So as others have already suggested in the comments to your question, why not use a seamless noise image? (you know where to find one :P).
You could still embed this image as 'DATA' in the html(, HINT: even or even feed image-data straight into canvas that will render it as your 'noise.php').
But then.. you are right: what if you wanted to change the noize-size?
And you want to know how to make granite/noise anyway..
And is mathematically/programmatically describing this noise lower in character-count (file-size) than supplying a ready-made image(-fragment)?
Start UPDATE 2 part 1:
Actually, after some good night sleep I realized/remembered that visual noise is one of the BEST way's to determine randomness. Humans are notoriously good at finding visual patterns, even professionals use this (and as such this is also heavily used in cryptography where one would need -for instance- a useful one time pad).
Also see 'commander' Crockford's YUI-lecture 'Principles of Security' from 19m07s to 22m37s.
Now why is this important? Well ECMA-script (aka javascript) defines a loose Math.random() function:
"returns a number value with positive sign, greater than or equal to 0 but less than 1, chosen randomly or pseudo randomly with
approximately uniform distribution over that range, using an
implementation-dependent algorithm or strategy"
Re-read the italic/bold part and welcome yourself to reality: each and every browser (brand/version) has it's own random-routine!!
"But what does it mean?" Well.. simply put.. Depending on browser(version)'s ES-Script implementation (cough cough IE): Noise based on Math.random() will/might render visible patterns in your noise (independently of possible tile-size)!!
So for the rest of this answer we are going to assume either an ideal world where browsers spit-out proper random numbers, or that you took control and use a stronger 'predictable' random-solution as is discussed on this wonderful article that google's bubble accidentally leaked :)
End Update 2 part 1
So let's start with the radial gradient-part. You already figured that one out.
Ok, then follows the noise-function in canvas (you could you could do this before the radial gradient, but this order gives a nicer grain and diffuses color banding the gradient produces -on a average lcd you would see them anyway since they're not true color-) : this is done by generating random pixels.
There would be a lot of different algorithms to use, I've used a straight-forward one that you can understand without math..
Note that generating noise for a modern day full-screen resolution is easily larger than 1 mega-pixel in resolution, so this would be slow! To overcome this we need to generate and RE-USE a small seamless tile. We use this as a pattern-fill in our full-size image that already has the radial gradient.
I also assume you want the radial gradient liquidly placed in the middle of the view-port, so if you want to go the fixed way (as opposed to the noize.png/css3 way you referenced), you'll also need an extra eventhandler 'onResize()' to have canvas render a new background.
Why? Well if you where to let the browser scale this background-image (created upon page-load) automatically, then the nice grain-size of your noise would change to, EVEN leading to visible PATTERNS that you would not want..
(Since I desperately want to go to sleep now..): The rest is thoroughly explained in the source-code of the function I wrote for you..
Here is the link to the fully documented code I wrote for you: jsfiddle.net/sU74C/ and here you can see it in full-screen preview. UPDATE 1: function genNoise 80% FASTER!!
Use it if you like (retaining the link to this answer) or learn from it and do your own thing.
PLEASE DON'T FORGET to accept AN answer to this question (hopefully mine :))
Hope this helps!
UPDATE 2 part 2:
There are more way's to interact with canvas. One could also calculate/(re-)use/generate/save/import pixel-maps/array's (as png or base64 or jpg or ...) for instance, see this excellent article on faster 8bit and even faster 32bit (if the browser supports 'Uint8ClampedArray' as the type of the data property of the ImageData object) pixel-array's, including a proper solution to account for the endianness of the processor!!
So after giving this some considerable thought, it turns out that to do this 'right' is actually a challenge and should be divided in 2 parts:
Where do I get my noise-data (Math.random() or custom random or pre-defined external (image, json-string, random.com) or embedded (packed?) data)?
What is the fastest way to build/store/re-use this noise on full-screen size/canvas.
Given the statements in part 1 of this update and that we don't want patterns in our visible noise, I'm starting to lean to using some pre-rendered 'random' noise data (meant to tile seamlessly) that is embedded in the noise-generator: otherwise there is the overhead of running your own none-engine-optimized random function (times..a lot..).
Also I think one might get away with just black and white and transparency afterwards.. This might considerably speed-up things up AND reduce embedded pixel-data.
Think about it: black or white equals 0 or 1..
In base 64 one character can represent 6 bits. So a 30x30px image has 900 px divided by 6 bits = 150 characters (sweet-spot increments by 6px, so next is 36px*36px is 216 characters).
I'm working on a 2d tile based HTML5 canvas application and I would like to know what kind of special effects I can apply to the images as their being drawn ( context.drawImage(...) ). The only trick I've come across is modifying the canvas.globalAlpha value. This leaves some color from the previous frames, creating a blurring or dazed effect if things on the canvas object are moving from frame to frame.
Is there something for rendering images that is comparable to setting the context.fillStyle to an ARGB value for primitive shapes?
Is there a multiply mode? ie: multiply the image pixel color by the destination color. This could be used for primitive lighting. (I've toyed around with context.globalCompositionOperation but didn't find anything interesting)
Are there any other cool effects you've come across?
NOTE: I don't want to use WebGL for this application, and it's a game. That means it's realtime and I can't modify each pixel with javascript code because that takes too long. (although I could probably do that when the player dies and nothing is moving on the screen anymore)
Canvas doesn't provide any predefined effects.
To manipulate the image shape you can use matrix transformations.
To manipulate the image pixels and colors you should use getImageData method - http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#pixel-manipulation.
Then use google to find algorithms to apply some effects like swirl, blur, emboss etc.
I am drawing a sprite (of a ball) on a canvas element. As the ball moves however, the x or y position of the ball may become a fraction, eg. (20.153; 63.638). When canvas is used to draw this image, it attempts to use transparent pixels to make the ball appear in it's position more accurately.
I was wondering whether I should use Math.round() before drawing the ball to avoid the transparent pixel stuff, and possibly speeding up the game a lot. Will this help much? The game is a sorta complex pong game.
The image below should help with my explanation:
At least this guy seems to believe so. As Gabe mentioned, it depends on the implementation.
Note that some sort anti-aliasing seems to kick in if you are using regular coords (1, 14, etc.). For this reason some guides (Dive Into HTML5 mainly) seem to suggest that you are better off by rending using half pixels (ie. 1.5, 14.5, etc.). I don't know if this makes any difference to performance, though. It's noticeable on render result at least.
You might also want to experiment with various layering schemes. See this question for more information. Depending on your situation you might want to treat your objects as separate canvases even and just offset them on top of the background.
Alternatively you could try to render it all on one canvas. In this case you have some extra stuff to keep track of. This library seems to handle all the bookkeeping for you.