Hi,
The speed you can expect is equivalent to any other C/C++ application, since rexx basically should call dll's to do video to image processing and display embedded GUI components/controls. Test the rexx part of e.g. GBM and you'll see. GBM provide a wide veraiety of image editing solutions if you can write C/C++ code. Adding rexx functions "on top" is compared to that quite easy.
Parts that use interpreted rexx code are slower, Yes, but those parts usually doesn't require speed as user input often limit more. It depends on what the developer do with rexx or let specialized code handle instead. You can't even notice that some GUI applications has been written in rexx as they rely on addon dll's to do e.g. the number crunching that rexx wasn't meant to handle.
Chris Wolgemuth wrote as part of a larger project DrDlgCtrl e.g. a new Image viewer control for DrDialog, it's fast and responsive as a developed DrDialog rexx app just has to deal with the stuff it does the best (strings/text/get/set settings) while the dll itself handle input and data interpretation of the binary images and display the results.
I think eCo Software has developed a control that should be very appropriate as a video sequence view port, then one just need a few rexx functions or a wrapper to be able to add it to e.g. DrDialog, VX-Rexx and/or GpFRexx as an embedded control. Then we'd have a native OS/2-eCS centric solution that behave as an OS/2-eCS app. should and we don't have to reinvent the wheel.
It's easy to call ffmpeg.exe and mencoder.exe etc. directly, but if they're rewritten as dll's they'd blend in more nicely.
//Jan-Erik