DSP Robotics Support

What tronic meant was that the windows library underneath, used for drawings, does not synchronizw with the graphics card, nor the monitor. The effect you are experiencing is known by the name of "tearing". Tearing means, what Nubeat described: while a frame is drawn the next frame is already done and sent to the monitor. In result you see the upper half of frame 1 but the lower half of frame 2.
This effect is of general nature, it has nothing to do witch FS or Ruby. You can see the same effect in Flash videos, for example, and generally every program that uses the windows library GDI.

I you want chrystal clear, smooth moving graphics, you have to use OpenGL/WebGL and sync you graphic card with the monitor. I'm not sure, but I think JUCE offers this with the newest version. Or you could use C++ with some OpenGL library. If you find a .dll, you could try to use FS just for starting, but do all drawings in another window that is controlled by that .dll

I think I'm quite done for my purpose:


processing at that speed, I don't have problem. The problem become when I increase speed (twice it, for example). i.e. try to change:


with


It seems that I'm not able to compensate "previous line area" module (which select the area to be draw taking care of the previous cursor and a huge limit after the current one).

I don't understand if it's a problem of Redraw Area prim that is called later (or not called at all when there are many call; Also tried True for HiRes, but nothing change) or where I am wrong here?

Area margins looks good: from previous-1 (x) with a width of current-previous+1, for each cursor position. But sometimes it forgot to "clean" some lines over the background

If I try to set previous-2 and width current-previous+1 (so a bit more space before the previous position, from -1 to -2) it works, but if I increase the speed again (+200) it fails. S&H + Trigger blocker should be correct there for store previous position at each new trigger

The counts/margins are correct: here a quick example that simulating the progression with a knob (move it slower or faster with mouse):


the redraw area for each movement get the correct limit upper/lower taking care of previous pos (+ a bit of margin for "security") till the current one (again, with a padding). As example, with these values, this shouldn't happens:


but I can still see two lines inside the Display. Seems that some Redraw Area method are executed not in order (so 3° value drawn before 1° for example; it can't clean previous one).

Is that the case? Can be fixed? Or for fast drawing its somethings you can't deal with?

I know you've been on this for a while ... and I really have no solution ... but an idea.

1. Does a BITMAP image work differently than drawing a line ??

Maybe scrolling a BITMAP of a line would yield a better result ... i don't know.

Just a thought.

RJHollins wrote:I know you've been on this for a while ... and I really have no solution ... but an idea.

1. Does a BITMAP image work differently than drawing a line ??

Maybe scrolling a BITMAP of a line would yield a better result ... i don't know.

Just a thought.

It seems to be the same:


with "Redraw Area" deactivate, you will see the same "tearing" effect, as said by tulamide.
If you enable "Redraw Area", you can decrease the tearing effect, but you don't know when the frames are rendered (by graphic card or monitor, I guess; or from C++ redraw stack operation by FlowStone); thus, some previous part (that should be cleaned) is drawn as well (as happens before, without Bitmap).

Do you see?

I do.

It was just a thought

But I do wonder ... I've seen this 'tearing' on my new digital monitor, and that happens regardless of FlowStone. It seems to happen at certain spot on the screen. It's minor, but I've seen it.

Guys, I've got how to do it. If anyone is interessed, here's the schematic:


not sure why my previous/current area subtract limit don't work, but using the Area union primitive (which is the "famous" Redraw Area module content trick) I can get the job done! Maybe can help someone in the future

This works for limited vertical height (which is the amount of pixel that can be drawn in one shot by the buffer I think).
Thanks for the right direction!

here do not...

Tronic wrote:here do not...

Are you seeing tearing so? Damn... not so good.
How would you proceed so?

I think I see an improvement ... since not be able to do A/B compare ... it seems like this is working [better].