I have a few sites where I'm creating an SVG programatically in JavaScript using createElementNS. It's always worked up until the present, but for some reason, on one project, it's not working.
You can see that the SVG registers in DevTools but has a screen height of 0x0. I'm wondering anyone has tips to debug it? The code is quite long that makes it & whenever I try to distill a minimal example it works, so I'm a bit stuck on what may be going on here. Thanks!
Related
I've dug through the internet and found some things that seem to be going in the right direction but nothing that seemed like a complete solution. Here's what I found:
The upcoming CSS property backdrop-filter, which is currently only supported in Safari and behind a Chrome developer flag. Exactly what I need, but it needs better support.
The JavaScript library Blur.js, which seems to have all but disappeared from the internet. (Even the official website leads to a GoDaddy page.) It may have been a solution but I'm not sure what happened to the project.
The JavaScript library StackBlur, which seems to be a brilliant blurring solution, but I haven't the slightest idea how I would use it to blur BEHIND an element.
Any ideas? Perhaps someone has used StackBlur to do this and has a CodePen I could poke through or something? Basically, I have a grid of element each using jQuery UI Draggable that I would like to make translucent with a nice blur behind each one. The blur needs to update as expected when the elements are dragged around.
One last thought. Right now what I'm using is a pure CSS "solution", but it has some annoying limitations. If you are going to suggest a solution with only CSS it's probably what I'm already doing. The issues with it are the following:
The area behind the element isn't really blurred, just an arbitrary background image.
The edges or the blurred area do not cleanly cut off the blur. This is a bit hard to describe, but just trust me when I say that it's doesn't look great.
Unless I missed something huge in all my searching, I think I'm going to need JS for this one.
Barmar is correct. Give two objects the same absolute position. Blur one object and assign it a lower z-index. Bob's your uncle.
If you need some clearer specifics, then please post your code following the SO guidelines.
Is there a way to turn debugging on or some command to show us rendering problems when using famo.us?
Log statements would be helpful or any other way of telling us what is going when the app is being rendered.
EDIT: Here are the rendering problems I have seen so far
1- Layout is inconsistent across browsers (Not even talking about IE yet!!!!).
Safari 7.02:
Chrome35:
Android Firefox 29:
2- Scrolling with famo.us is basically screwed.
I have 3 main sections my app (website):
Header (which is a ScrollContainer with 4 surfaces).
Footer (Which is a ScrollContainer with 1 surface).
Content (2 ScrollContainers on the left side and 2 ScrollContainers inside a Deck component on the right side. Each text/paragraph is a surface in its respective ScrollContainer).
Now, if you go to my app, you will notice that the scrolling is screwed and I have no idea why! I don't even know how I can debug this mess.
P.S: The code is left un-minified and with comments on purpose.
But wait there is more. Scrolling is confusing to the user as the user has no idea that this view is scrollable because no scrollbars are visible. You can even see that on the famo.us demo page. Go and try to scroll :). The only way you can scroll is if you go to the left side of the page ...
3- The Deck component seem to arrange the cards randomly on initial load based on the browser! As if things aren't already screwed enough. See screenshot below:
Chrome35 Desktop renders the green card first:
FF29 Desktop renders the red card first:
With all the above issues. I have no idea how to fix them or why they are happening.
List of things that will help me as a developer debug problems with famo.us:
Enable some debug logging when using components.
Throw JS errors when using components incorrectly.
Warn me about potential layout problems if using components with known issues.
Have better documentation. I basically read your code base to understand how to use something because the famo.us docs is not adding much value without having examples whereas your open source code does.
More articles talking about layout and page structure. This is a fundamental thing. If we can't get this right, there is no point playing with animations on a page that is not viewable correctly!
I have also noticed that FF29 on Desktop lags when I interact with the Deck of cards whereas on Chrome it doesn't. So backing up your 60fps claim across devices would be a good start. Show us performance metrics and comparisons to prove that claim.
I really want to use famo.us and I will hopefully contribute some fixes if I get some time but this is currently how I feel about famo.us.
Yes, it would be great if there was something that gave more info. Like a famoushint or something. I use jshint that at least helps with the common JavaScript errors.
Also, this has saved me a few times as well. http://famo.us/guides/pitfalls
But I agree it is a little buggy at this point, I've been having trouble with the Scrollview.
Currently there are no render specific debugging tools in Famo.us..
There are a couple of things I do when I run into problems..
1) Use javascripts 'debugger' command to stop the execution of the code and inspect the environment..
debugger;
2) Use a class that you can easily search in the surface you want to inspect. This class would contain no style but be unique enough to be used as an identifier to find the element quickly within the DOM tree.
var suspiciousSurface = new Surface({
size:[200,200],
classes: ['my-debug-class']
});
Hope this helps!
a famo.us app is fundamentally a javascript app, so the same techniques apply http://berzniz.com/post/78260747646/5-javascript-debugging-tips-youll-start-using-today
About the rendering, it is OK to inspect the DOM. If your scene is not too complex, you can quickly figure out which DIV your surfaces map to.
You can also outline a particular surface as #johntraver suggests, or also outline all the surfaces : in you CSS, add :
.famous-surface {
border: solid black 1px;
}
I'm following this tutorial on the JavaScript library dc.js and am having an issue with rendering a line chart in the tutorial. I get something to display, but it doesn't look at all the way it should in the tutorial. The D3 and Crossfilter parts of the code seem to be talking to each other since the brushing functionality works, so I'm wondering if I don't have the CSS referenced correctly. You can easily view the code by just viewing the page source. I'm assuming this is something simple that I'm just overlooking due to being fairly new to CSS and JavaScript. Thanks in advance for reading.
Your problem is that the fill attribute on the path svg element is not set, so it's defaulting to black, giving you that black fill in the middle. When I open the developer console in my browser (using IE), I get error messages that say "CSS was ignored due to mime type mismatch." for both dc.css and colorbrewer.css. GitHub is a pain with mime types, so you may want to move these files elsewhere.
The work-around to get the fill to go away (but not addressing your css loading problem) is adding this line of code:
d3.select(".line").attr("fill-opacity", 0);
I hope that helps!
I do have a Paper.path() in Raphael that is filled with a simple texture:
var fill = screen.path(Iso.topFacePath(top)).attr({
fill: 'url(http://www.example.com/mytexture.jpg)',
});
The path can be altered by the user via drag and drop. For this I use Element.drag() to bind the handlers.
The problem that I encouter now is that while the onmove-handler function is called the element in question will be recalculated and has to be drawn again. Apparently this is "too much" for raphael and the fill pattern will disappear randomly (flicker) and appear again some time later (at latest onend).
The actual code I use is a little too much to post here but I built a fiddle where you can see what's going on (you can drag the upper sides of the quadrangle).
Is there a simple fix to this?
I am used to canvas much more than raphael (actually this is the first time I really use raphael) so maybe my approach of redrawing everything everytime sth changes is plain wrong?
EDIT: I just found out that seems to be somehow browser-related as well. Chrome and Firefox will produce the flicker where Safari seems to do everything just fine.
This seems to be caching issue (raphael.js does not cache the bitmap fill and will reload it on every change) and is fixed (for me) by this pull request on GitHub that is (as of 08/14/2012) still pending.
Raphael is pretty hard / impossible to build oneself as the make file points to local and/or inexistent files, but you can either concatenate everything by hand, modify the build script or use the modified build that is used in the example to get hold of the fix.
Let's hope it will find its way into a future release of Raphael.
I have been working on an experiment to render HTML into a canvas image, by having javascript read all the necessary information from the loaded DOM. As canvas lacks many of the standard parts of CSS, especially when it comes to text formatting, a lot of work arounds and performance intense processes need to be done (letter-spacing for one). The intent is and never will be to make a fool proof HTML renderer, as it simply won't be possible, but instead try and make as accurate as it can be.
For the sample pages, Google Chrome usually loads them significantly faster than FF. However, for some pages (usually the bigger ones), Chrome completely freezes, where as Firefox loads them fine. Now, I have been trying to pinpoint where exactly things go haywire, but haven't had much luck as it doesn't end up outputting anything in Chrome.
Does Chrome have some limit of how many canvas draws can be performed within a certain time span, or how much system resources a page can use? How can I start untangling the bottleneck if I can't get any sort of feedback from the page at all (as it just hangs up)?
Examples (what it should do, is render a canvas image on top of the page, which should look more or less same than the actual HTML page. You can toggle the canvas image (show/hide) by clicking it. Please don't open them either if you got unsaved work in your browsers, as it may end up hanging them as well.):
simple test, works fine in FF/Chrome
another simple test, works fine in FF/Chrome
Complete page, works fine in FF/Chrome
Complete page, only works in FF < 4, Chrome freezes
They all use the same js which can be found here.
I am not looking for a blazing fast script, as with the type of emulation this renders the images, I don't think it could even be done. Simply trying to find ways to make it perhaps slightly more efficient, without losing any of its current functionality.
Where to begin?
Break it down.
Use the same example and cut how much you do it it (your rendering code) in half. Does it still not work? In half again, etc. Did it work? Put back half of what you took out.
As in, get rid of all attempted text rendering, or all border/padding code. Just comment it out. Does it work then?
Or try just commenting out ctx.drawImage(img,x,y); on line 199 and nothing else. Does it work then?
If you're lucky you'll be able to determine a critical point where Chrome is spending a lot of time doing something.
Have you tried using Chrome's built-in performance profiler?
The problem appeared to be with the css attribute background-repeat, and specifically repeat-x. Commenting out
for(bgx=(x+background_position_left);bgx<=w;){
drawImage(image,bgx,(y+background_position_top));
bgx = bgx+image.width;
}
Fixed the issue at least for chrome, and looking at that it most likely was an endless loop as Kinlan proposed, but why exactly it gets stuck only on newer versions of FF and chrome is something I'll need to look more in detail (most likely not having the image.width available yet, or something similar).