UI causes tasks to pause until dropped (Timeout/scheduler issue)

Xaon420

When dragging and moving the console window around my monitors (console module only), the print function still works correctly with or without tasks (they are printed to screen even if im dragging or resizing the console window). this is expected

However i want to use the UI module and i like it, along with canvas it holds up really well in features but the only 2 issues im having is when i drag a window; all functions and tasks not related to ui module stop working (and events as well).

So this means any prints/calls to the console module or another function/task at all also stop as well. even if the only other task is just a while loop printing to the console.
Looking at the UI module docs it seems there is no way to fix this, but i would expect the lua scheduler to at least give a few cycles to the tasks the user makes.

though i did note even if UI module is ran via calling a task as a function or the Async function (or now deprecated ui.run()), tasks are no longer updated at all. as they seem to sleep until timeout is reached or i drop the window.

Example of bug, Just watch the console and ui (the BOTH stop draw/prints as the canvas ui is dragged around):

--Startup UI here, will be a tray icon we can open for this UI (Will display Load, TimeSpent, Name, Total ThreadCount. tasks can be killed from there as well)
UI = require("ui") ui = UI
require("canvas")
require("console")

-- create a fixed Window (Dragging this pauses all tasks?)
local win = ui.Window("Canvas:onPait() sample", "fixed", 320, 200)

-- create a Canvas
local canvas = ui.Canvas(win)
canvas.align = "all"

-- set the onPaint() event handler to draw on the canvas
function canvas:onPaint()
    self:begin()
    self:clear()
    self:print("Hello World !", 10, 10)
    self:flip()
    --print("HELLOW") --this also fails to show on console window when dragging the ui around
end

--the task i want for the backround
local TestTask = sys.Task(function()
  while true do
    print(math.random(1,100))
    sleep(20)
  end
end)
TestTask.after = function()
  print("Task ended")
end

--as a random thought (Did not work, as assumed and noted)
ui.task.priority = 2
print(ui.task(), ui.task.priority)

--Run our task (Gets ignored when we drag the window ui around)
TestTask.priority = 1
TestTask()


--the run the UI task and wait for ours as well (in VSCode or terminal; Ctrl+C)
ui.run(win)
waitall()

Samir

Hi Xaon,

It's not a bug. It's a well known behaviour on Windows. Let me explain it.

When you grab a window's title bar to move it, or pull a corner to resize it, Windows enters a modal loop. At this moment, the operating system takes over the message handling to ensure the window moves smoothly with the cursor.

Because LuaRT performs its logic and its interface updates on the same Main Thread, the following happens:
The system stops sending standard "Update" or "Paint" messages to your application code.
Your main execution thread is effectively "hijacked" by the system's internal resizing logic.
Any background tasks, animations, or data processing happening on that thread are suspended until you release the mouse button.

One idea to prevent this is to use a separate thread to run the message loop but it will be very complex to interface with LuaRT, and it's not planned for now.

Xaon420

Thank you for the reply, i know life got you busy more recently.

that makes more sense and kinda forgot about windows modal loop, would you be opposed to me working on that front?

One solution im thinking about is running "if (!lua_schedule(L)) return FALSE;" right after dispatching on line 722 in ui.c
though im not sure that will help at all, so ill have to assume threading seems to be my answer.

worst case ill kinda play around with threading, i would ask for a future feature similar to that. i have started working out how to add in the separate thread idea in luart.c (just haven't tested the new code yet or re-built yet with nmake), would this be in-advisable?

Samir

Yes certainly any help to improve the ui module is welcome !

Xaon420

Update for anyone else wanting to work on the DearImGui module

Well i have cloned the repo for luaRT 5.4, im still researching a better cross platform UI lib, Since ui module kinda needs to support multi-os for 5.5 and onward. That clone repo will host my module but does include the entire luaRT repo as well. once 5.5 is dropped i will start working on adding into 5.5 by itself rather than the whole LuaRT project

my end goal for this month is to have started getting imgui setup for luaRT, Currently im working out what other platforms require and the caveats (this takes a bit longer for me as im new to bigger c projects), then will push that to the main repo once done for review

Structure issue and Consideration of adding DearImGUI

Currently we could keep the older ui.c structure, but it may be simpler and less complex (to the user) if luaRT uses DearImGui, with it; the LuaRT vm can autoswap to the correct Backend for the users hardware (if not already done by imgui or allowing it to be set via enum/string by the user).

This could be its own new module, but would work for any platform LuaRT and ImGui is supported on (Mac and linux in this case).

Other ideas?

if one could find a UI library for multi-os that would be huge, since im already considering making a new module for the DearImGui library. we could also use 3 or 4 lib's for each OS as its needed, but with ImGui we can use whatever backend we need for the same feature-set.

The Old UI.c module

keeping the current UI module would be fine (imo) since it is using the main thread and is baked in really well. aside moving the window around, it works splendid for most day to day tasks, locking the window from moving can solve this.
(or a custom drag and drop system using events, this still locks up but can allow user to prepare for the movement)

The ui module could still remain as is for the windows users Called "WinUI", but mac and linux users may have their own tools. a module for other platforms is still needed anyways

the nice part is even if luaRT uses imGui as part of its included modules, at that point the older UI module could be deprecated at that time, focusing on compatibility ofc.

Samir

Sadly, there is no good C/C++ tiny multiplatform gui library: QT is heavy, wxWidgets is huge too and other attempts are quite limited in functionnality

Samir

LuaRT is modular so any other ui module could be used. This imgui module is a good idea for the LuaRT multiplatform move

Xaon420

Samir alrighty, thank you for the feedback ill start work on the new module, leaving the old UI module for windows strictly

Though i hope your week is starting off good! its nice to be working on stuff again, and just cant wait for the new vm to be dropped