term.blitAtCoord(xPos, yPos, text, textColour, backgroundColour)

I've been messing around with GUI stuffs recently that has involved having multiple windows on screen at once. It occurred to me that it would be easier to do if there was a term function that enabled you to do a blit without having to set the cursor position first, and then reset it after. It would prevent a lot of extra calls to term, especially when updating a lot of things on screen at once.

To sum up, a function that in effect does the following, but internally on the Java side, which I assume would make it a lot quicker?

function blitAtCoord(xPos, yPos, text, textColour, backgroundColour)
	local cursorX, cursorY = term.getCursorPos() -- get the current cursor position
	term.setCursorPos(xPos, yPos) -- set the required cursor position
	term.blit(text, textColour, backgroundColour) -- do the blit
	term.setCursorPos(cursorX, cursorY) -- reset the cursor position
end

There wouldn't be any noticeable speed gain. On any modern computer function calls virtually don't impact performance, not to mention function inlining. If this were to be introduced, I think the coordinates should just be optional parameters instead of an entirely new function. But in any case, it's not that hard to type out term.setCursorPos, so would it really be worth it? A self-defined utility function would do just as well.

Lignum, on 24 August 2015 - 01:53 AM said:

On any modern computer function calls virtually don't impact performance, not to mention function inlining.

Just throwing it out there, but if that were entirely true, then term.blit() wouldn't provide the potential speed boosts that it does. They're not insignificant. "Low" impact isn't the same thing as "no" impact.

That said, blunty, you could probably get a fair performance increase by either using the window API, or constructing your own similar display buffer. The idea is to set the window to invisible, update its contents, and then reveal it. The whole thing then gets blitted at about the same speed as term.clear() executes.

Thanks for that Bomb, will give it a go. The other reason I was inspired to ask this question was the ability to update the screen without having to move the cursor, which would remove the problem of having to keep track of the cursor when multiple windows are on screen.

So far I haven't suffered to much with performance using my method above, I suppose it depends how often the updates to the screen get sent from the server to the client?

Another feature of the window API is that every window you define tracks its own cursor position for you.

I was thinking more when there are say 4 windows, one in each quadrant of the screen. If you want the cursor to be blinking in the top left window, then after blitting to any other window, you will need to remember to reset the cursor to the top left window. I know it's a very specific use case, but it just seemed that drawing to the screen would be easier if it was independent of where the cursor is…