Undocumented "window" parameter in the term API wiki

[Piorjade 2]

So I am coming from ComputerCraft and the term API there is pretty straight forward and allows us to create windows to write / redirect to.

Anyway, in the term API wikipage of OpenComputers there is for example the method term.bind with an optional parameter "window", the problem is I can't find any information about this parameter and I assumed that this would be the same kind of "window" as in CC and I won't have to write my own API for it.

Do you guys know something about it?

[Molinko 43]

Here's a little demo to get you started.. But, the warning I received using this method is that it's an 'internal' method and so subject to possible change in the future. Just FYI.

local process = require "process"
local term = require "term"

local function window(program, dx, dy, width, height)
  local _window = term.internal.open(dx, dy, width, height) -- # Create a new window
  term.bind(term.gpu(), _window)                            -- # derp
  process.info().data.window = _window                      -- # Get current process, tack _window unto ...data.window
  os.execute(program)                                       -- # exec program as child process. It inherits our term window via process magic*
  term.clear()                                              -- # clean your fuckin' room
end

window('/bin/dmesg.lua', 10, 5, 65, 20)	-- # Do the dew

Let me know if this need clarification. I'll try to help  

[Piorjade 2]

Thanks!

Is there any wiki page that shows what metadata processes exactly have?

[Molinko 43]

No, not that I've seen. You can use the Lua interpreter and call process.info(lvl) to explore the returned process. Beware some of the metadata is linked with metatables and so may not appear directly* on the process handle.

[Piorjade 2]

Okay, thanks for the tip.

 

Another question (it isn't directly related to the topic, so if that's not good tell me and I'll create a new topic for it)

If I wanted to make such a system myself (a self-made term API that allows creating multiple windows), how would I have to handle redrawing the content of them? I already tried having pixels saved in a table (with information like background- and foregroundcolor and which character they contain) but that made it really slow as it iterated through the whole table and made a gpu call for every pixel.

I need redrawing if I for example have 2 windows overlap each other and I saw something in the OpenOS code about a stream for the ttys.

[Molinko 43]

From what I understand you're on the right path. What I think* you're missing is a grouping algorithm. Iterate the table for like-pixels chunks by fore/background color and character to draw together. This should result in less gpu calls overall. I'm working on something similar

[Piorjade 2]

That's a great idea!

The reason I wanted to make it is that I wanted to try to make an OS myself, idk really why lol.

Anyway, I'll take a look at that buffer library that OpenOS apparently uses for I/O.

EDIT:

I experimented with process metadata and your answer regarding term.internal.open and I don't get why the process doesn't have a "window" entry in the data table and after you set that as the newly created window it only THEN prints to the new window, which is why I also don't get why you used term.bind in the beginning as that apparently doesn't redirect input/output, it binds these components to the current window/terminal (which is still the original one at in that moment) (I attached some screenshots)

Edited April 13, 2018 by Piorjade
update on the situation

[Molinko 43]

I would definitely keep looking into how OpenOS gets things done, some of it is pretty clever. The buffer API is mostly for byte streams like files and such, maybe socket streams.

An idea I had was creating a double buffer API and a virtual gpu component proxy interface that could then be bound to the term library with term.bind(gpuProxy, windowInstance)

I think this would be workable and easily injected. Just my thoughts.. happy coding

[Molinko 43]

From what I understand term.bind just binds the window instance to a given gpu proxy. The window instance is just size info, cursor state and some other metadata. If you keep digging in the OS you might notice term.internal.open isn't used anywhere other than in the term library and windows aren't exposed anywhere to the user. That's because it's not an explicit OS feature. This is why we have to manually bind a window instance to a process' metadata ourself. As for why it's not present in the process info already has to do with that metatable trickery I warned about earlier. There is one term window, it is on the init it shell process.... I forget. Child processes inherit this window or 'term'. Hope that's not too muddy to understand.

[CptMercury 6]

@Piorjade

What also helps to speed up screen redrawing is to update your screen dynamically, so that you are only reprinting the areas that actually changed. Also if you are moving large areas on your screen, like scrolling or dragging, make sure to use the gpu.copy method.

[Piorjade 2]

On 14.4.2018 at 12:11 PM, CptMercury said:

@Piorjade

What also helps to speed up screen redrawing is to update your screen dynamically, so that you are only reprinting the areas that actually changed. Also if you are moving large areas on your screen, like scrolling or dragging, make sure to use the gpu.copy method.

Yeah, that's true, but as I said, if I wanted to have "virtual terminals" (-> "windows") and they overlap and I wanted to redraw the one in the background, I somehow need the data that was on it before, which means I have to have its pixels stored somehow.

 

Again, my methods involving having these pixels in a table lead to the whole redrawing process being really slow, as it would call a gpu method for every pixel.

[Molinko 43]

20 minutes ago, Piorjade said:

Again, my methods involving having these pixels in a table lead to the whole redrawing process being really slow, as it would call a gpu method for every pixel.

I think this is why I think a 'grouping' algorithm(if thats what it's called..) would be useful. Yes, you have to iterate every 'pixel' for its data, but you dont have to draw every pixel one by one independently. If you've heard of MineOS, it has  a pretty beefy double buffering library. If you inspect the draw method you can get an idea of how it does grouping for gpu draw calls from its internal buffer. Just a suggestion in case i haven't been clear.. 

[Piorjade 2]

On 16.4.2018 at 10:51 PM, Molinko said:

I think this is why I think a 'grouping' algorithm(if thats what it's called..) would be useful. Yes, you have to iterate every 'pixel' for its data, but you dont have to draw every pixel one by one independently. If you've heard of MineOS, it has  a pretty beefy double buffering library. If you inspect the draw method you can get an idea of how it does grouping for gpu draw calls from its internal buffer. Just a suggestion in case i haven't been clear.. 

I think I'll first try to set up a basic Operating System (I'm trying to make something like "miniOS", so basically imitate DOS a bit) and when the basic system is working, I'll try implementing your idea, if that's okay.

 

Anyway, thanks for your help!