One question that has arisen is:

Can I get truly non anti-aliased lines with jgraphics?

I am calling jgraphics_line_draw_fast, which claims to not be anti-aliased, but is clearly not. I’m drawing a grid, and I think a sharp edge might be preferable. Any way to do this?

Thanks

Alex

I’m doing the same for horizontal lines (rounding y value to the nearest half-integer value), and it works as well, so you should be able to paint a grid just by using half-integer pixel positions.

Daniele

jgraphics_line_draw_fast() promises to be anti-aliased already, but it’s not so.
Probably a bug in the function or in the comments documenting the function…

The strategy I usually adopt is something like:

for (i = 0; i < num_lines; ++i) {
    double pos = floor(height / num_lines) + 0.5;
    jgraphics_line_draw_fast(context, 0.0, pos, rect.width, pos, 1.0);
}

However, my concern is that it would be more efficient if jgraphics_line_draw_fast() was already anti-aliased, since there would be no need to make the values rounded to half integer and the function itself would run faster...

I remember running some comparison tests to see if it was faster to draw lines with:

jgraphics_line_draw_fast();

versus

jgraphics_move_to();
jgraphics_line_to();
jgraphics_stroke();

I found there was no significant difference between the two and as a matter of fact I believe that jgraphics_line_draw_fast() calls the jgraphics_move_to(); jgraphics_line_to(); jgraphics_stroke(); combo under the hood.

But of course I have no access to the source code so I am just speculating...

Hope this helps.

- Luigi

I assume that the result looking anti-aliased is simply a consequence of the anti-aliasing method, and I would be slightly concerned about this behaviour potentially changing…. however, if this is the only way I may have to adopt it to deal with the issues I am currently having.

FWIW the speed is not a great concern in the jgraphics method as in general it is slow – hence the inclusion of an alternative onpengl method, but the issue now is that I cannot exactly replicate line behaviour in certain alpha situations with anti-aliasing on in both environments. Drawing non-antialised for some of the task may relieve this issue for me….

Thanks

A

A – when you zoom in?

B – when the object is not placed at an integer position?

I assume this method you describe may well breakdown in these cases.

A.

my method (which is exactly Luigi’s method) does not work when you zoom in, but it works if the object is not placed at an integer position. That’s quite surprising to me as well, though, and I don’t have a real explanation of why it works.

And yes: a truly non-antialiased line function would be welcome :)

A – When you zoom in, Max does a matrix transform of the patcher window to scale it and show it at the desired zoom size. So even if you use a truly non-antialiased method to draw your object, the grid lines will be antialiased by the matrix transform anyway. All line points will be multiplied by a certain factor and they will no longer fall on half-pixel values. As a 3rd party programmer you really don’t have any control over this. If you check the standard distribution object that implement some kind of grid line drawing (scope~, plane~, filtergraph~, etc…) you will notice the are all antialiased when the zoom level is not 100%.

B – The above code will not break when the object is placed at non-integer position, because pixels will always fall on .5 values (it’s kind of a brute-force approach)

But I am curious of what Alex is trying to do exactly…
Are you trying to use OpenGL to draw lines faster than the JGraphics API would allow?

- Luigi

I’m not sure about the first point – my experience is a little different from that – at high zoom you can actually draw much finer lines – it seems just that jgraphics handles the scaling of “points” before drawing to the screen, rather than scaling a rasterised image – after all it is supposed to be a vector graphic – not a scaled bitmap – maybe I’m wrong on this though.

And yes, I’m using opengl to draw faster than jgraphics using a FBO and then grabbing the pixels and drawing the result with jgraphics. The issue I’m starting from is to do with alpha and line blending behaviour in opengl that seems incorrect. In the case of the grid I am drawing one solution in opengl is not to anti-alias – then everything is fine. That doesn’t work for some other lines I need to do, so it’s not a total solution to my problem, which ideally would result in two draw routines (jgraphics/opengl) that look identical (or close) under all conditions.

A.