I'm using fabricjs 1.7.17 and have seen this issue below on IE Edge, Chrome and Firefox.
where the canvas is being set with a width and height in HTML of 768px.
Within my fabricjs canvas init I've got:
editor.canvas = new fabric.Canvas('editor')
editor.canvas.setDimensions({
width: 1080,
height: 1080,
allowTouchScrolling: false,
backgroundColor: 'rgba(55, 55, 55, .33)',
rotationCursor: 'url(/static/img/rotate.cur) 10 10, crosshair'
}, {backstoreOnly: true})
The problem is when you call the editor.canvas.toDataURL() method the size of the goes from 768px to 1080px
If you call the browser's native canvas.toDataURL() method there isn't a jump in size.
Anyone bump into this and have a possible fix?
Here's a simplified jsfiddle:
https://jsfiddle.net/m8dhmbtu/23/
Click on the "Native Canvas.toDataURL()" and you'll get the results to console.log and there will be no change to the displayed canvas in the preview window.
Click on the "Fabricjs canvas.toDataURL()" and you'll also get the results (the same) to console.log however; you'll also get a jump in the size of the in the preview window...this is what I'm trying to prevent.
I think the problem is actually a bug.
You set the canvas to 1080 for backstore dimension only, meaning that the canvas will be sized but the css will be left untouched.
A dataurl will reset the canvas after the process to fix it back in case the export to data url had a multiplier.
while this can be fixed at least for the non multiplied situations, a proper fix is needed.
The proper fix consist in setting backstore only during export so that the css does not get touched.
A better fix would be to do not touch the original canvas and create one on the fly just for exporting.
please go on official fabricjs repository and open an issue for this.
Related
I'm having a bit of a problem: I'm trying to access the width of a container in which I've added a sprite to, but it seems to return as 1. However, when I inspect the object in the console, it gives me the proper width.
I wrote up a code pen showing the issue, but it goes something like this:
var container = new PIXI.Container();
app.stage.addChild(container);
var sprite = PIXI.Sprite.fromImage('https://i2.wp.com/techshard.com/wp-
content/uploads/2017/05/pay-1036469_1920.jpg?ssl=1&w=200');
container.addChild(sprite);
console.log(container.height);
console.log(container);
The first console log returns 1, while if I go into the object in the second log it gives me 141.
I'm trying to center the container like in the demo. The demo container returns the proper width, unless you try and do it for only one "bunny" (replacing bunny texture with internet image, also the for loop is commented out).
Any suggestions on a proper approach for this?
Cheers
There's a few things to address here.
Firstly, what the problem in your codepen is:
You're creating a texture from an image that has yet to be loaded.
Until the image loads pixi will not be able to give you the dimensions of it, and the container reports a width and height of 1 when you immediately query them. If you put the same console.log statement in a timeout then it will report the dimensions after the image has loaded and thus the dimensions will be accurate.
Logging out the object itself seems to work because when you examine the contents of it they've been updated to the correct values because the image has loaded by that point.
If the texture is already in the cache at the point that you create a new sprite using it then you won't have to wait before you can access its true dimensions.
Secondly, why the bunny example on pixi's site doesn't have the same problem:
Actually, it does. You just don't notice it.
The magic is in the bunny.anchor.set(0.5);. It lines 25 sprites with width and height of 1 out in a grid. By spacing them out, their container now has width and height of 160.
This container is now centered immediately based on its current dimensions, and then when the sprite textures finish loading and the sprites are updated with their new dimensions. Due to their anchor being set to 0.5, however, this means they remain centered despite their container now being larger.
You can play around with using a larger image than the bunny to exaggerate things and changing the anchor value, along with using the rerun code button rather than just refreshing the page. If you rerun the code the image being used for the texture remains cached by pixi so you get different results.
Lastly, how you would resolve this issue:
Loading your assets before creating sprites with them.
(Or at least waiting before they're loaded before querying their dimensions to position things)
You can find an example of the resource loader that pixi has here: http://pixijs.io/examples/?v=next-interaction#/basics/spritesheet.js
The default behavior of fabricJS resizefilters makes images look great as long as the zoom level is set to 1.0. This means images with a resizefilter look pixelated when zoomed in, as well as when exporting the canvas with a multiplier. Is there a way for resizefilters to take into account the current canvas zoom level or toDataURL multiplier?
https://jsfiddle.net/melchiar/mh9ba4pz/
fabric.Image.fromURL(imageData, function(img) {
img.set({
left: 10,
top: 10
}).scale(0.5);
img.resizeFilter = new fabric.Image.filters.Resize({
resizeType: 'hermite'
});
img.applyResizeFilters();
canvas.add(img);
});
Hi i have seen your question on the issue tracker too, as of now there is no simple way to obtain it with the resize filter.
The only way to make it non pixellated is to remove at export time the resizeFilter and add one resizeFilter in the normal filter chain with a precalculated ratio.
This is actually a bug.
issue tracker: https://github.com/fabricjs/fabric.js/issues/5071
Just an update on this question, this issue was a bug that was fixed with Version 2.3.4. Using a resizefilter will now apply resizing based on the current zoom level, and works with toDataURL multipliers as well.
I have a function that adds an imageOverlay and a semitransparent Rectangle on top of that image (so as to tint the image, and draw a keyline around it).
activeUserImage = new L.imageOverlay(imageUrl, imageBounds).addTo(map);
activeUserTile = new L.rectangle(imageBounds, {stroke: true, color: "#ffffff", opacity:1, weight: 1, fillColor: "#003572", fillOpacity: 0.7, clickable:true}).addTo(map);
this works great, but then I want to remove the image and rectangle with:
map.removeLayer(activeUserImage);
map.removeLayer(activeUserTile);
This seems to work well...
However when I try and add a second Image & Rectangle (using the same function) the rectangle SVG is being rendered underneath the image, so I don't see the colored overlay.
This seems to be because the element is being left behind from the first creation, and then when the image is being added a second time it appears in front of the SVG.
Q:
Is this a bug? Should the SVG element not be cleared too?
Can I adjust z-index of the image or SVG on creation?
should i be containing to rectangle in a different layer to the images? How?
Many Thanks
OK, so the Leaflet bringToFront() method didn't work, but instead I have used a bit of JQuery to force the same approach.
svgObj = $('.leaflet-overlay-pane svg');
svgObj.css('z-index', 9999);
This works, but still feels like a hack... however if (?) there is a bug in LEaflet, then maybe this will have to do???
Any better ideas?
The bringToFront() function alows you to bring layer to the top.
Search it in the docs.
I'm drawing d3 line graphs and tipsy tooltips attached to the circles.
The tooltips work fine in Chrome/Safari but in Firefox and IE when you hover over a point, while the respective tooltip does appear, it shows up outside the graph/SVG element in the top left hand corner of the screen (html element) instead of next to the point.
This is how I'm attaching the tooltip:
jQuery('g circle').tipsy({
gravity: 'w',
html: true,
title: function() {
return this.textContent;
}
})
Any advice on what I'm doing wrong would be much appreciated.
This patch adds proper SVG support to Tipsy.
tipsy uses offsetWidth and offsetHeight on elements. It assumes that such things work on SVG elements, unfortunately that assumption is incorrect outside of Chrome/Safari.
The CSSOM specification says that offsetWidth/offsetHeight are html element properties. It seems that Chrome/Safari have put these on their SVG elements but there's no specification that says that that should be the case.
You'll either need to fix tipsy to be cross-browser or get the author to do it. Using getTransformToElement and/or getBBox is probably what's needed.
See this fiddle:
http://jsfiddle.net/UfP3C/3/
Each list item contains an SVG element.
My goal is when the user hovers the list items, the Raphael animation occurs (for its child svg element).
I'm having the following issue:
JQuery.hover works fine when moving the mouse slowly. But, when you
quickly mouse across (and off) both list items (horizontally), the svg elements often get stuck in the "mouseenter" animate position.
I'm trying to figure out how to get the animation to work as expected: When quickly mousing across both list items, the end result is that the svg elements are in the "mouseleave" position.
The above fiddle demonstrates the issue (in FireFox 5 and Chrome 13).
I would recommend using Raphael's native mouseover and mouseout
They rapidly respond to these events
You will also be able to tightly bind the animation with the keyword "this"
See this fiddle for the solution:
http://jsfiddle.net/UfP3C/4/
To prevent the svg animation from freezing in the mouseenter animate postion, set the animate in and out time to be the same value:
list_item.hover(function() {
my_rectangle.animate({
y: 0
}, 400, 'bounce');
},function(){
my_rectangle.animate({
y: 200
}, 400, 'bounce');
});
In the above code, the animate time is 400. Setting both animate times to the same value solves the issue.
See the above fiddle for the full code.
Note that using the Raphael hover function instead of the JQuery hover function (with different animate times) still shows the same issue and has the same solution.