TURBU Tech

I just got out of the DelphiLive keynote, presented by Michael Swindell and various other members.  As you can imagine, it was mostly about XE2 and demoing the new technologies, with a lot of talk about FireMonkey and using it for cross-platform development.  Here’s what really caught my notice:

Michael Swindell opened it up.  He was talking about the recent advances in UX (user experience) technology throughout the computer industry, and he explained how FireMonkey is designed to provide a modern interface and user experience.  He had a very interesting story about a dentist visit a few years back.  He went in one day and found that the dentist’s office was modernizing a lot.  All the medical records were being computerized, moving out of the file cabinets.  He was really impressed when they showed him the new system, especially as the software came from a Delphi shop.  When he went in to talk with the dentist, all his patient records were up there on a big screen, and he was really proud of what they’d done with Delphi.  Then the dentist tried to show him a new feature and, as Michael put it, “all the pride turned to shame.”

He had to grab a mouse and try to use it with one hand, clicking around through the interface, all while trying to hold a miniature camera inside Michael’s mouth with the other, and it was a big, clumsy mess.  It would have been a lot easier for him if he’d had a touch-based system on a tablet, or example.

He mentioned that a lot of new interface and display technology is starting to show up on the market.  Samsung, for example, has just started to mass-produce transparent LCD screens.  (He mentioned the movies Avatar and Minority Report as examples of transparent LCD screens in use, which kinda bugged me.  I wish people would stop talking about “Minority Report interfaces” as if they were something realistic, because they’re anything but.  Sure, they look cool in movies, but there’s a good reason why all successful human interface devices have always required little wrist movement, minimal elbow movement and zero shoulder movement to operate.  Trying to run a real-life “Minority Report interface” would wear your arms out very quickly.)

He also mentioned GPUs.  He said that all computers from desktops to smartphones have had GPUs as standard features for the last decade, and they’ve got more processing power than your CPU, but they generally sit idle.  He said that finding ways to use the power of the GPU is a major focus for Embarcadero.  All the FireMonkey visuals are drawn with the GPU, and they’re looking into ways to do general-purpose computing on the GPU with Delphi, for a later version.  CUDA was mentioned a few times as an example of the sort of things that can be done with a GPU, which I find interesting.  CUDA and OpenCL, CUDA’s non-NVIDIA competitor, both use script languages that look like someone took C and beat it with an ugly stick.  If they could come up with a Pascal-based GPGPU script language, that would be awesome!

After Michael, John Thomas spoke for a while, talking about FireMonkey.  He called FireMonkey “a full application stack” that makes it very easy to simply recompile and run on a new platform.  But unlike other cross-platform solutions, FireMonkey a full native code framework; no VMs to slow down execution and limit what you can do with the system.  He also mentioned that all FireMonkey controls are drawn with vector graphics, leveraging the GPU, so everything scales properly. (Even at high DPI! Finally!)  He also mentioned that FireMonkey “is not a game engine,” despite all the heavy graphical focus, but it’s a general-purpose application development framework.  I found that interesting because of what happened next.

Next came a bunch of FireMonkey demos by Anders Ohlsson.  He showed various instances of graphics and 3D objects rotating and moving around on-screen.  One very noticeable issue with the demos was that when he made the window larger, everything got slower.  He mentioned that this was because the animation was linked to the Application.OnIdle event.  I found this a bit funny because “FireMonkey is not a game engine,” but if it was, they would have a game timer available, which you can hook into Application.OnIdle to decouple animation from the system “heartbeat” and provide a constant rate of speed even with varying levels of processing power.  (I talked to him afterwards and explained the basic principle, and he came back about half an hour later to show me everything running nice and smooth and at a consistent rate on his demos, so that’s cool.  Maybe someone will make a game timer component for FireMonkey.)

He also showed off an impressive collection of GPU-based shaders that can be applied to FireMonkey objects in real time.  There are shaders that can add color effects, distortions, or transitions from one image to another, and they can be “stacked” to apply multiple shaders to the same object or scene.

I went to look at the shader language code that implements the shaders, though, and I was very disappointed to see that they were not implemented with readability in mind.  There are 3 versions of each shader, one for DirectX, one for OpenGL, and one for OpenGL ES (for mobile devices).  The DirectX ones are implemented as byte arrays of compiled shader code, and the GL ones are in ARB (low-level “shader assembly code”).  The GLES shaders are in GLSL (a higher-level “GL Shader Language”,) but written in a highly unreadable style.  I asked in Q&A if they had deliberately obfuscated the shaders, which makes them hard to read and study and would certainly make it harder for third parties to create new shader effects.  Michael Swindell assured me that that was certainly not the objective, and said he’d look into it and try to ensure that the shaders were easier to work with in the future.

They talked about a few other things related to mobile development, but it was really the FireMonkey stuff that stood out and caught everyone’s attention.  As Nick Hodges said yesterday when a bunch of us were talking, FireMonkey is conceptually the correct solution for Delphi cross-platform development, and a lot better than the QT-based idea they were working on last year.  Time will tell how well they’ll do with maturing it and promoting it, but for the moment I’m cautiously optimistic for the future of Delphi and the FireMonkey framework.