THIS, A MILLION TIMES THIS
This is going to make GUI development actually practical in OC! Which is kind of a thing you'll need for tablets, if they're going to be keyboardless.

When the bffer is in vram and it is switched into, its called page flipping, just to note that

Since this has been brought up on IRC before, a quick recap of what I remember being discussed/brought up back then:

• This will basically double the storage data of screens (additional copy for the backbuffer), so I'll have to externalize that first to avoid issues when saving (which I plan on doing anyway in a hope of resolving Server Rack resetting #443, where I suspect it already causes trouble with just one buffer worth of data).
• Ways of changing the backbuffer: extra methods or a mode switch (set current 'target' buffer). For 'unlimited speed' it'd pretty much have to be the prior due to how call-limits work (their hard-wired in the annotations of the methods).
• What is done where: send changes incrementally like normal ones and make 'flip()' super cheap and just exchange the buffers, or compute some the delta, overwrite the frontbuffer and send that to clients (i.e. clients only have the frontbuffer)?

Personal thoughts: I principally like the idea, since it allows updating more of the screen without the individual changes being apparent and conveying a sense of 'lag'. However a rate of 1 / tick seems unreasonably optimistic to me, considering this has to be sent over the network when it runs on servers. Some numbers for worst cases:

• Tier 3 screen is 160x50. That's 8000 chars. That's UTF-8, so up to 4 bytes per char, so in total up to 32kB.
• A full swap per tick would therefore result in an outgoing bandwidth use of 640kB/s per nearby client.
• This can be compressed, of course, but in most cases - let's take GZIP because that's readily available - the worst case is actually even worse.
• Alternatively deltas could be sent, but again, worst case i still a full re-send.
• Even if compressing it reduces bandwidth to something reasonable, it will most like increase CPU use to something unreasonable.

If you have an idea to enable this without opening an easy way of killing the network, please do let me know. I'd love to see full-frame updates each tick in OC, too, I just don't see a way to make this possible, technically speaking.

A realistic and (probably) relatively simple change would be to allow setting a backbuffer target that's manipulated at the same speed as the frontbuffer, but can be swapped instantly, hiding the incremental changes (which would indeed be the only gain).

PS: cheaty way would be to only enable this in single player mode, where bandwidth is practically a non-issue.

why not just send the commands the gpu recives, like fill,copy,flip and let the client render that.
Also, who the heck needs 4000 million possible characters?

Also, who the heck needs 4 million possible characters?

Users from Asia.

3 bytes would be 16777216 chars, that should be enough for everything.
4 bytes are 4294967296

wait wait I see what's going on here
Don't forget that 16 bits of each char on a Tier 3 display are used for the foreground and background colors!

ok, thats a thing.
When sending just the commands, a full screen fill would take..
4 bytes for char and colors + 8 bytes for the area = 12 bytes

Those four bytes I mentioned are purely for accounting for 4-byte UTF-8 chars. So if all colors change, too, that'd be an additional 2 byte per 'pixel' (fore- and background colors are packed into and stored as shorts). So yeah, it'd be even worse.

One thing could be to make buffer flip rate configurable. Default values: ssp: one per tick, smp: one every 5 or 10 ticks

That would be inconsistent(And probably some noobs complaining about how fast that works on their favorite server :-) )

Double buffering was created to reduce flickering. IMHO sending commands and allowing buffers swap would be great addition.

@Kubuxu yep, exactly that

I came here to request this feature, so I'm hopeful it can be done! The backbuffer method suggested sounds fine; it wouldn't increase bandwidth any (since the viewed screen would be remaining static while you updated the backbuffer), and the additional memory use would only be that of another screen.

How would you implement it? There's a flip() function, obviously, but it'd be simplest, I think, to also have a page() function (or some other name; I don't know if there's a page() function already) to determine which page screen-writing commands write to.

I would add method enableDoublebuffering(boolean) and all draws would be then made to backbuffer and shown on flip(). You don't need to know which buffer are you using.

I was thinking of something a la flip + setTargetBuffer (0 or 1, 0 being front, 1 being back e.g.) or such, method subject to change, defaulting to the frontbuffer for backwards-compatibility.

ETA some time after September, too busy with university before that.

