No bitmaps, just screenshots of graphics I made with strokes and fills.
In the 12 years I've worked with Flash, I've created many graphics by using the line-tool or pecncil tool, manipulating the vectors and then filling in the colors and gradients with the fill tool. The box to the right is from the SWF and the box on the left is the same graphics on canvas in the browser.
The problem happens when using strokes.
Here is another example I just made:
I know this isn't a bug in Adobe Animate CC, I'm just VERY curious if it would be possible for Animate CC to circumvent this weird canvas-behaviour. Especially as my main method of doing fast graphics isnt doable anylonger when making HTML5 animations in Animate CC.
I could ofcourse just use bitmaps, but this is in no way as flexible, as manipulating vectors...which is kind of the reason I would go back to using Flas..I mean, Animate.
Here is a few links on the matter:
http://diveintohtml5.it/canvas.html#paths (the technical stuff behind paths in canvas of which I understand nothing)
i see your anti-aliasing problem, but don't know what you can do to resolve it.
Try adding a stroke to each shape that matches that shape's color.
I've tried adding strokes to "cover" the gaps, and its definately a solution...but it would add more time to my workflow, so I'd rather that this stuff worked "as before".
I have a rather large catalogue of graphic assets, that I reuse/build upon, and I would have to go back and insert strokes in many of them, to get rid of the gaps...and I'm talking about a lot more details than just a few squares and circles. On top of that, I would have to redo a lot of animations.
Ofcourse I can be forced to do this, but that is why I'm asking my question here first: Would it even be possible for Adobe Animate CC, at some point to find a solution to a problem, that is inherent to canvas? Just trying to plan ahead and pick the right software-path for me. I'm pretty dependent on these GUI-based programmes that deal in the development of interactive animations.
I still use Edge Animate, but can't risk continuing for too long as Adobe shut it down, and already the Apple-users are having problems running Edge Animate on Sierra.
I simply cannot reproduce this problem. I used the pen tool to draw a jagged-edged vector with another jagged-edged vector inside it, filled them both, deleted the strokes, and tested in IE, Firefox, and Chrome. All browsers rendered it perfectly.
I do see the issue, and it does seem to be a problem inherent to canvas. I did some searching and found this: graphics - How to avoid seams between filled areas in canvas? - Stack Overflow, so you might have issues with other programs as well.
That sounds a bit comforting, although I still get the exact same "gap" result on 5 VERY different PC's from graphics workstations to office-laptops.
The gap is more noticable with certain color-combinations than others. In some colors-combinations I don't notice it, but if I zoom in I can see the gap right away. And with other combination of colors it's jarring right away.
Are you using the same fill color? If so the two fills will just be rendered as one.
I've also tried all the different options under Publish Settings. Disabling Compact shapes helped towards normal straight lines/strokes which also have problems regarding anitaliasing (They have to be a .5 coordinates and according to the links in my earlier post, these rendering problems stem from the same place as the gaps between fills.)
Here are some screenshots of simple straight lines (browser set at 100%):
Sorry for going off my own topic, but they should be connected in some way
Nice workaround, Myra! I'm not sure it won't be messy during animations, but it surely works on still-graphics If i group the drawing, and duplicate it on top of itself, it even works in the same layer....perhaps this could be a clue as to how, the devs could solve the canvas-problem when using Animate CC.
It's all pretty much above my comprehension-level, and I'd just like to be able to draw and animate without all these workarounds
Maybe for your animations, keep everything inside of a movieclip. Then you could duplicate that either on the same layer or a separate layer. Keeping your work inside of the movieclip will help if you make changes. Then you only have to make it one place, and it'll update every instance on the stage. The reason I mentioned duplicating a layer is because it's something you could do last by right-clicking on your layer and duplicating. It might help for organization. And if the Animate team comes up with a solution and you wanted to re-export, then you'd know you could just delete that duplicate layer.
Its color bleeding issue that happens due to anti-aliasing technique used by canvas for rendering vector shapes.
It becomes prominently visible when the two adjoining shapes have similar fill color and a contrast background color(white by default) which seeps through their boundary.
To minimize the issue, you can use a background which has similar color to the region showing this issue.
For complex graphics, workarounds suggested above can be used. (duplicate layer or bitmap object underneath the actual graphics.)
Hope this helps!
Thx, for the explanation!
The question of this thread is:
Is it possible for the developers of Animate CC to correct this canvas-behaviour at some point down the line? Or is beyond the scope of Animate CC to correct this issue, as it is related to how canvas works?
Although the workarounds fix the issue, they are cumbersome to implement in a workflow, so I'd really appreciate it, if you could track down an answer for me.
The rendering part of HTML5 canvas documents is handled by CreateJS library which in turn uses the native canvas APIs, so there's not much we can do from Animate CC side.
The workarounds should be possible using some JSFL or run-time scripts to simplify the process.
Please note, this problem is already handled in WebGL or AS3 based doctypes.
Thanks for the helpful info, Nipun, that was EXACTLY the info I was looking for
Looks like I need to look more into WebGL instead of Canvas, then!