Lua plugins in Neutrino-MP

[Benny]

Greetings,

Some Signal level monitoring plugin, originally from Coolstream HD box, where it works OK:

Code: Alles auswählen

local n = neutrino();
dx = 600;
dy = 200;
sx = ((SCREEN['END_X'] - SCREEN['OFF_X']) - dx + 50) / 2;
sy = ((SCREEN['END_Y'] - SCREEN['OFF_Y']) - dy + 0) / 2;

sx = math.floor(sx + 0.5);
sy = math.floor(sy + 0.5);

local m = neutrino(sx, sy, dx, dy);
local w = cwindow.new{x=sx, y=sy, dx=dx, dy=dy, name="Signal Level", icon="satfinder"};
w:paint();

local s = signalbox.new{x=sx+50, y=sy+50, dx=dx-100, dy=dy-100};
s:paint();

repeat
	msg, data = m:GetInput(100);
	n:PaintBox(1, 1, 1, 1, COL['MENUCONTENT']);  -- draw fake paintbox, not a part of original code
        s:paint();
until msg == RC['home'] or msg == RC['setup'];

w:hide();

Until i add paint call to main "n" context - it draws all other stuff "transparently" - ie screen is clear.
Something wrong with original lua script, or with lua client in Neutrino-MP?

[dbt]

Code: Alles auswählen

w:hide();

This erases screen i think.

[Benny]

This erases screen i think.

a) Don't think so, hide() should work only after certain key pressed on RC, look at example - http://wiki.tuxbox-cvs.sourceforge.net/ ... tWindow:de
b) It works on Coolstream (don't know about Neutrino version there)

[martii]

The SPARK implementation utilizes two frame buffers:
- a back buffer with a fixed resolution of 1280x720
- a front buffer with variable resolution (which depends on the video source)

The draw/paint/render methods write to the back buffer, and after that the back buffer needs to be copied (and scaled) to the front buffer. This is what the blit() calls you're seeing in the C++ code are for, and appropriate (in your example code: "n:Blit();") calls are required from LUA too, unless you're using a method that already incorporates them (e.g. s:paint()).

IIRC: seife's newer code does continuous blitting (calls blit() a couple of times per second) which eliminates the explicit blit() calls which are spread all over the code (but I didn't merge that code, on purpose).

Cheers,

martii

[seife]

IIRC it only blits if somehting changed, so only if necessary. But I have not looked at that code for a long time, and my memory might be wrong.

[Benny]

... and after that the back buffer needs to be copied (and scaled) to the front buffer ...appropriate (in your example code: "n:Blit();") calls are required from LUA too.

Ok, thanks for explanation.
So, if i meet same issue on SPARK boxes in the future, i'll need just to add n:Blit(); in appropriate place and forget about it?

[martii]

So, if i meet same issue on SPARK boxes in the future, i'll need just to add n:Blit(); in appropriate place and forget about it?

Yes. Alternatively additional blit() calls could also be added to lua handlers, e.g. CLuaInstance::SignalBoxPaint(). However, this needs to be considered with care as a blit() thunderstorm may have quite an impact on performance.

You can easily check via the web interface whether a blit() is missing somewhere if you've configured the screen shot feature to use the back buffer. The screen shot will then look fine, but the actually displayed picture won't.

Cheers,

martii

[Benny]

Greetings,

back to our sample in first post - when lua script called from Neutrino (without using luaclient, from "Addons" menu, for example), there a previous menu drawn on background, until lua script is finished.
How i can hide/close that previous menu, or clear framebuffer within lua script?

[schufti]

AFAIK this depends on how the lua-plugin is called from within neutrino; like call (return to previous neutrino gui) or jump (give control to plugin)
You can see the difference if you place the same lua plugin directly in one of the "user menues" e.g. under the yellow/blue button or have it automatically listed under the "plugins entry" (as submenu under the yellow/blue button).

[Benny]

You can see the difference if ... or

Ok, thanks for the tip. Looks like this part of code in user_menue.cpp caused "wrong" behavior:

Code: Alles auswählen

-int CUserMenu::exec(CMenuTarget* /*parent*/, const std::string & actionKey)
+int CUserMenu::exec(CMenuTarget* parent, const std::string & actionKey)
 {
        if (actionKey == "")
                return menu_return::RETURN_NONE;
-       g_PluginList->startPlugin(actionKey.c_str());
+       if (parent) {
+               parent->hide();
+               g_PluginList->startPlugin(actionKey.c_str());
+               }
        return menu_return::RETURN_EXIT;
 }

After I had removed comment tags and added "parent->hide()" issue with lua plugins is not a issue anymore.

Can somebody explain to me, why "parent" was initially disabled in this function?

[seife]

Because it was unused and the compiler would complain about unused parameters (with the appropriate compiler flags set)