I would expect the clip function to clip the line and the fill area (backgroundColor), but it only clips the line. How do I get it to clip the fill area, as well?
Fiddle here. In my project I am actually making a radar plot, but the same behavior is observed in a filled area chart. Notice that the line is clipped 100 pixels below the top (as intended) but the filled area below the line, which is part of the same dataset, is not clipped at all. I would like them both clipped equally, which I would think is the expected behavior.
My fiddle uses 3.9.1 but the same behavior is observed in latest 4.2.1
Here's another version of the fiddle that shows the same behavior in a radar chart.
Related
Looking for a solution to get the grid lines inside or over the polar area points.
Like the image attached.
I found the code which draws the gridLines and the one draws the point.
I also see it's possible to pass a creationPattern() as background.
But I don't know how to get them working together.
Maybe a solution can be simply show the gridLines over the points and not behind.
I am trying to use opencv's simple blob detector to determine the colors on the face of a Rubik's cube. I have been using this fantastic resource so far and it has proved to be very helpful and descriptive. After a fair bit of tweaking, I have been successful in making good filters for each color. I look at the x and y position of each color blob, and since the cubies have an even spacing, do a quick rounding division to determine which row and column they belong in, with groups of two being split and belonging in two different rows/columns respectively.
This is more of a curiosity question than anything else. To my eye, it looks like the centroids are being calculated incorrectly... shouldn't the drawn circle be more centered in each blob? Yet both seem to be sticking out arbitrarily to one side.
Below, I have the original image of the cube, and two of the color filters, the top for green, and the bottom for blue.
As you can see, the green and blue blobs are positioned correctly, and should be far enough away from each other to be classified into separate rows, but the centroids visually seem to be skewed from the centers of the blobs (green centroid should be more to the right, and blue more to the left). Is there something that I am not picking up on here? Is this just a quirk of the system?
In v2.0-beta, is there a way to configure the tooltip corresponding to that x-position to show up when hovering anywhere above that point on the axis? for example, the functionality shown here:
https://blockchain.info/charts/market-price
As you trace the line horizontally, you are shown the tooltip corresponding with your distance from the y-axis.
What the tooltip shows in your example is the y value corresponding to the distance from the y-axis (i.e. the x value).
Unless you want to extrapolate between data points (not usually a good idea for data like that shown in your example, since you don't know that its going to follow your extrapolation), this means that you need to have data values for all points where you want to show the tooltip.
With that your question is basically about showing every n x axis labels. https://stackoverflow.com/a/31606933/360067 does this similar for the current stable version of Chart.js. For v2.0-alpha, the option you need to be adjusting is scales.xAxes.labels.template.
I'm working on a piece of code to automatically align x-axis labels for a variable number of subplots. When I started having trouble setting label positions manually, I checked to be sure I could just transform from one set of coordinates to the other without changing anything, with a code snippet like this:
# xaxes is a list of Axes objects
textCoords = [ax.xaxis.get_label().get_position() for ax in xaxes]
newCoords = [ax.transAxes.inverted().transform(ax.xaxis.get_label().\
get_transform().transform(c)) for ax,c in zip(xaxes,textCoords)]
for ax,c in zip(xaxes,newCoords): ax.xaxis.set_label_coords(*c)
In theory, this code doesn't change any coordinates; it just gets the coordinates of each label, maps it to Axes coordinates using the Text object's internally-stored transform, and then sets the position. Yet running this code removes my labels entirely, and a little experimentation shows that they go off the bottom edge of the plot.
Have I just misunderstood the transforms involved here?
You're understanding the transforms correctly, but there's a caveat to using display coordinates before the plot has been displayed.
The short answer is that putting in a call to plt.draw() before your code snippet above will fix your immediate problem.
You're trying to link the different axes display system through display coordinates. However, before the plot has been drawn the first time, the renderer isn't fully initialized yet, and the display coordinates don't have much meaning.
Can you elaborate a bit more on what you're trying to do? There may be an easier way.
Alternatively, if you want to avoid the extra draw, you can link things through figure coordinates before the plot has been drawn. (They're well defined regardless.)
I am getting some weird distortion of my CCLabelBMFont labels in Cocos2D, as noted here:
The distortions appear on both iPad device and simulator. Notable points about this:
I have other labels using the same font file that are not showing this
I have made sure the coordinates of the labels are all integers, no floats
there is no scaling of the labels
I have tried with and without [label.texture setAliasTexParameters]; no difference
If I move the label to a different coordinate, it sometimes corrects the distortion
Any idea what could be going on?
UPDATE: I changed my label to a TTF label, and the issue remains! Even when no font file is used, the distortion is appearing.
Some digging on Cocos2d forums led me to add this:
[[CCDirector sharedDirector] setProjection:CCDirectorProjection2D];
Seems to resolve the issue. Anyone know if this has other undesired side-effects, since this is not the default projection in Cocos2d.
UPDATE This solved my issue on iOS 4 only but my issue persists on iOS 5. I am now seeing that the distortion can be removed by adjusting the anchor point of the label, so it seems to be affected by that. Probably a bug?
UPDATE 2 It turns out that my symptoms were caused by two different things. The projection did in fact make a difference with some sorts of distortion and on all iOS versions, so this above code is useful. But second, I found a conditional statement that sets the position of the font label and it was not always creating integer coordinates. So, by placing (int) in front of the x and y parts of the coordinate, the issue resolved. Sprites can handle floating point coordinates without distortion, but CClabels cannot, it seems.
Add some spacing around each character. This is normally caused by other nearby glyphs from the texture atlas "bleeding" into one another due to texture filtering. Both Glyph Designer and Hiero allow you to specify spacing, typically a value of two pixels between each glyph is enough to stop bleeding.