Allow editing contents while another window takes care of prompting

[videosmith]

When 'no flip' is selected for hdmi-2 and 'off' for hdmi-1, both screens scroll.

Device information

• Operating System: raspbian bullseye 64
• rpi 4b
• QPrompt Version: [1.0.0]

[Cuperino]

This is not a bug but a design choice... Perhaps an inadequate one, thinking in retrospect.

In QPrompt, the editor itself is the prompter. Screen projections are mere duplicates of the editor's contents. It was implemented this way because on tablets and phones QPrompt needs to be able to do everything from a single frame. This also comes from the goal of being able to edit while prompting; which in QPrompt is done by double clicking where you wish to type.

What I missed while designing QPrompt was the ability edit offline, asynchronously while the prompter scrolls, and post those changes later. This would require an external window to become the prompter and have screen projections copy from it while the primary window continues to serve as an editor.

There has to be a way to for the 3 types of window to exist and not have the UI feel cumbersome. I have some ideas in mind, but what are your suggestions for this @videosmith?

[videosmith]

Understood.

This approach of using both hdmi ports appears to affect the smoothness of animation, which did not exist in Imaginary on my RPi4 since only the external animated.

Also, when lowering resolution to SD as recommended to minimize the animation issue in your other app, some menus in QPrompt cannot be accessed.

For non-live prompting, I believe your single monitor edit/prompt solution is best.

For live prompting (eg: sport events) perhaps the AutoScript/ iNews approach?

https://www.autoscript.tv/products/winplus-ip-news/

Others can upload/update a script to a server like google docs or ip directly to the prompter client and it automatically downloads the updated script, hopefully only the modified sections -- maintaining the existng formatting of the rest.

[Cuperino]

This approach of using both hdmi ports appears to affect the smoothness of animation, which did not exist in Imaginary on my RPi4 since only the external animated.

This happens because QPrompt's approach to copy every frame is much more expensive than Imaginary Teleprompter's, which is to keep two individual prompter instances in sync.

The disadvantage with Imaginary Teleprompter's approach is synchronization off by several pixels and jitter occurs with every re-sync, which happens once every 5 velocity changes. The faster text is scrolling, the more noticeable the jitter is. This jitter is also impossible to avoid, even if you use a super fast computer.

QPrompt's approach to copy frames means the image will not lag more than a frame behind the original. Unfortunately, due to limitations with the Qt framework, this process happens at the CPU level, and cannot yet be moved to the GPU. Since image processing time grows exponentially with screen resolution, this can be especially hard on low end hardware, causing frame rate variation.

As the Qt framework evolves, I keep looking for new ways to copy the frame from one window to the next without having it leave the GPU. It might take a few years before a different implementation is doable. After all, Imaginary Teleprompter's compromised sync took over a year to develop, and QPrompt's approach took several months to achieve.

What I've thought about doing is enable the user to manually force a frame rate. Using a lower but consistent frame rate would result in easier to read text, which could help low end devices.

If I provide a separate window for prompting, the separate window would animate in all its fluidity. Only the screen duplicates and countdown animations are expensive to process.

Also, when lowering resolution to SD as recommended to minimize the animation issue in your other app, some menus in QPrompt cannot be accessed

QPrompt's current minimum resolution is 453x292, but it could go down to 292x292 if you use the mobile user interface instead of the desktop user interface. The problem with the mobile interface is it automatically hides the options to enable screens projections, because it is designed for mobile devices, which you can't connect additional screens to.

What I could do is enable screen projections on the mobile UI for Linux only. This would help you on the Raspberry Pi, and it would still work with most Linux environments designed for phones.

For non-live prompting, I believe your single monitor edit/prompt solution is best.

For live prompting (eg: sport events) perhaps the AutoScript/ iNews approach?

Others can upload/update a script to a server like google docs or ip directly to the prompter client and it automatically downloads the updated script, hopefully only the modified sections -- maintaining the existng formatting of the rest.

I plan on adding the ability to do remote updates. I think this could be done through MOS. If that's the case I'd rather we implement the standard than use a custom solution.