I am working on a full screen kiosk application in Flex 4/Air 2 using Flash Builder 4.
We have a company training website which staff can access via the kiosk, and the main content is interactive flash training videos. Our target machines are by no means 'beefy', they are Atom n270s # 1.6Ghz with 1Gb RAM.
As it stands the videos are all but unusable when used from within the Air application, the application becomes completely unresponsive (100% cpu usage, click events take approx 5-10 seconds to register).
So far I have tried:
increasing the default frame rate from 24fps to 60. No improvement.
nativeWindow.stage.frameRate = 60;
running the videos in a stripped down version of my app, just a full screen HTMLLoader component pointed at the training website. No better than before.
disabled hyper threading. The Atom CPU is split into two virtual cores, and the AIR app was only able to use one thread so maxed out at 50% CPU usage. Since the kiosk will only run the AIR app I am happy to loose hyper threading to increase the performance of the Air app. Marginal Improvement.
The same website with the same videos is responsive if viewed in ie7 on the same machine, although Internet Explorer takes advantage of the CPU’s hyper threading.
The flash videos are built with Adobe Captivate and from what I understand use JavaScript to relay results back to the server.
Adobe Air 2 recently came out of Beta (June 15th I beleive, the day I posted this question...) and this release correctly utilizes BOTH virual cores when hyperthreading is enabled on the CPU.
CPU usage when playing the flash content in the HTMLLoader component dropped from 100% to around 60%, a massive improvement.
Related
When we launch our game in the AirConsole, the RAM usage jumps really high and we get an "Out of memory" error. The only way to actually test the game is to upload a Development build with exceptions enabled and the WebGL Memory Size set to 2047. That's the only scenario, when the game doesn't crash.
We used Chrome to monitor the RAM. When we launch the game in the AirConsole, the RAM gets heavily loaded (2 GB or so) and after the game loads, the RAM usage becomes much lower (about 1 GB).
I think it is directly connected to the huge JS file that we get, when we make a WebGL build, but that's only a guess.
How can we diagnose the problem and lower the RAM usage?
Well, you need to profile memory usage by the page with the tools a browser provides - just like you would do for a desktop application.
JavaScript Memory Profiling - Google Chrome
MemoryBug Firefox extension
Diagnosing memory problems in your webpages (Windows) - MSDN
They vary in sophistication, but are basically the same as in every other garbage-collected environment. They can be divided into two basic types:
rough data: general dynamics, snapshots (incl. on events), usage by entities (DOM,JS,plugins) - identify main hogs
fine data: GC statistics, object links - locate specific culprits
When I make a change to Javascript file and save it, it takes over 5 seconds to build and restart the development server even if it is simple 10 line example app. I am new to Meteor.js so I don't know if it's normal, but I though changes should appear instantly (about a second or two) on a browser? 5-6 seconds feels pretty long time for me.
Selecting package versions and downloading packages seem to take the major part of the time.
There is one websocket pending (Chrome Dev tools Network tab) when it's restarting. I'm using Meteor 1.0.
That's a known problem they're working on. You can read about it and follow the progress in issue #2846.
There is a new issue about this: https://github.com/meteor/meteor/issues/4284
Upgrading to a pre-release of 1.3 seems one of the best options right now:
meteor update --release METEOR#1.3-modules-beta.8
And upgrading to 1.3 when it comes out (should come around march-april 2016).
Quick measurements to get a rough idea:
BryanARivera says on the thread that updating to 1.3-modules-beta.8 gets him From 6-10s to 1-2s.
I tried on the https://github.com/wekan/wekan project by changing a view component (on an early-2013 mbp with SSD):
with `METEOR#1.2.1` ~10s to reload
with `METEOR#1.2.2-faster-rebuilds.0` ~5s to reload
with `METEOR#1.3-modules-beta.8` ~4s to reload
This was my purely hardware solution to the problem of slow Meteor build times.
When I decided to get into development I was adamant that I wasn't going to run out and buy the latest and greatest in hardware until I actually knew how to code and knew what my requirements were in the long term.
So I went out and bought a used 15" Acer laptop; it had the following spec:
Memory: 6Gb RAM
Processor: Intel Pentium CPu 6200 # 2.13GHz *2
OS: Ubuntu 16.04.1 LTS 32-bit
Storage: 153.5GB HDD
With this setup I saw rebuild times of between 15s ~ 30s (including the browser refresh) of a side project using Meteor 1.4, Reactand a Mongo db instance with around 1500 records. I found these times to be excruciatingly slow when it came to making multiple changes. You can see the initial version of the project I was working on herehere.
After trying to get work done in cafe's and libraries I realised that I was much happier working at home, and once the side project was complete I decided I would reward myself with an upgrade.
My initial choices were between a Macbook Pro and a gaming PC such as the Asus ROG, but since the former are very expensive and the later's graphics abilities were of no use to me (I'm not a gamer) I ruled them both out. These being quality machines, when I compared them against reviews of other PC's and laptops I noticed that where other systems scored higher in performance, they were lower in build quality and vice versa and there was no overall winner that had me sold.
I decided, a self build was in order and that it would be great if I could fit it all into a mini-ITX board and case. My requirements became:
An SSD drive (faster read/write times than a HDD)
Ubuntu: On account of it being free and faster that MacOS
Mini-ITX: so that it can unobtrusively fit onto my desk
Quite
16Gb DDR4 RAM: this seems the bare minimum for development.
After some searching I came across these instructions for a $682 Skylake Mac Mini Hackintosh Build, which formed the basis of my build.
As I currently have no intention of working with MacOS, as per the Hackintosh instructions, I did not change the Wifi card.
My new spec list along with what I paid for each item were as follows:
Intel Core i7 Quad-Core i7-6700 3.4GHz Processor £279.97
Crucial Ballistix Sport 16 GB kit (8 GB x 2) DDR4 2400MT/s UDIMM 288-Pin Memory £121.00
Samsung 850 Pro 250GB SSD £121.00
Gigabyte H-170 Motherboard £109.00
Noctua NH-L9i CPU Cooler £35.00
External PicoPSU Power Brick £24.00
MiniBox 160W PicoPSU £40.00
Streacom F1C-WS £90.00
Noctua NF-A4x10 FLX £10.99
Making a total spend of £830 (correct at time of writing).
The case comes in two finishes; black and silver, I went with the former to keep my monitor my main point of focus on my desk. It took me about an hour as a newbie to put it all together. I imagine it would be much faster if I did this for living.
Pros:
My rebuild times were drastically reduced to only 2s using Meteor 1.4.
The PC as a whole takes only 15 seconds to boot up whereas the laptop could take as long as 2 minutes.
With the laptop, a Meteor reload would fully load the CPU whereas with the PC the 4 cores barley rose above a few percent, as viewed from the System Monitor tool.
It has a footprint of 19cm x 19cm making which is smaller than my laptop.
It was super quite, the fans were barley noticeable on most days.
Cons:
The draw back of such a small case is that there is no room for a graphics card should I want to start gaming in the future.
All the ports are at the rear. However, this does give the front a clean look.
There is no reset button but the power switch can be configured via the bios to act as a "soft" switch such that, pressing it brings up a dialogue giving you the option to restart/suspend/shutdown.
Conclusion:
Overall I am very happy with the choice of components I made and the money I saved by self-building.The PC is powerful enough for video editing and I am working towards editing my first Youtube tutorials.
Being more wise about my needs means that I am now using Docker to create isolated development environments to prevent software conflicts which in themselves can chew up time in resolving.
The component research I did means that I am aware of the massive progress that PC cases, coolers, cables, memory cards, fans have made since I left college. You can now build something not only small and powerful but also attractive with options like tempered glass, liquid coolers, custom braided cables, case strobe lighting and shaped cases.
Currently I’m trying to develop RTSP video player, which can show many streams at one time (2, 4, 5 etc). It has to be fast and be able to run on Windows, Mac and Linux.
First app version has been written on Swing and VLC. Good performance, ability to play many streams at one time on slow PC. But not impressive UI and video playing is unsupported on Mac
So, after a lot of researching I stopped on JavaFX and VLC. Great UI, support on all platforms, but performance issues on slow PCs.
Here is simple project which can play one video: https://github.com/costello/vpfx
(don’t forget to set your media link in class java/app/AppController.java, line 22)
Unfortunately it’s using too much CPU, even if I play only one video. I tried to play 2 or 4 videos (from different RTSP streams), completely nightmare.
Here is CPU usage graph on PC with Intel® Pentium® Processor E5300
(2M Cache, 2.60 GHz, 800 MHz FSB) and integrated video card: http://imgur.com/MrBv3HF
vlcj version: 3.0.1
VLC version: 2.1.5
Java: 7 and 8 (java fx 2.2 and java fx 8), same result.
Found this OpenGL discussion: How to use OpenGL in JavaFX?
But I don’t know how to use OpenGL to render image from given RGB array and even I don’t know will it help.
Ive tried asking on the blackberry forums with no luck... Maybe there are some Blackberry/Adobe experts here...
Im just about to start a project using Adobe AIR/flex for the Blackberry Playbook, I have a few questions:
If I develop an application for the playbook, will the same application be able to run on a desktop? If so will there be any differences?
What is the difference between the desktop and mobile libraries? Can I only access a subset of the SDK on the mobile device compared to the desktop?
Can I create a playbook application that can call methods to a JAVA back end, located on my server?
Thanks
Phil
What’s different about developing a
mobile application versus a web or
desktop application? While many
existing Flex concepts and patterns
carry over directly to mobile
development, developers will need to
take into account the differences in
interaction patterns, screen real
estate, and performance
characteristics of mobile devices
compared to desktop computers. As a
result, we recommend using the new
mobile features in Flex to craft UIs
specific to mobile devices, while
sharing underlying model and data
access code with your desktop or web
application. Additionally, we
recommend certain best practices when
developing mobile applications with
Flex, such as using ActionScript and
FXG rather than MXML for creating item
renderers and skins.
Taken from http://labs.adobe.com/technologies/flex/mobile/faq.html#differences
As per my usual qualifying statement: I haven't tried this. Since this is of some interest to me and I've got a bit of free time I'll give making a hero app and running it as a desktop app versus as a mobile app a shot and post back here once I have it working or find a wall.
The runtime: Adobe AIR 2.5 on mobile
devices The initial versions of the
mobile development features in "Hero"
and "Burrito" are targeted at creating
standalone installed applications
using the Adobe AIR runtime for mobile
devices. By focusing on AIR, Flex can
take full advantage of the integration
AIR provides with each mobile
platform, such as the ability to
handle hardware back and menu buttons
and to access local storage.
Running on AIR Finally, it's important
to realize that in addition to all the
mobile Flex components listed above,
you can also directly take advantage
of all the APIs that are available in
AIR on mobile devices—geolocation,
accelerometer, camera integration, and
so forth. While some of these features
are not exposed as Flex components,
they are easy to access directly using
ActionScript. For more information on
developing using the APIs provided by
AIR on mobile devices, see AIR mobile
docs.
http://www.adobe.com/devnet/flex/articles/mobile_development_hero_burrito.html
Basically it's looking like the answer to all the questions is positive.
Yes and likely yes. (as they re-iterate throughout anything I've found on the topic the controls in Hero were made specifically for touch, taking into consideration the fat finger vs the mouse pointer, my guess is it will render slightly differently on the desktop and it's best to actually develop the UIs separately, although the web-services/model can be combined into a shared library/project)
You should have access to everything provided to the desktop (plus info from GPS/accelerometer etc., but obviously wouldn't get those on desktop), but don't have nearly as good a processor so what will work on the desktop may not on a lower performance computing device, but for low resource consumption tasks this shouldn't be a worry.
Yes this is a core feature of Flex, I don't see how it would be possible to make a (useful) RIA without web services. For confirmation on this one look no further than Adobe TV: http://tv.adobe.com/watch/adc-presents/flex-mobile-part-1-beginning-a-mobile-application/ <-- that app is using a web service (doesn't really matter to Flex what the underlying server technology is so long as it can make HTTP requests against it, RemoteObject/AMFService should serve your purpose)
If I develop an application for the
playbook, will the same application be
able to run on a desktop? If so will
there be any differences?
Depends. the Air file for both desktop and Playbook is exactly the same, however for Playbook development, RIM has provided an Air library so that Flex developers can take advantage of the hardware further than just the normal Air capabilities. With that said, if your application is dependent on that extra library, it will not work on desktop.
What is the difference between the
desktop and mobile libraries? Can I
only access a subset of the SDK on the
mobile device compared to the desktop?
Desktop and mobile libraries? Do you mean the Playbook Air Library or something else? See above for the latter. Comment on this if you can clarify.
Can I create a playbook application
that can call methods to a JAVA back
end, located on my server?
Yes, you can, as long as you have internet connectivity on the Playbook.
How good is a Flex app in handling large amount of data (say, for a reporting kind of application)
Are there any memory management issues that need to be kept in mind while developing for such an app
Are there any issues in running a Flex app on a Mac?
1) great as long as you're not transferring huge amounts of data at one time using HTTPService. A good AMF remoting like amfPHP runs super fast.
2) Flash player runs on the clients machine, you would need to make sure you aren't using more memory than they have available.
3) If I remember right flash player is kind of weak on the mac, much slower than PCs but I haven't bench-marked them in a while
Flex can use a lot of memory in a poorly written application. A well written application will manage it's assets well and will not use more memory than needed. Flex is wonderful for a reporting application since you can do data manipulation on the client and do a lot of client side analysis and re-presentation of data.
Profiling. Flex Builder has a decent memory profiler so make sure you use it and don't leave dangling references around. Event handlers can keep references you don't realize if you don't clean them up. States can also cause problems if they're used inappropriately--to manage the state of the whole application for example instead of in a small scale within individual application components.
Flex is slower on the mac. This is largely due to the limited api provided by browsers on the mac. On PC the Flash Player has access to GPU acceleration and other low level API's which can make it faster. This is going to get better when Flash Player 10.1 is released since it will take advantage of new core animation api's available in Safari 4 on OSX 10.6.