Good Practices for JavaScript “asm” sections in DWS/OP4JS
The compiler supports writing “asm” aka JavaScript section in the middle of Object Pascal, there are a few good practices as well as tips to keep in mind, let’s review the menu:
Fixing TCriticalSection
Don’t publish your .dproj/.groupproj
Just a quick reminder to everyone publishing Delphi projects with source:
Please don’t publish your .dproj & .groupproj, only publish the .dpr & .dpk
The reason? Those files include machine specific settings, such as paths, DCU/DCP/BPL/EXE output directories, along with your favorite debug & release options, which are likely different from that of your fellow developer.
It’s possible to have them manually cleaned up, but that’s tedious and error-prone short of checking their xml content manually.
Pretty much every single project with a .dproj out there has issues: that’s from major open-source projects to Embarcadero’s own samples. None of them (of you) got all of them cleaned up right.
But even getting the published .dproj right doesn’t matter: .dproj is where compile options are stored, options you’re just bound to change and adjust. When those .dproj are in a project you synchronize with via version control (SVN, GIT, etc.), your locally modified .dproj will likely conflict next time you synchronize, sometimes in unintended and not immediately obvious ways.
Hopefully in a future version, Embarcadero will split the .dproj, so that machine-specific settings are in a distinct file from the non-machine specific settings, which would essentially be per-project relative paths to the source files.
Ad interim, .dproj are just a kludge by design.
Rendering semi-transparent objects in FireMonkey
The question has (predictably) popped up several times now, so here is a recapitulative post with workaround.
FireMonkey (as of now) doesn’t support rendering semi-transparent objects in 3D.
Delphi XE2 VCL Styles and 3D
…or when the old/new VCL mule shows it can still kick!
I was asked how hard it would be to do yet-another-Cover Flow-clone with VCL+GLScene, and how that would stand vs using FireMonkey on Windows.
FireMonkey’s TCube & Tessellation
If any of you had a look at FireMonkey’s TCube object, you might have noticed rendering it is quite slow and quite complex.
If you were curious enough to look at the code, you might have noticed that TCube is actually a static mesh made up of 452 vertices, 1440 indices and 480 triangles, instead of the 8 vertices and 6 quads (12 triangles) one could have expected.
Memory Manager Investigations
André Mussche on Google+ investigated the performance of several Memory Managers for Delphi, in single-threaded & multi-threaded situations, with detailed results and charts on performance and memory usage.
Great work and interesting findings!
A look at the 3D side of FireMonkey
This post was actually written sometime ago, alas XE2 Update 1 didn’t change much.
I’ve been looking at FireMonkey 3D side, by that I mean strictly the 3D side, not the UI components, or the 2D. Here are some observations, most born from maintaining and developing 3D software in C++ and later with GLScene, and with an eye to eventually porting some of GLScene code to FireMonkey (after all, most of GLScene’s code is actually linear algebra stuff, mesh manipulations, file format imports, etc. and not OpenGL-specific).
TdwsRttiConnector: read anything, write anything
…or to be more accurate, many things the Delphi RTTI can reach, DWScript can reach.
Taming the Chrome Web Store
Well, “taming” is probably too ambitious given the jungle that the Chrome Web Store is, especially as this post is restricted to publishing a standalone DWScript/JavaScript app into the Web Store in a few simple steps.
Interestingly enough, it seems that publishing Metro apps for Windows 8 will follow a similar process, according to the developer preview.
I’ll use the Flock Demo as an illustration, and turn it into a packaged app, that lives in Chrome and can be access off-line.