Nano-X - Window repaint problem

[ghaerr]

Nano-X - Window repaint problem

[ghaerr]

Hello. My env. Raspberry Pi Linux raspberrypi 4.14.98+ #1200 Tue Feb 12 20:11:02 GMT 2019 armv6l GNU/Linux Microwindows config - config-linux.fb. Problem - The window does not redraw properly after its movement.

Does it only happen with that just demo, or all the demo-* demos? You might also try some of the mw* demos (win32 api). Try dragging quickly, then slowly. Type a few characters afterwards. If the main loop is being held up somehow in nanox/srvmain.c::GsSelect(), then the full repaint may get delayed due to hanging. There is a small possibility this is also hanging in the mouse driver, are you using MOUSE=DEVICEMOUSE in config? Also set VTSWITCH=N. The proper event gathering routine GsSelect() is selected using the UNIX and HAVE_SELECT defines, which are set by default if ARCH=LINUX-NATIVE or LINUX-LINARO. Check ARCH= in config, and then check the Arch.rules section for that ARCH. Also, it looks like your RGB colors are BGR, since the title bar should be red and its blue, and the background has too much blue in it. Set SCREEN_PIXTYPE=MWPF_TRUECOLORARGB instead of what I’m guessing is MWPF_TRUECOLORABGR now and this should be fixed.

[JulStrat]

Hello.
Coming back.

Does it only happen with that just demo, or all the demo-* demos?

Yes. It's general behavior for all nano-x demo-*.

You might also try some of the mw* demos (win32 api).

mw* demos repaint window properly, but have other problem. I can't resize window.

Try dragging quickly, then slowly. Type a few characters afterwards.

Dragging window (nano-x demos) in up-left (only) direction works properly, any other direction repaint window after mouse double click in window (with 2-3 sec delay).

I have tested MOUSE=GPMMOUSE setting with same results.

My config - config-linux.fb

ARCH=LINUX-NATIVE
VTSWITCH=Y

I will check VTSWITCH=N also.

Thanks.
Best regards.

[JulStrat]

P.S. If I switch to other VT and then back to original - window repaints!

[ghaerr]

Dragging window (nano-x demos) in up-left (only) direction works properly, any other direction repaint window after mouse double click in window (with 2-3 sec delay).

With this information, I’m pretty sure the problem is related to the blit during the window move when VTSWITCH=Y. I will have to look into the vtswitch code, but haven’t been able to run it since I’m developing on OSX at present (no framebuffer). A temporary workaround should be to look at the function nanox/srvfunc.c::GrMoveWindow(), line 451: change “if 1 &&!SWIEROS” to “#if 0” and that will cause a different move routine to be used.

I will check VTSWITCH=N also.

I’m definitely interested in hearing the result with VTSWITCH=N. Regards, Greg

[JulStrat]

Hello, Greg !
I updated my repo up to your commit dfe93ab .
And now window (nano-X and nuklear demo apps) repaint properly without your workaround in nanox/srvfunc.c !
Regardless option - VTSWITCH.

Regards,

Julian.

[ghaerr]

Great news Julian! I'm still not sure whether VTSWITCH might be broken but I have fixed some other issues in the window manager. I'll consider this issue closed.

[ghaerr]

Julian - just wanted you to know that I finally actually debugged your problem. I installed a linux framebuffer VM on my laptop and found the exact same window redraw problem you had. The problem is now fixed, it was related to two problems, but would not show when the SCREEN_PIXTYPE was set to MWPF_TRUECOLORARGB, which was not the default for config.linux-fb. The screen colors were also incorrect. Both are fixed now, and the config file can be set to either SCREEN_PIXTYPE value and all works ok. I also tested VTSWITCH and it works correctly.

I am seeing some problems with the keyboard being left in non-echo mode after exiting from a nano-X application (say demo-ttfont) using the close box in the app, but not when hitting the nano-X server QUIT key (which is BREAK/Pause or now also ESC). I am still working on this problem.

[JulStrat]

Hello, Greg.

The problem is now fixed, it was related to two problems, but would not show when the SCREEN_PIXTYPE was set to MWPF_TRUECOLORARGB, which was not the default for config.linux-fb.

Good news! I am testing your fixes on Raspberry.

Regards,
Julian.