I've slogged my way through implementing excanvas on ie8. I've got the dynamic element bit sorted, the initially-hidden elements are now happily rendering throughout most of the app, and just when all seemed to be well I've hit another roadblock.
The vml items rendered inside the div that excanvas generates are all offset by a large amount.
I only discovered what was happening by setting overflow:visible on all children of canvas, which caused the offset vml to become visible.
I've got a screenshot of the offending articles; the area in blue is the generated div in the correct position, and the items bordered in red should be within the blue area.
Has anyone encountered this before, and even better, been able to solve it?
Cheers!
In case anyone ever encounters this error, it seems the issue was with a translate() call. Although I was using save and restore, and every standard implementation of canvas interpreted the translate call as I intended, in excanvas the translate was persistently additive.
I solved the issue by restoring the identity matrix before performing the other save, translate & restore calls.
context.setTransform(1,0,0,1,0,0);
Related
I would like to comment on my problem in case someone has an idea of what it is due to or proposes an alternative solution.
Currently I have a large ag-charts graph that does not fit and it is always necessary to scroll to be able to see it in its entirety but when scrolling the axes are not maintained, so I resorted to the alternative of cloning the graph canvas twice to generate 2 new canvas clipped with "position:fixed" so that they always stay at the ends.
So far there is no problem except that if the browser zoom and/or the windows scale differs from 100%, it affects the cropping of said canvas in an inconsistent way. I was not able to get a rule of 3 to apply the correct zoom multiplier ( with ctx.drawImage() ) due to its inconsistency.
The error stops happening when you test it with a normal canvas that has not been generated by ag-charts
Here I have a very simple Live Demo to test it.
(To reproduce the bug you need to have the zoom applied before the generation of the graph).
I also tried to get the zoom level using:
(Math.round(window.devicePixelRatio*100)/100, -1);
and applying the correspondent ratio using:
.drawImage(canvas,0, 0, canvas.width*ratio, canvas.height*ratio);
but it only works in specific percentages of zoom
I am trying to animate lines going from left, right, top and bottom(lines should start from edges of the screen). Animation works fine in IE11 but not in Mozilla and Chrome. Other browsers I haven't tested. I used Adobe Illustrator to draw. http://codepen.io/Ljanmi/pen/WbyLWv
In Chrome and Mozilla(IE11 is fine and acts normal) if in Illustrator I set Object>Artboards>Fit To Artwork Bounds(minimizing Artboard size which I usually do when create or edit SVG) I get this result(even worse) - http://codepen.io/Ljanmi/pen/yyqVqz
I spent hours and hours trying to figure out on my own without success. I started topics on GSAP forum and CSS tricks forum(stackoverflow.com is limiting me to post only 2 links as a newcomer).
I used GSAP JS library for animating(generally very happy with GSAP) but animation behaves the same if I use CSS3 to animate. I concluded that it is not related to GSAP(viewbox size property seems to have little bit of effect here) , more likely to be related to SVG structure itself or browser compatibility or both. So I guess there must be some work around to make it work like I would like to. I most likely lack some SVG/HTML/CSS3 knowledge since I am not very experienced but trying to learn as much as I can. Thanks everybody for reading.
Add svg { overflow: visible } and it should work the same in all browsers (longer explanation below). If you want to see why the lines get clipped, add borders to the svg element.
Another way is to make sure the size of the svg matches what you want, e.g by using css.
All browsers except IE implemented hidden as the initial value for the overflow property for the <svg> element, as called for by the SVG 1.1 spec. SVG 2 has changed this for (outermost) inline svg elements, such that it requires what IE11 is currently doing. It will take some time before that gets changed in all browsers, so for now just add the overflow: visible rule and it should work correctly in all browsers.
I had some trouble with browsers still not showing the overflowed content for SVGs and found that this finally got past it:
svg:not(:root) {
overflow: visible !important;
}
I have written a small JavaScript library to calculate text height-related metrics.
It scans canvas image data to find top and bottom points of the text.
Unfortunately due to Firefox Bug 737852 it is currently broken in Firefox -- top position is higher than it should be, which breaks fitHeight logic.
Any suggestions on how I can work around that?
My understanding is that CTRL-mousewheel zooms are an accessibility feature, built into the browser in question (I am currently testing in Chrome and Opera, both if which use the CTRL- zoom).
This won't ever really be needed for accessibility, however, as the app will not be for the general public. And CTRL-wheel zoom has a nice benefit out-of-box as compared with standard mousewheel zoom over elements: It seems that Angular ui-sortables work perfectly at any zoom/scale.
Unfortunately, from other answers I've found on SO, there is no way, when using CTRL-wheel, to zoom selectively : the browser can only zoom everything. For me, this includes position:fixed overlays scaling at the same time as the main viewport, which is no good.
So I set up some code for scrolling as per whichever element the mouse cursor is over, eg. scale the main viewport using the mousewheel, only if the mouse if over that viewport element.
The problem is that ui-sortable does not behave correctly, when using it for only a single element. I've used scale with transform-origin set at 50% 50% but still, when I drag the ui-sortables at any scale other than 1:1, they appear way off to the left. Any ideas on how to begin to tackle this?
This isn't a problem in Angular's sortable adaptation, rather it's an issue in the underlying jQuery-ui 1.9.2 positioning functions around line 4000 (_generatePosition or maybe one of the others). I believe that as the browser does not modify the actual dimension values during scale or zoom, and the formulae provided in that library do not account for scaling (that I can see), there is no easy fix, since jQuery ui.sortable needs scale-accurate values to calculate correct displacements. (I tried modifying the formula to account for this, but without success.)
The simplest workaround for the present is to manually change the width() / height() of your individual list elements, as seen here. This may require being selective about just what you scale using width() / height(), and what you change using scale (which is generally easier).
I'm using d3.js to do some svg layout/animations and am running into the problem described by the first example here (only on Safari / Safari mobile):
http://www.mysparebrain.com/svgbug.html
(e.g., when the rect+text moves, it leaves rendering artifacts in its path)
Does anyone know of a workaround for this?
The only similar question on SO I could find is this unanswered one:
Canvas draws artifacts in Safari for animated, filled bezier curves
You should definitely file a WebKit bug report on this. You've already reduced it to a very clear test case, so that should make it easier for someone to fix it.
Anything that forces a redraw based on horizontal positioning seems to fix it. I noticed just by switching to another tab and back caused it to redraw. What about doing a reposition of the content area, e.g., move right 1px then left 1px, to force a redraw? It's not pretty, but it's better than artifacts.