I have a chart in my current web app that I’ve implemented in canvas. I’d like this to work in IE8, but excanvas doesn’t seem to support translucency or composite operations. My fallback solution is to render a chart on the server as an image and send that out to IE8 instead of rendering it client-side.
I’d assumed there’d be a canvas gem that I could use with a direct port of my JS code to Ruby, but I can’t find anything. Has no-one done this? If not, what would people recommend? It’s not a particularly complex drawing, but I’d like to keep the amount of duplication to a minimum.
(It’s worth pointing out that I’ve considered using a headless Webkit to render and return a data URI, but I expect this would be fairly slow to spin up. Another possibility is to pre-render all the possible charts – somewhere around 120K of them – but that feels like a last resort!).
I haven't found such an implementation.
There is at least one canvas implementation for node.js. You could use it to write a small node program to generate the images using the exact same code you're using on the client. It wouldn't be the most efficient solution but I'd guess it'd be better than using PhantomJS or the like.
Related
I want to use Electron as a debug overlay for a Vulkan Render Engine im building. Since i have a lot of requirements on this debug tool writing one in engine myself would take way too long. I would like to use electron instead of Qt or similar since i feel its a lot more powerful and flexible with less effort (once its working).
The problem is now that i somehow either have to get my render output to electron or electrons output to my engine. As far as i can tell the easiest solution would be to copy the data back to cpu then transfer it. But that would be extremely slow and cost a lot of bandwidth. So i was wondering if there is a better solution.
I have two ideas to make it work but i didnt find any ways to implement them or even anyone talking about it.
The first would be to have electron configured to run on the gpu somehow get the handle for the output texture and importing it into my render engine using vulkan external memory. However as i have no experience with chromium and there doesnt seem to be anyone else that did it this i dont think it would work out to well.
The second idea was to do the opposite. Using a canvas element with webgl and again using vulkan external memory to copy the output of my engine to a texture and displaying it. I have full control over the draw process here so i think it would be a lot simpler and more stable. However again i found no way of setting up a webGL texture handle as an external memory object.
Is there any better way of doing this or some help on how to implement it?
I'd like to have an interactive floor map (so they're not huge) in my application. The maps will be different for every user, but contain similar elements which only differ by quantity and location. The application will show the map, identify certain elements and link them to information from the database.
To design and store the map, I'd rather not roll my own editor and/or come up with some custom file format. However, it would be nice if the format were open and easily readable. SVG seems to be the perfect candidate for the job. All there needs to be is a convention of how to name the elements to make them identifiable. But how to go from there? I need something that can render the SVG and distinguish between the different layers.
TSVG can do exactly this but depends on FireMonkey which I'd rather avoid - it's not even present in Delphi 2010, so I'd have to use another version and do DLL tricks.
Another option would be to use the Chromium Embedded Framework and create the map using HTML, CSS and JavaScript. That feels very bulky, and would be hard to get right.
Are there any simpler ways to do this that I overlooked, either using SVG or perhaps something completely different?
I'm not sure if a GIS system is appropriate for this. It may very well be overkill.
In the end I decided to go for D3.js using Chromium Embedded, to have a flexible and more portable solution.
There seems to be a lot of conflicting information out there. It might be that support has increased recently, or changes to adobe.com/air have made some information difficult to find - but I can't track down a definitive list of things to avoid.
I know that actionscript won't run in loaded SWFs, I know that some people say that filters and blendmodes and halo components won't work. I've also read many posts saying they will (at least that blendmodes will, and that halo will run, but slowly so still use spark)
I have a large amount of AS3 code to plan for upgrading to work on iOS, but at the moment I have no idea what things will break (or what things will break when those things have been fixed!)
Is there a list of unsupported APIs, or iOS dos and don'ts?
Thanks
:S
First, yes. Externally loaded SWF's will not run. You can however embed SWF's/SWC's into your project and include them inside of your package.
As far as Flex components, stay away from Halo. You should use Flex 4.6 and stick to components with mobile skins. I recommend downloading Tour de Flex http://www.adobe.com/devnet/flex/tourdeflex.html to get an idea of whats available.
As far as blend modes go, I'm not really sure. I haven't used them in mobile yet. However filters are supported but they are expensive. For drop shadows on rectangles there is something called RectangularDropShadow. This is actually a component and therefor less expensive. However it can only be used on rectangular groups.
You should have access all of the AIR API's. You will however be restricted when using some of File related classes since I don't believe you can leave your Appliaction Storage Directory.
One big performance tip I can give is to use AS3 over MXML whenever possible, ESPECIALLY when creating item renderers. Use BitmapImage over Image whenever possible, again especially in item renderers. Use cacheAsBitmap whenever you have images that don't change often. And stay away from any Flex component that doesn't have a mobile skin.
You may also want to read up on View and destruction policies.
http://www.adobe.com/devnet/flex/articles/flex-mobile-development-tips-tricks-pt1.html
This link also has some more performance tips
http://www.adobe.com/devnet/flex/articles/flex-mobile-performance-checklist.html
I need to add printing capabilities to an app and I have been looking around for information about printing. Logical/physical sizes, dpi, font scaling, etc, lots to digest since I never programmed printing into any app before.
Are there any sites that would offer a primer on the topics of page sizes, margins and all the other elements required to understand printing on Windows? I've been looking around for a while but what I find is either cryptic or years old...
I've been playing around with TPrinter, but I would like to build solid printing functionalities and understand what I'm doing better.
Using a report solution is not an option, even though I'm sure it would provide better results much sooner.
Two links to get you started:
Printing with TPrinter
Printing via the TPrinter Canvas
I think that you are looking too lowlevel.
Try looking at the build reporting tools (Rave or whatever is in your product).
Personally i am using a product called Report Builder from Digital Metaphors.
But if you want to do the lowlevel stuff lot og good information can be found at efg's computer lab - printing
Well, I have done things a variety of ways in the past, including the "hard way" with TPrinter. In fact, I recently had to do that again to run a special inventory label printer.
On the other hand, sometimes you are better off taking work others have done and using it for your benefit. I agree that ReportSmith isn't so great, and also it's Delphi (and Windows) specific. Using Excel or Word has those limitations, plus the fact that the user has to actually have them installed.
One thing I have done to make printing easy for some simple applications is just to generate an HTML file and call the user's web browser, then they can print it. HTML tables can be created relatively easily for numerical data, and you can include photos, etc. as well. This works well for some applications, and works on every platform where a web browser is installed. The downside, of course, is that HTML isn't the most precise layout language.
The version of Delphi you´re using is important. A number of Delphis came with print engines like ReportSmith (ugh). Another option thinking laterally is to use MS Word as a print engine. I´ve hooked into instances of Word & Excel before & utilised their functionality. As to raw printing using TPrinter or the print method of TForm you´d have to be pretty desperate. I seem to recall the Pacheo / Texeira Delphi books coming with a pretty good overview so you might want to see if you can find a copy of that somewhere.
Quite a few methods exist for passing data into a Flex binary from a Rails application. Right now, I'm using the old e4x resultFormat with a xml.erb template. I've done AMF before, but I feel like inlining parameters into the embed itself is a better solution because you don't have to wait for the browser to load a swf binary and the binary to make a web request.
Taking all of that into account, what is the best practice for rendering a Flex widget with a Rails back-end these days?
Sounds to me like you shouldn't use Flex at all. Flex is great for writing applications that load and display data, but is a huge overhead if you just want to display charts. If you're worried about delivering the SWF and the data in two separate responses, you should be worrying about the 200-300 K overhead of the Flex framework.
Go with something more lightweight like Flot and deliver the JavaScript code that generates the charts along with the data. I don't think Flex is a suitable platform for what you want.
If the chart is just a graphic you are placing amidst normal html content, your solution of custom compiling the swf may be a good one. Of course you should still explore alternatives like Theo's suggestion.
If your whole application is flash, it's a toss-up. If it is fastest to simply import a swf, go ahead. However, if you need to make things any more interactive, use the data elsewhere, or fetch new data, it would probably be best to use xml templates as you are, or the ActiveRecord::Base#to_xml method if you're lazy.
It depends, are you going to want the charts to be 'live', as in get updated in real-time when data changes? If so then using AMF with a Flex native RemoteObject gives you plenty of polling options, you can also just use a simpler Flex native HTTPService.
Read about them both here: Flex Actionscript 3.0 Documentation