So, this is how this should work. First we remove the code for uploading the whole terminal and replace it with commands, but we still keep code to upload the whole terminal for connecting clients (TileEntity's getDescriptionPacket really helps with this). Whenever a command is sent, whatever code that processes it needs to keep track of the buffer being draw to, and it also needs to keep track of the buffer that is actually being show, in this case to the clients. gpu.flip() would just be an ease of use command to invert the draw buffer and the render buffer, while gpu.set(Draw,Render)Buffer(0 or 1) would set the buffer, while gpu.get(Draw,Render)Buffer() would return the binded buffer.

A simple command would be sent just to swap the rendering buffers, thus letting the GPU keep it's current limits, and preventing us from sending a whole screen to the client every frame. Techniques like this are used everywhere in CCLights2 to prevent flickering caused by the asynchronous nature of the ClientDrawThread, so something like this should majorly reduce server to client transmission lag just by switching to a command based system.

(also the tier 3 gpu should have more than 2 buffers so you can have triple buffering)
(also we should have a command to copy from one buffer to another... kinda like lua_xcopy (or was it xmove) that lets you bring a value from one thread to another)
(also we should totally implement spacecore)
(also parenthesis.)

Edit: Made some code to demonstrate what it could do http://hastebin.com/ijoxezixul.lua

xcopy is definitely something that should be added together with this, yes. It could be implicit by having the source of copy simply be the render buffer. The question is if we'd want that, or whether it should be explicit? I guess keeping it explicit would be better since it's more versatile (and would allow copying from bb1 to bb2 for t3, e.g., assuming t3 gets three buffers).

I presume copied buffers will be handled client-side by players close enough to have the buffer data, so as to avoid the performance hit involved? And as long as we're spitballing ideas, how about some way to move buffers to and from variables? Maybe an 'image' format that includes both the text characters and (for T2 and T3 screens) the color values for each character, foreground/background? That way we could precompile animations and be able to move larger shapes across the screen more easily. (Since copying a variable [i]to[/i] a buffer would involve sending that data to all players, maybe it should take a variable number of ticks, depending on how much data's being pushed.)

To clarify, this is how I'd see this being implemented.

Now

Client and server hold the same data structure, an array of chars and color information. Lua performs operation on the server buffer and sends a network packet requesting the operation to be performed on the client's buffer.

After

Client and server still hold the same data structures, but now they have up to three arrays of chars and color information, and two integers specifying the read and the write buffers - where the read buffer is the one that's actually rendered, and the write buffer is the one that's affected by the existing operations such as set, fill, etc. Commands still work the same as before, but there are a few new commands: setting the read / write buffers, and copying between the buffers.

Lua performs operation on server as before, sends commands to clients as before.

So the only thing that really changes is which commands are available, and the memory use increases.

and the memory use increases.

Config option time?

Also a comment I made in my pusedocode was that the OS needs to
automatically set the buffers back to 0 on program end. If a program
crashes with the write pointer set to buffer 1 and the read buffer set to
buffer 0, that would mean that OpenOS would show the shell on buffer 1, but
only buffer 0 would be visible [?]

On Tue, Aug 19, 2014 at 1:13 PM, Vexatos notifications@github.com wrote:

and the memory use increases.
Config option time?

—
Reply to this email directly or view it on GitHub
#457 (comment)
.

Having a big virtual screen to scroll around would be nice.

I think you have some error in your calculation: 160 * 50 * (4 + 4) = 64000, thats 62,5 KB/client for a absolutely worst case full screen update, so if Asian players fill their screen with random chars. This is about the size of a full chunk update, and servers send those constantly to clients.

I agree that you should not ignore the bandwith usage, especially to not give griefers another way of attacking, but I think under normal circumstances double-buffering should not kill a server.

And then there is still the option for incremental update and compression. A zipped full screen update with US chars should be like 3KB/client, which is nothing a server wouldn't be able to handle.

160 * 50 * (4 + 4) = 64000

What's the +4?

This is about the size of a full chunk update, and servers send those constantly to clients.

Servers don't send full chunk updates "constantly". They send them when necessary, which is usually once per chunk per player (at least in my tests). And even then, this is comparing apples with oranges. While chunk updates can be much larger, it doesn't matter much if they get transferred at a slower speed. Meaning even if the client can only receive them at 8Kb/s or the server throttles to that, everything continues to work fine. They can also only happen exactly one at a time per client, whereas there can easily be multiple screens. I'm repeating myself here (see above), but if screens require 32Kb/tick that's 640Kb/s, and that's way above the average player's bandwidth. And way above what a game should consume.

but I think under normal circumstances double-buffering should not kill a server.

"But"? Do you mean "assuming it sends a full update each tick" or "based on what's planned"?

A zipped full screen update with US chars should be like 3KB/client

Well sure, if you're lucky. But that's far from the worst-case, and 'per client' is a pretty meaningless measure for bandwidth ;) This would still be 60Kb/s (per client), which is way too much for something that can be running constantly per screen.

+4 was the color, and you're right, I forgot that in worst case the screen needs to update 20 times / second.

Ah, I was purely thinking in text, true (since for all normal commands like set, fill etc the color isn't sent). Assuming that'd have to be sent, too, it'd be +2 (color is saved as short, one byte for the foreground, one for the background).

ahh finally someone not using ints for everything

What about scrolling? (in all 4 ways that is)

Going to close this as sort of a reverse-duplicate of #779, as that was one of the suggestions that seemed to get the most approval, and seemed most feasible. Further discussion about this topic, if desired, should take place in that issue.