This is absolutely possible, but as of writing our VCL framework doesnt have a full implementation of TBitmap. I have done a similar thing myself, where i use WASM to draw to a pixelbuffer, then quickly move that over to the DOM side of things for canvas work.
In my case I have implemented a fairly low-level pixel buffer with standard primitives (line, fillrect, rect, ellipse etc etc) and use that, but its not ready for public consumption just yet. The VCL framework is being worked on, so TBitmap will no doubt appear soon.
For your second question: Yes, the canvas has a draw method that takes an imagebuffer or image reference. So you can reference the canvas element from wasm, and hook into the events, and then change or perform effects there. Normally you would use CSS for smooth transitions.
As for loading pictures, that is already a standard part of JS/DOM so that is common functionality. Even though you use WASM, you want to take advantage of the browsers support for image formats and just load the images through ordinary channels there (and then you can push the data back into the wasm module).
WASM is binary and can have data yes, but you dont want to embed data into the module, thats not how the JS/Browser world works (you want to be compatible with the infrastructure JS devs use, especially in a commercial product). WASM code can quickly become big, so unloading common tasks like this to the JS side is the best approach (imho). Implementing raw image codec’s as a part of wasm - when they already exists as a part of the browser would be time consuming and non productive.
I can share a demo that does this, but the primitives still needs some work. But i will post a link here when its finished. Moving the data from WASM into DOM space is quite simple. Since this is ultimately the same as DIB (device independent bitmap) coding, its much faster than ordinary canvas for raw primitives. But naturally, the standard HTML5 canvas can tap into the GPU when doing more elaborate effects. But for ordinary use, a paint program, a game, drawing control surfaces etc – the dib unit works really well. I will keep everyone updated and post a unit for it when its finished. Not much left (filled polyons and clip mapping)
Thank you much. This is very good news for me & I am very interested in seeing demo.
Perhaps a dumb question that I should research later: I’m trying to build a WASM Ap to replace a current Client/Server Ap where the Server ISAPI creates a text document (rtf format) with an included image, puts it on disk w/ a unique name, “yourDocxxx.rtf” which the Client HTML can click & download. I want to create the doc w/ WASM & have it all done in the browser. Do you see any problem. Don’t work too hard as I’ve not got to that part yet, but my bitmap is to appear on the browser AND on the rtf document.
That is a very good task for WASM indeed!
You have multiple options in this regard. You can create a http request and download the data from your server inside wasm, and then perform your preview or presentation by emitting the visuals to a CANVAS tag. So its a very good example of a “hands-on” task where wasm is perfectly suited.
Do you intend to “draw” the text in a mode so it cant be copied, or simply prepare the RTF inside the wasm and invoke a “save as” dialog for the customer?
Hi again Tampatex!
Just keeping you up to date here. There are still a couple of routines left, and im cleaning up the code so it can be used as a library + example. So should have something for you shortly
I very much appreciate your work on this. It is very encouraging for my WASM Ap efforts. The rtf document is a tech document, kinda Engineering-type, with a simple Eng-type drawing img on it – mostly straight lines, arrowheads for dimensions, and some very simple color filled geometric shapes with straight line borders. Solid colors. The text in the bitmap will be dimensions, title, & some object descriptions with arrow headed lines pointing to the geometric shapes. Drawing-wise, simple stuff. Since some lines will be on angles, I need them to be anti-aliased, i.e. no jaggy lines.
The rtf document text, separate from the bitmap, is intended to be read/write for the user so he can make changes to the programmed auto-design. I intend to allow the user to open &/or save & for some customers, a copy auto-uploaded to the server for the organization.
Rtf is a bit nasty for auto-inserting bitmaps, so I’ll need access to the Bitmap bytes. So nasty I’d really like to program-produce a pdf document instead, but never done that & do have Delphi code to create rtf’s w/ hassles every time I add bitmaps. Besides, rtf is obsolete & no longer supported by MS. I’ve also looked at “odt” (OpenDocument) which is supported by Word & an on-going standard, but I’ve yet to see an easy way to generate such a document, but it would probably be easier to insert images.
All the above done in the user’s browser with my WASM Ap. Lotta math in the Ap, but I’m comfortable the math is no problem for Oxygene, unless you know otherwise. If you happen to know anything or could pass on anyone who does know anything about auto-generating pdf or odt documents, I’d really like that too.
I may have solved my document format problem. I found a free pdf version of the OpenDocument format which will probably allow me to generate odt documents. It is J. David Eisenberg’s “OASIS OpenDocument Essentials” at http://storage.hinterland.nu/webdav/Documents/ODF/OD_Essentials.pdf.
I expect the “OD Essential” to be sufficient for the easy doc’s I’ll create. For those needing more complexity the full description is available. See “OASIS Open Document Format for Office Applications” at https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=office
For any interested in rtf, I used the book, “RTF Pocket Guide” by Sean Burke, O’Reilly. The book notes the nasty rtf image problem & does not try to explain how to do it by programming, but rather by template.
This also includes the pre-compiled *.fx file that you can reference in your own projects.
I’m going to create a clean cut example that demonstrates how to move the pixel-buffer from WASM memory into a DOM ImageBuffer object, and then blit that to the canvas in a single, fast operation.
I have to do things in steps since I also have other chores, but ill try to post the example ASAP
My open doc format specs were not so easy as an odt document is not one file, but several XML files which need to be zipped into a single jar file. Emitting the multiple files may be doable (didn’t get that far), but I don’t think it easy to have a built-in WASM module to build a jar file from multiple XML file (memory) streams. I don’t want to learn how to build a jar zipper. If you’ve heard of one, please advise.
–tex