gui freeze after interacting with console text (windows/linux)

[yal2du]

on windows, a love2d app is started from the command line and runs normally. print() is used to output debugging info to the terminal. if the terminal is clicked (once) to bring it to top focus, and then focus is returned to the love2d gui window, things run as expected. however if any console text is (inadvertently) clicked/marked/selected/highlighted, love2d will freeze once the gui window is given focus.

now, if text is marked and the system menu is used to copy the selection (or enter is pressed, or cntrl-c) before returning to the gui, things continue to run as expected.

not sure if there is any way to avoid this? first thought was maybe related to dragging the mouse into / out of the gui with a key depressed, but this doesn't seem to be the issue.

edit to add: on lmde copying text out of the console will halt the gui display update, however love.update is still being processed as evidenced by fresh print() text lines appearing in console.

[pgimeno]

Are you using lovec.exe? If so, does it make a difference if you turn the console on in love.conf? (not likely, but worth a shot)

[yal2du]

Are you using lovec.exe? If so, does it make a difference if you turn the console on in love.conf? (not likely, but worth a shot)

yes using lovec. good suggestion, alas setting t.console to either true or false isn't changing the behavior. i am beginning to suspect it is something in my code or configuration (vaguely remember this happening before in different app, maybe even on linux). will post a follow up if i figure out what it is.

[yal2du]

replicates in my windows 10 environment with following code

Code: Select all

-- test console hang

-- start app with lovec.exe
-- click on gui
-- raise console to foreground
-- select some text
-- click on gui window to give it focus
-- hangs on windows 10
-- in lmde gnome terminal, copying txt from console halts the gui from updating further

local terminate = false

love.load = function( arg, unfilteredArg )
  print('Hello');
end


love.keypressed = function( key, scancode, isrepeat )
  if key == 'escape' then terminate = true end
  if terminate then return end
  
end


love.quit = function()
   print('Goodbye');
   return false
end


local counter = 0
love.update = function(dt)
  if terminate then love.event.quit(); return end
  counter = counter + 1
  if ((counter % 32) == 0) then
    print('...')
  end
end

local iointxt = ''
love.draw = function()
  --local line = io.stdin:read('*l'); if line ~= nil then iointxt = iointxt..tostring(line) end;
  love.graphics.setColor( 0.7, 1.0, 0.8, 0.5 )
  love.graphics.points(400, math.floor((counter/64) + 64 ))
  love.graphics.print( iointxt, 200, 200)
end

[yal2du]

after adding a love.draw routine that draws a moving point to each frame, it became apparent that love2d itself freezes whenever the console is in focus and the console output client area has been clicked (i.e. not title bar or scroll bar or border). it resumes after pressing enter or cntrl-c.

also when testing on linux i've noticed that copying from the terminal window halts further updates of the gui (though love.update is still being called; print() called from within it is still added to console); updated the thread title to reflect this.

all in all, probably unavoidable behavior stemming from window message handling mechanisms on both platforms; vaguely recall on windows that it spawns message queues on random threads if they invoke certain api calls, and then messages can end up on threads not expecting to handle (get/peek) them, sort of like detailed here

https://stackoverflow.com/questions/178 ... sage-queue

[pgimeno]

On Linux it may depend on your terminal program and window manager. With WindowMaker as a window manager and urxvt as a terminal, I haven't experienced anything like you're describing. It's possible that the FPS drop if you print enormous amounts of text to the terminal, because the terminal needs to render the text to its internal buffers and the screen, and that takes a bit of time. But I can't see any effects while selecting text in the terminal where Löve is running.

Does the same happen to you with apps other than Löve?

[yal2du]

Does the same happen to you with apps other than Löve?

pretty sure after re-learning about different windows subsystems that this would be an issue for any program on Windows. tldr; don't mix console and gui code on windows. guess right now if someone wants another non-freezing monitor window probably easiest thing to do is to spawn another love instance, or some other co-process, and read from a (memory-mapped) file.

With WindowMaker as a window manager and urxvt as a terminal...

nextstep! and rxvt interesting you mentioned the latter, browsed its console code after running across this phrase in the following s.o. thread

Cygwin packages [rxvt] as a more fully-featured console, with support for things like ... non-application-freezing mouse select and copy, etc. In order to run natively on Windows, rxvt shipped with Cygwin includes a tiny X11 wrapper library for Win32. Rxvt on Windows is actually a console application for compatibility reasons

https://stackoverflow.com/questions/377 ... ard-output

so the freeze appears to be issue with interaction between windows' console subsystem and window subsystem. they were never designed to play well together.

https://docs.microsoft.com/en-us/cpp/bu ... w=msvc-170
https://devblogs.microsoft.com/commandl ... le-conpty/

edit:

[on linux], I haven't experienced anything like you're describing.

i might try different distro/terminal just to compare. currently , LMDE 5 (elsie)(bullseye) w/ gnome terminal 3.38. happens after a couple of copies, and same glitch if i type in the console. using the appimage version of love2d.