ghaerr commented on issue #18566: URL: https://github.com/apache/nuttx/issues/18566#issuecomment-5152982941
> My recollection is that nxterm provides refresh callbacks when a region is exposed to redraw it This may have been the case with the much-older `nterm`, but that terminal emulator didn't support enough ANSI sequences to run an editor, so it was replaced with `nxterm`, which goes to a lot of trouble to quickly blit screen areas when terminal scrolling is emulated/performed. Nxterm doesn't process any Nano-X window system callbacks, and thus the user sees the screen cleared due to the automatic window background paint performed by the server just prior to sending expose events to affected windows. > The lower level graphics logic provides copies of the occluded window content That's great but will require special communication with the NX server, since it otherwise knows nothing about automatic framebuffer bitmap refreshes, and thus goes ahead and repaints the background (or foreground) during its own separate management of window rectangles. Nano-X is "software-only" in comparison with more modern designs that interface with GPUs handling some of the window painting, etc. I suppose the Nano-X server could somehow communicate with your RAM-backed window routines and tell those functions, rather than the applications, to repaint areas of the screen. This could get tricky though if an application takes a combined approach of sometimes using expose events and sometimes drawing directly during its event loop processing. All that said, Nano-X also supports "double-buffered" application windows that effectively automate the application's saving of window contents and fast blit for restoration on expose events. This model ends up using an RGBA pixmap for each double-buffered window, which of course is RAM-intensive. The application also needs to generally be reworked to only draw to its "buffered" window, never directly to the actual screen, the contents of which are then synchronized on per-display-cycle or constant refresh rate to the actual screen. None of this will work on 16-bit systems, for which nxterm has seen recent larger enhancements. I personally think the best answer is an updated terminal emulator that saves screen contents - but nxterm internals are old and messy, thus my thoughts of replacing it from scratch. Again! My [GFX](https://github.com/ghaerr/gfx) project has a designed-from-scratch Unicode/ANSI terminal emulator that handles all this and more, but it hasn't been ported to Nano-X yet. It would need to run on 32-bit+ systems. Unicode ANSI terminal emulator from GFX Project (showing rotated text using bitmap fonts) <img width="1136" height="940" alt="Image" src="https://github.com/user-attachments/assets/37a20746-38b7-493e-8828-2e6ac6450e94"; /> -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
