How to deal with resolution mismatches on the JXG.Board - javascript

I have an editor that opens a JXG.Board which I can drag around etc. This editor maintains the ratio of the board, so that means I can make the board larger and smaller inside the editor while the original remains at the same size. When the size of the board INSIDE the editor matches the size of the actual canvas element then there are no problems.
But as soon as there is a resolution mismatch the coordinates don't get updated properly because the coordinates in the editor are different to that of the actual canvas coordinates. So as an extreme example scaling down so the board is 50% of the original (400 x 300) vs (800 x 600) results in the origin being offset towards the upper left corner each time the board is loaded into the editor as the origin is being taken from the editor and is 50% of that of the original so the origin drifts.
I'm a bit confused about how the coordinate system works. I've tried all sorts of stuff such as applying a scale factor and so on. I just cannot seem to get it working. I figure that I need to be using board.origin.usrCoords and somehow mapping that to board.origin.scrCoords - but I just cannot seem to get it working!
Basically what is the correct way to do this mapping? So far I've only used board.origin.scrCoords and the docs aren't exactly clear on how to work with the board coordinates.
Thank you!

Related

Guage value that adapts to width of graphic/svg

I have a slider/guage/bar component to select a value. As the slider is dragged it updates a value to give the user feedback:
currentValue = Math.round((componentHeight - draggedValue) / componentHeight * vesselVolume);
The slider gives its value from the top position of an absolute div inside an overflow hidden div parent, giving the illusion of a gauge that can be raised and lowered.
This all works fine.
The problem
I'm using the gauge to estimate the volume of liquid in a vessel. If the vessel has level, straight edges, fine, but it may not. A barrel, for example, will bulge out then back in.
I can use a mask over my guage to simulate the vessel being filled but it made me wonder if the task of being able to extract some some of volume filled of the vessel shown is ridiculously complicated or something approachable?
My current approach
I'll be using my own SVG graphics which could provide simple line data. I'm looking into whether there's a clipping or boolean operation possible on SVGs in vanilla javascript where I can clip the graphic where the top of the gauge reaches.
I presume I could then calculate the area of the resulting graphic, and present a volume of liquid if provide the volume of liquid that would have fit in the entire vessel.
I'm providing no depth information but it's currently safe for me to assume all vessels are symmetrical around the Y axis.
I'm a bit clueless at math involving shapes, is this task feasible? As a compromise, I would be ok to use crude formula that emulate various vessels if they approximately simulate edges diverging at a certain angle up to a certain height, etc.

Detemine all elements at a given point js

I am working on an API that use shapes (and irregular) shapes to build websites. My problem is where I can provide a div that can carry as a background to irregular shapes so .
However to do this I would need to know the max area the object is taking up by having the max height and width.
I am aware that element.getBoundingClientRect does this but my roadblock is that is does not consider any psuedo elements, which is how most of these shapes are made.
I know when working with the CSS transform property, especially using scale, the browser knows to resize the whole shape including the pseudo element that makes up the shape.
It also uses the border-box coordinate system.
However the browser does not provide this information as it comes from the user agent
My main question is how do I access the dimensions the user agent computes for any given element, or how do I find the proper dimensions of a 'getBoundingClientRect' that considers an elements psuedo classes
My shapes can be found in the attached links.
httpsmichaelodumosu57.github.iosigma-xi-mu
https://css-tricks.com/examples/ShapesOfCSS/
I can't afford to use any other method to create my shapes because I have limited time on the project, but I do know that the browser can provide me with the information I am looking for.
Yes I have answered my own question. What you want to do is to scale the image to a very small since (since transform scale() works perfectly) and place it in a grid box (this could be a div of small size as well. You would run document.elementsFromPoint(x, y)
(notice the pluralization) on every point in the div containing you shrunked irregular shape and from there you can find the height and width of its bounding box by the difference of the highest range of their respective coordinate values. To center you must place your irregular shape in the bounding box of the background drop with the re-scaled dimensions (remember your skrunked your irregular shape to find them) and have the margin of the inner shape set to zero. This works only if your real (not pseudo element) is to the left most of the screen. Question is how do you position your background when your irregular shape is not properrly centering inside of it?
You can use document.elementFromPoint(x, y) for getting the element that exists in specific point, but I have not tested it for any kind of shapes.

Javascript canvas and optimization of internal functions?

Say I have a rectangle that is 100 x 100 and I have a canvas 1000 x 1000.
As long as the rectangle's x co-ordinate is no more than 999 and no less than -100, it is true to say that some portion of the rectangle will be visibly seen on the canvas. Same goes for the rectangle's y co-ordinate.
What I would like to know is that if the rectangle's x or y co-ordinate is set so that the rectangle will not be visible on the canvas, does the internal workings of the canvas api still draw the rectangle or does it auto optimize and realise by itself that the bitmap that will be drawn on the canvas will not be seen, so therefore it doesn't attempt to draw it.
When drawing to canvas the boundaries are checked for each draw. If a pixel ends up outside the canvas it is clipped (discarded).
If not you would get a memory corruption and very soon a crash.
Canvas is designed to be very safe so you won't have poorly written Javascripts (intentional or not) crashing your browser. The same applies to colors where color values (f.ex. using a bitmap array directly) are clamped to be within the valid range.
Optimization is dependent on the implementation, but it's reasonably to assume that if the area is completely outside the boundaries of the canvas, the draw operation is rejected in full. If it is partly inside it may start the internal block copy by moving start and end cursor to represent the effective area that would be rendered visible.
The other option is to check each pixel as it is rendered, if it's inside or outside the visible boundary. This however is not optimal.
To visualize, only the gray areas would be considered, the light-blue would be ignored:
(I didn't show all possibilities but it should be easy to imagine the bottom parts etc.)
Cursor here is where the internal routine will start and stop looping through the pixels. In this case if the area to be drawn is 100x100 pixels and is drawn at -50, -50 (x,y) then the internal cursor is set to +50, +50 relative to the area being drawn and the width and height is reduced likewise.
By moving the cursor and adjusting the width and height, it doesn't have to iterate through all the pixels and therefor optimizes the copy (although, it is not quite accurate to say "all pixels", as data is not copied per pixel but mainly on block basis related to memory alignment. There are separate algorithms that deals with optimized memory copying and takes into account offset bytes (bytes that does not start or end on a "clean" memory boundary) and so forth, ie. 4 or 8 bytes are copied in one go rather than one and one byte combined with masking (AND'ing the bits)).
The boundaries apply to lines and circles etc. as well. Their effective drawing area is handled as a square area, but there are different approaches to draw lines, circles than a square of pixels, to optimize further.
See f.ex. Bresenham algorithm for lines or mid-point circle algorithm for circles or various algorithms for ellipses - I don't the specific implementation in each browser, but for these you square of the start and end coords and in some cases (as with circles and ellipses) you may have to check as you go (perhaps drawing the circle in four parts and check the part which is overlapping the boundaries on a pixel-individual basis - this is implementation specific though).
When it comes to translation that is merely a recalculation of coordinates (translate, rotation using rotation matrixes and stuff like that). The new coordinates are then checked against boundary.
Now that being said it is not sure the browsers have their own specific implementation. They might use the system's native bitmap and clipping functionality instead where possible. However, the same described above applies in this case as well.
FWIW, On IE, Chrome and FF the fully offscreen draws (non-draws?) took about 100ms less than onscreen draws for 100,000 rects.
According to the canvas spec:
"When the destination rectangle is outside the destination image (the scratch bitmap), the pixels that land outside the scratch bitmap are discarded, as if the destination was an infinite canvas whose rendering was clipped to the dimensions of the scratch bitmap."
This is not absolutely specific to your question but it's likely all "out of canvas view" operations are handled this way. So based on that, I'd say Yes, they are "optimised".

