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.
Related
I have converted the MD2 code from the library to use THREE.BufferGeometry instead of THREE.Geometry to vastly improve memory footprint. To do this I just convert the model to THREE.BufferGeometry after it is done loading. I also had to modify the MorphBlendMesh code to use attributes for the morphTargetInfluences.
This is working great except for issue: the shadows don't update during animation, it always uses the shadow from the first frame of the animation.
I haven't seen any documentation on morphTargetInfluences attributes, so I don't have much to go on.
I can't really post the code since it is too much spread out across the code base.
I am just hoping that someone out there might have some insight as to how shadows get updated during morph animation, and maybe point me in the right direction on how to research this issue.
I have found the problem, and a workaround!
The code in the shader renderer is checking to see if geometry.morphTargets has a non-zero length before it decides to set the 'usemorphing' flag. The converted buffergeometry does not have a .morphTargets field since this information appears to have moved to .morphAttributes for buffergeometries.
My hack workaround is to add a fake .morphTarget list like so:
Buffergeometry.morphTargets = [];
Buffergeometry.morphTargets.push(0);
Have looked around the internet, and have not been able to find an answer to this.
I am building yet another custom image slider, but need to be able to handle arbitrary html in the div that is being animated.
Generally, this would be no problem... this certainly isn't the first slider I created, and, in general, if I require the pretty slice and dice effects, I use an empty div with the content as a background image like everyone else. If I do have to allow it to handle arbitrary html, I limit the effects, or simply fade in the html content once the slice-n-dice transition is completed.
In this case, however, I need the pretty effects AND the arbitrary HTML in the same sliders, and at the same time.
My best idea on how to do this was to convert the arbitrary HTML into an image.
I couldn't find a decent, client side solution anywhere... but eventually realized I could stuff the HTML into an SVG element, and can use SVG as a background image for the div.
(Just an FYI, this really only has to be handled by modern browsers, which can handle SVG and DATA-URLS and such)
The first part is actually kinda easy:
arbitraryHTML = "<style>div{padding:10px;border:5px solid red;border-radius:10px;width:500px;height:175px}p{text-align:justify;}img{height:50px;float:left;border-radius:5px;margin:10px;}</style><body><div><img src='steve.png'><h1>Arbitrary HTML</h1><p>This allows arbitrary HTML to be turned into an image, and the image is then able to be stuffed into a canvas. In this case, I will leave this image as an image so that I can set it as a background image of a div that will be visually sliced apart for a slider.</div></body>";
var stuff = document.createElement('svg');
stuff.innerHTML = "<foreignObject>"+arbitraryHTML+"</foreignObject>";
document.body.appendChild(stuff);
This works perfectly fine if I just want to stuff it directly into the DOM... but what I need to do is to use it as a background image for the div that I am slicing and dicing.
Since I already have the SVG code, I should be able to use it as a data uri to feed the image in.
I found an example like this on fiddle, and attempted to use this method on the code sample above to stuff the svg into the background-image...So far, I have completely failed to do so.
Example:
var i = document.createElement('div');
i.setAttribute("style","background-image:url('data:image/svg+xml,<svg>"+stuff.innerHTML+"</svg>);'");
document.body.appendChild(i);
Every time, I get the same problem; there are no errors or warnings thrown by Chrome console, but the div simply shows completely empty.
Using some methods (the code sample above, for example) the console shows the data uri in the code for the div properly, but still fails to show the background.
As part of bug testing, I had both side by side... the actual svg element (which displayed fine), and the div with the same code stuck as a background image (which would not display). Due to this, I am assuming that my problem is something about the way I am casting the svg into the data-url rather than the svg itself.
I really haven't been playing with either inline SVG or Data URL's very much before this... so it is quite possible that I am handling the data URL's or SVG improperly for the way that I am trying to use them.
Not really sure what I am doing wrong, but would really like to solve this.
Is there a better way of converting arbitrary HTML into an image that I missed?
Or is my idea of how to achieve this on the right track, but the implementation screwed up?
Any help would be greatly appreciated.
I guess Chrome still has this webkit bug. What your doing should work in Firefox or Opera 12. Note that IE9/10 doesn't support foreignObject at all, not sure about 11.
Using kinetic js for a searchable directory listing on a kiosk. It works great!! except for one issue. I am in chrome and have an a,b,c,d etc list on the side a user can click for names starting with that letter. When a letter is clicked, it re-renders the whole stage. After 10-15 times of doing that, the stage comes up blank, but I can still click where a name would be and get its detail "lightbox" or click where a letter would be and get a new listing, but still a blank stage, ie no fill or color on any rects or text. Whats worse is that if I go to an entirely different kiosk page that uses KineticJS for something else, it does not render either and never will again unless I leave the domain (localhost) and go to google or something and come back, or open a new tab or restart Chrome. I am totally lost now and redoing it without Kinetic is going to be a huge loss if I can't figure this out.
I have gone through and tried to be sure my memory management was ok and pretty sure it is. My system memory does grow, but Chrome seems to gargbage collect it fairly quickly. I have even tried calling destroy() on every kineticjs object I create when re-rendering with no luck.
There is a known issue in Chrome 29 in regards to canvas rendering. The issue is not present in version 28 or 30. Join the party and help draw eyes to the issue. :) https://code.google.com/p/chromium/issues/detail?id=280153&thanks=280153&ts=1377616231#makechanges
As a temp workaround you can turn off the 2d canvas acceleration by setting 'Disable accelerated 2D canvas' flag to enable.
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).
I noticed that when you move a canvas around or when you resize it, everything inside gets erased. I remember having a similar problem in windows forms applications in C#.
Anyway, what's the best way to keep the graphics on canvas, even after it moves etc.? (using javascript)
I've been working on a paint using canvas and websockets, you can see my problem here: http://students.info.uaic.ro/~tudor.berechet/ (just go to Coboards, select the Brush tool, click a bunch of times on canvas and then resize the window or enlarge the canvas)
One more thing I noticed, running the site off my HDD, this problem doesn't occur. which makes me wonder if there's some strange error somewhere.
I definitely need a persistent canvas, because I'm gonna have to implement the hand tool to move it around...
What say you?
The problem seems to have gone after cleaning up my code a bit. I still don't know what was causing it, but it seems that the canvas drawings now remain intact even after I move/resize the canvas.
Please confirm. [EDIT] confirmed.
The point is, my original assumption that canvas graphics are not persistent seems to have been wrong. There was most likely some coding error that was "erasing" my canvas.