Framework question (OO-design)

Hello guys,
I have following problem:
I want to create processes, where every process have his own Frame.
My idea is, that every process get mouse_xxxx events relative to his own Frame.
A Frame is a term object created by window.create.
My first idea was, to create a table, with 19 tables, containing 51 tables, pointing to the process (coroutine), which is on top and
the program looks up by every mouse_xxxx event, which process is meant and resume it with modified coordinates, relative to the Frame.

The problem is the performance:

1. Every time, when a click event was fired, the program has to iterate through 2 big tables: first through the lines, and then through the line.
2. Every time, when a Frame was moved, the program has to move the process to his correct position in the screen table.
3. Every time, after a Frame was moved, the program has to point the old pointers to the new process under the old Frame.

I hope someone understand what I mean and thanks in advance!

I wouldn't make a huge frame table, I'd have one table containing more tables which you can loop through.

Ex:

local lookup = {
   [Frame] = {minx = 3, miny = 3, maxx = 30, maxy = 5}
}

function distributeClick( event, button, x, y )
   for k, v in pairs( lookup ) do
      if x >= v.minx and x <= v.maxx and y >= v.miny and y <= v.maxy then
         k:resumewithevent( event, button, x - v.minx, y - v.miny )
      end
   end
end

Depending on how your exact framework is set up, the best solution may vary significantly from what I've outlined above. This is just a general direction I would recommend.

19*51is only 969 which any sound like a lot but for a simple iteration loop that shouldn't even be causing any problems or delays at all. Are you able to post your code so we can figure out what part in your loop is causing the biggest part of the delay

LyqydOS's mechanism for correctly distributing mouse clicks can be found here. This is going through the buffers in the compositor (which contains all windows in the order they are stacked on screen), and finding the process' window that matches that buffer, then seeing if the click was within the borders of that window. It may seem like it would be slow (three nested loops, oh no!), but it's actually quite fast. Users do not notice any delay in their input reaching the appropriate process.

I have found that rather than using a two dimensional table for screen related tables it is quite a bit quicker to use a single array (especially on Silica/CCNext, where about 60k pixels). Essentially, you use this equation to set/get a pixel value:

pixels[( y - 1 ) * width + x]

Just little thing to help with performance.

oeed, on 21 August 2016 - 04:23 AM said:

I have found that rather than using a two dimensional table for screen related tables it is quite a bit quicker to use a single array (especially on Silica/CCNext, where about 60k pixels). Essentially, you use this equation to set/get a pixel value:

pixels[( y - 1 ) * width + x]

Just little thing to help with performance.

Wait, what? CC computers will have a resolution of 60k???
Two questions:
What is Silicia?
Where can I look for the plans in future?

Sewbacca, on 22 August 2016 - 01:47 AM said:

Wait, what? CC computers will have a resolution of 60k???
Two questions:
What is Silicia?
Where can I look for the plans in future?

Well not CC Computers, but there's this 3 page topic about what he's referring to.

Silica is basically a UI framework oeed is making. There's a gitter for it, but it's extremely off-topic some all of the time.