Even on the Windows desktop, it is IMHO becoming increasingly questionable to base your UIs on anything else than HTML5 & CSS, the alternatives are not only more proprietary, but either looking responsive but dated (like unskinned VCL, WinAPI controls), or outright messy and sluggish (WPF).
Right now, ChromiumEmbedded allows you to embark Webkit + Chrome V8 engine, which will work across the board with no update or dependency issues (unlike IE9), using Henri Gourvest’s Delphi ChromiumEmbedded, you can integrate it into your Delphi applications, and use it as an alternative to VCL-based controls for many aspects of an application’s UI.
Are you really proposing using a web browser to produce a Desktop GUI. That makes no sense to me.
it will make sense in a couple of years when you can easily write cross platform AND cross hardware apps. however it’s still debatable.
There are less and less things that an out of the box Delphi application can do better than a modern browser, and more and more things where it’s becoming inferior: skinning, animation, internationalization, even computations, the list goes on and on.
For instance, Delphi only support for anti-aliased graphics out of the box is TDirect2DCanvas, which is limited and restricts your application to Win 7… While HTML5 Canvas hardware support is near universal given WebKit’s ubiquity.
Once you allow your browser to break out of its box and read/write files or access hardware, like what PhoneGap does f.i., there are very few things where you’re limited.
I agree with you… That makes no senses at all.
But you saw that benchmarks. One of our beloved Delphi greatest features is efficiency. We loved to say we develop fast, deploy fast, compile fast and RUN fast.
If Delphi or any other language begin to slow down, I am one of the ones who will leave it alone… It would be a sad day… 🙁
IDK if you tested that on your example. Theres a different performance when I start the soft and when I click in the “Reset” button. Using your pre-compiled example, I’ve got ~164,4 when start, ~254,8 “standard” when click in reset and ~103 SSE version, while got 115 in Firefox4 version on my Pentium E5300 2.6 GHz.
But using my Delphi 2010 compiled version, I’ve got ~164 when start or click, and ~126 SSE version.
The difference with the “reset” button is due to another shortcoming of Delphi, on the original post, look down to the comment by Victor for an explanation. It all boils down to Delphi not properly aligning the stack, so when you have alignment-sensitive code (such as when doing maths…) the performance depends on the state of the stack.
Ohh, I think I should reread comments when rereading posts…
But what made me comment about it in this topic is that in Delphi 2010 that is not a problem…
As Victor said: “I hope the new Delphi compiler will eliminate this”. That was not in an older compiler (neither in Delphi 7, I’ve tested it)…
Alas the stack state is purely circumstancial, a change in any function called before the call to the Mandelbrot functions can result in a different stack, if a VCL function involved has an extra (or less) integer parameter on the stack f.i., it will change the alignment by 4 bytes.
Please have a look at Raudus. http://www.raudus.com. It is a framework to build web applications in Delphi.
I gave Raudus a try a few months ago, was impressed, however the lack of source code is really annoying, not to mention the fact that back then I could install only in Delphi 7, I wanted in Delphi 2010
It looks interesting, if a bit different. The lack of modern Delphi supports is very limiting, let’s hope it’ll make the jump into the Unicode world!
yeah… you right… don’t you hate when random circumstances rules the behavior of your code?
Thanks for sharing this great info. i have never heard of that Delphi can write web applications.
Comments are closed.