RaphaelJS -- vector or not?

I'm trying to place a circle at 50% of the width of the paper using RaphaelJS, is this possible without first doing the math (.5 * pixel width)? I want to simply be able to place an element at 50% of its container's width, is this even possible with the current Raphael API?
Raphael claims to be able to draw vector graphics, and yet it seems everything in the API is pixel-based. How can you draw a vector image using pixels? That seems 100% contradictory.
Likewise, as I understand vector art, it retains the same dimensions regardless of actual size. Is this not one of the primary reasons to use vector graphics, that it doesn't matter if it's for screen, print or whatever, it will always be the same scale? Thus, I'm further
confused by the need for something like ScaleRaphael; just seems like such functionality is part and parcel to creating vector graphics. But, perhaps I just don't understand vector graphics?
It just doesn't seem like an image that is created with absolute pixel dimensions and unable to be resized natively qualifies as a vector image. That, or I'm missing a very large chunk of the API here.
Thanks in advance for any help. I've attempted to post this twice now to the RaphaelJS Google Group, but I guess they are censoring it for whatever reason because I've been waiting for it to appear since last week and still no sign of my posts (although other new posts are showing up).
Using pixel values to define shape positions/dimensions does not make it a non-vector shape. Take for instance Adobe Illustrator - this is a vector product and yet you can still see that the properties for each object shows the positions and dimensions is pixels.
A basic explanation of vector graphics would be like this, taking a rectangle as an example:
A vector rectangle will have a number of properties such as x, y,
width and height. These properties can be specified in pixels. The
difference with vector (as opposed to raster) is that these pixel
properties are only used to determine how the shape is drawn. So when
the display is rendered (refreshed) the "system" can redrawn the shape
using the same properties without effecting the quality of the resize.
A raster image however will hold a lot more information (i.e. the
exact value of each pixel used to form the shape/rectangle)
If the word "pixel" makes you think it is contradictory, just remeber everything on a computer screen is rendered in pixels. Even vector graphics have to be converted to "raster" as some point in the graphics pipeline.
If you are worried about having to use a calculation (0.5 * width) then just remember that something has to do that calculation, and personally I would happily handle this simple step myself.
After all that, you should just calculate size and position in pixels based on the size of your "paper" element and feed those values in Raphael for creating the shape.

EaselJS line fuzziness

I am using EaselJS as an API for HTML5 canvas.
I noticed that the following code:
line.graphics.setStrokeStyle(1).beginStroke("black").moveTo(100,100).lineTo(200,200);
stage.addChild(line);
...produces following line:
I set the thickness to 1 - but the line is still fuzzy. If you zoom in with the snapshot, you can see it actually occupies 3 pixels. I believe I read somewhere canvas draws a point between two pixels, so that both pixels will be colored in fact. And you need to shift where you draw the point by half the pixel width so it falls on the entire pixel.
I need sharp image for my applications, please advise.
EaselJS is just an abstraction for the canvas APIs - which draws all lines on the specified coordinates. The snapToPixel API is specifically for doing automatic rounding, but doesn't take into account the half-pixel issue you are describing.
The best practice approach is to put everything into a Container, and put the container at positive or negative (0.5,0.5) - which will adjust everything, and you can work in a normal coordinate space, rather than offsetting all your calculations.

Categories