I am working on animating a line graph using d3.js, and have been closely following this example. The code I have written works just like the example...but the bug I am trying to fix is one that is also unfixed in this example. (So going forward, just follow that link to see the bug for yourself)
In Chrome and IE10, the chart works just as it is supposed to. However, in Firefox, the line does not just draw itself from left to right. Instead, the page loads with the line already displayed, then the line erases itself from left to right, and then finally draws itself (again) from left to right like it should have done in the first place.
Also notice that the line drawing is twice as fast on firefox as the other browsers - this means that the issue is with the transition itself: the transition of the stroke-dashoffset property is handled differently by firefox and the other browsers. Specifically, if we remove the transition from the equation, the main difference becomes evident: With stroke-dashoffset set to totalLength, Firefox displays the entire path, as opposed to none of it, like the other browsers do.
So my question is: is this a bug, or is this bad form on my (and duopixel's) part? If the former is the case, does anybody know a workaround or a fix? If the latter, I would be very grateful if you could show me the correct way to do this!
Related
I have a problem, I am making a page with fullpage.js, I am launching animations with tweenLite every time I reach a section with Scrollmagic.
The problem is the following:
If I move in the normal order of the sections, one by one, the animations come out correctly, but when I jump, from the first section to the last one for example, the animations do not complement each other correctly everything gets decontrolled, I leave the sample of the page, so you can better understand what is happening.
Is there any optimal way to do this process, thanks in advance for the help.
http://pagina.gestionahora.co/
I have for a very long time experienced a hugely annoying problem with the TStatusBar VCL control, a thin wrapper around the Win32 status bar control.
Since this appears to me as a very common and frustrating issue, I am very surprised Google (and StackOverflow) doesn't seem to know much about it.
The problem is that the status bar text becomes very blurred when it hasn't changed for a while; the precise conditions are still unknown to me. But I see this every day:
If one of the panels has its text updated, the new text is rendered correctly (see last panel):
Is this something that only happens when I am in the vicinity of running Delphi processes, or is it indeed a known issue? More importantly, is there a known cure? (And, academically, why does this happen? It wouldn't surprise me if it is related to transparent drawing of anti-aliased text by code originally designed for unthemed Win9x.)
I have tried to enable double-buffering, but I am not sure if that completely resolves the issue. (I have seen even worse behaviour in non-double-buffered list view controls, which is resolved by making them double-buffered.)
I made all status bars in my applications double-buffered a week ago, and I haven't seen any blurred text in any of them since then. Previously, I saw severely blurred text daily. Hence, it seems like this issue - whatever is causing it - can be fixed by making the status bars double buffered.
I am trying to set up a simple blog using Metalsmith and the fullPage.js library.
At the moment I have a problem where the height of the section divs upon intial loading are roughly 2 times the correct size.
Ie. when it initially loads the height in the console reads 1563px.
The odd thing is that once I resize my browser window in any way ie. make it larger or smaller, the div(class='section') height will then resize to its correct height in the console and in the browser, and everything is laid out correctly again (with regular sized divs as opposed to the super tall ones that were there previously.
This initial height inconsistency is causing many issues with alignment in my layout, such as the prev/next arrows as well as the div content.
here is a link to my public git repo for this project.
If you want to run this locally you can pull it down, run npm install, then run nf start. You will then be able to access it at localhost/3000.
If anyone has any suggestions that would be much appreciated.
Thanks.
It is not ideal to just public your source. A link reproducing the error would be much better.
In any case, I believe yours is a case of missing the compulsory DOCTYPE declaration at the very start of the page.
Take a look at any examples of fullpage.js. They all have it.
Add this in the first line of your resulting HTML files:
<!DOCTYPE html>
I am following this example of a difference chart. I've added buttons on my page that make ajax calls to fetch new datasets, and then I redraw the difference charts. There are several difference charts on my page.
Upon redrawing, the rendering of the above/below areas becomes corrupted: x-values have both above and below areas rendered. I'm fairly certain it's not a back-end problem, because the initial load produces a correct chart; changing a parameter messes up the redrawn chart; and going back to the default parameters and redrawing the original chart also produces a corrupted chart. In fact, I can partially make out what's happening: the original time series is present on the new graph. It's almost as if there are three series being graphed.
I think it has to do with .datum. I don't fully understand how it works, since it differs from the standard enter/update/exit methods associated with .data. I've read the documentation, but am still confused. Some possibilities:
The original data is hanging around (even though I clean out the container with $('#chart').html(''))
The .append(g) is adding groups without removing the earlier ones.
The svg.append("clipPath").attr("id", "clip-below") is causing problems, since multiple nodes have the same id (even though again, I'm not sure how this could happen since I remove the nodes before the redraw).
I feel like I'm missing a lot of fundamentals here, even though I've spent a decent amount of time trying to understand the library. Can anyone see anything obvious, or point out some good resources for me to look at?
UPDATE: This has to do with there being two charts on the page. I noticed this when I opened the inspector and closed it. The areas of the bottom chart (the difference chart) had screwed up, and I noticed the new line that it was using to separate the above-area from the below-area looked a lot like one of the lines from the top chart.
Does anybody have experience with dependency issues/namespace collisions when drawing two charts on the same page?
The problem was, the id's for the clipping paths were the same.
I would still like some more resources concerning .datum.
I'm trying to animate text with RaphaelJS, but I'm encountering a choppy animation ("judder"?). I've looked around for other issues regarding this, but I've only been able to find jQuery-specific or non-SVG topics so far. Please let me know if I overlooked a similar question!
Essentially, I'm attempting to visually wrap a text element in a rect element and translate them simultaneously through an animation. I know about the 'g' element, but I don't want to use it since older versions of Internet Explorer don't support it. Instead, I'm using separate Raphael animations for the text and the rectangle:
var raphRect = paper.rect(
(paperWidth/2)-rectWidth/2
,paperHeight-rectHeight
,rectWidth
,rectHeight
,rectHeight/2
)
...
,raphText1 = paper.text(
paperWidth/2
,paperHeight-(2*fontSize)
,'this is jumpy text?'
)
...
raphRect.animate({y : -rectHeight}, risingTime, 'linear');
raphText1.animate({y : -2*fontSize}, risingTime, 'linear');
I'm assuming that the judder is caused by rounding pixels in each animation frame for the text element. Is there any way to mitigate or prevent this judder? (Reducing the animation time is not an option...and it doesn't even look like it helps.)
(I have an example of what I'm trying to do here. I've included two lines of text and a bold stroke for the rect to emphasize the judder.)
I had the same problem and have tried to differentways to solve it. I have found few hacks that works for me. But they all have the same idea: you should make text not so straight.
"transform" : "R 0.01"
For example, it rotates your text on small angle. Here is the result:
jsfiddle.
I can't garantue that it will work in your browser. In stable Chrome 36 it works good, in beta or canary worse.
You could also try no so straigth font jsfiddle. It works good for FF.
"font-family" : "Comic Sans MS"
Other things worse to be tried:
inreasing font size
using bold font
using a text path
This idea is actually borrowed from Robert Longson's information about the text-rendering property. It's true that Raphael doesn't provide direct access to this functionality, but it does provide you with a link to the dom node -- so it is but a second step to apply this style yourself, and it does indeed produce better results in Firefox at least.
Using jquery:
$(raphText1.node).attr( 'text-rendering', 'geometricPrecision' );
$(raphText2.node).attr( 'text-rendering', 'geometricPrecision' );
Staged here.