3 Replies Latest reply on Oct 7, 2013 10:37 AM by sinious

    Oscillating performance problem in AIR for desktop

    simonjkendrew Level 1

      I’m currently developing an AIR desktop application that will be used in a gallery as an interactive touch screen exhibit, and I’ve encountered a problem with stuttering / oscillating performance that I am currently unable to resolve. I would be grateful if anyone can offer any assistance or advise as to what might be the cause, or where I might look for more information in resolving this issue.


      The application allows people to browse through a series of menus and options, and explore, photos, videos and text information. It’s designed at full HD resolution, and uses StageVideo to display a looping video clip as the background of the interface. Some of the menus are presented as carousels that can be rotated in either direction, and the items within the carousel can be selected to display further screens of information. Animation of the carousels and other parts of the interface is done using Greensocks TweenMax, which I’ve successfully used before without problem. When I run the application on the specific computer on which it will be installed, the performance of the carousel rotation and other animated items seems to stutter, or oscillate. The animation doesn’t appear to constantly perform slowly, it’s more that the animation speed seems to alternate between slow, normal, slow, normal, etc, several times a second, giving the impression of a jerky performance. The application framerate is 50fps. I’ve tried reducing it to 30fps, but the performance issue still occurs.


      When the application runs it first displays a screensaver. Interrupting the screensaver then displays a carousel menu with 4 options. When rotating the carousel, and the performance problem occurs, Windows task manager says the application is only using around 70MB memory, and CPU usage is minimal.


      I’ve run the application on 4 very differently spec’d computers, with differing results. Computer specs as follows:


      Computer 1 – My development computer

      • i7-3930K – 3.2GHz (overclocked to 4.5GHz)
      • Win 7 Pro 64-bit
      • 32GB RAM
      • SSD
      • 2 x NVIDIA GeForce GT 440 – 1GB DDR5
      • Hyper-threaded

      Computer 2 – My laptop

      • i7 Q 720 – 1.6GHZ
      • Win 7 Pro 64-bit
      • 8GB RAM
      • SSD
      • NVIDIA GeForce GT 330M – 1GB DDR3
      • Hyper-threaded

      Computer 3 – My other computer

      • Core 2 Duo – 2.4GHz
      • Win 7 Pro 32-bit
      • 4GB RAM
      • HDD
      • NVIDIA GeForce 7900 GS – 256MB DDR3
      • Not hyper-threaded

      Computer 4 – Intended installation computer for the application

      • i5-4670 – 3.40GHz
      • Win 7 Home Premium 64-bit
      • 8GB RAM
      • SSD
      • Onboard Intel HD Graphics 4600 – now disabled and upgraded to NVIDIA GeForce GTX 650 Ti BOOST – 2GB DDR5. No difference with either card.
      • Not hyper-threaded (disabled in bios)


      Computer #1 - The application runs as intended. I have had no problems with the stuttering performance. I’ve run the application on this computer when overclocked at 4.5GHz, and also with the overclocking switched off (running at normal 3.2GHz). The application works fine in both cases.


      Computer #2 – The performance varies here. Some of the time the application runs as intended, without any sign of the stuttering performance. However, on some occasions when the application is run, the performance of the animations will stutter. I cannot determine the reason for the variation.


      Computer #3 - The application runs as intended, but at a slightly lower framerate, most likely due to the lower spec of this older computer. I have had no problems with the stuttering performance.


      Computer #4 – The application has never run as intended. Every time it runs, the performance stutters on this computer.


      Flash CC Publish Settings

      • Swf settings: Hardware acceleration = Level 2 – GPU
      • AIR for Desktop
      • Render mode = Direct


      I’ve started to use Adobe Scout to investigate the problem, and have read through the following article.




      ‘Waiting for GPU’ seems to be an issue, from what I can determine in Scout. The above article says…


      “Here's a great tip: If your content shows excessive Waiting for GPU time in Scout, try temporarily disabling hardware acceleration in Flash Player (right-click and select Settings). This will cause Flash Player to fall back to software rendering, and the waiting time will vanish, so you can confirm that your problem is GPU-related.”


      … I followed the advice above, and the oscillating performance issue was gone on the intended installation computer, but the screen redrawing performance was really bad (due to the CPU rendering the app). I believe this confirms my issue is related to using the GPU. However, upgrading the intended installation computer from it’s onboard Intel card to an Nvidia GTX650 has made no difference.


      One option might be to replace the installation computer with a specification that is identical to my developer computer (#1), but I don’t think my client will have the budget for this.


      Googling the problem hasn’t provided much help so far, but I’ve seen a few other people mention ‘waiting for GPU’ and ‘synchronization between CPU and GPU’?


      Can anyone provide any clues, or a way forward to help me resolve this?


      Many thanks



        • 1. Re: Oscillating performance problem in AIR for desktop
          sinious Most Valuable Participant

          That's a pretty big performance difference. Your main machine (#1) is running dually GPUs with a faster CPU and a ton more RAM along with hyperthreading (which should under no circumstances be disabled).


          The onboard Intel HDXXXX (all of them) graphics are junk. They're for people who buy a rig to read email, run office apps and surf the web (some of it). The 'value' GeForce 650 (~$115 card) is no comparison either.


          As you've indicated you think the GPU is the issue, I think you're absolutely correct. You're using GPU at HD size in Flash along with the display list over it (for the menus, etc) which (depending on the menu complexity (alpha, etc)) will bog even a decent CPU/GPU. Setting CPU probably just evened out the bursts of bog based on rendering it all poorly but it felt more consistent.


          Going forward I would consider what you're mixing with the GPU and optimize it as much as possible, upgrade that value GPU and turn back on hyperthreading (even though CPU probably isn't your issue).


          I always give my clients absurdly high specs right off the start. They actually just rent machines for kiosks for their tradeshows.

          • 2. Re: Oscillating performance problem in AIR for desktop
            simonjkendrew Level 1

            Hi sinious, thanks for your help and advice.


            I've tried enabling hyperthreading in the bios of the intended install computer (#4), but Windows still reports hyperthreading as disabled. I've looked up the spec of the i5-4670 CPU, and it turns out it's a quad core, but does not support hyperthreading! Is this likely to have a major impact, be a part of the problem?


            Do you consider the GeForce GTX 650 Ti BOOST a poor performer? Although my development machine has dual cards, they are only GT440s, significantly lower spec than the 650? My AIR application performs fine on my development computer.





            • 3. Re: Oscillating performance problem in AIR for desktop
              sinious Most Valuable Participant

              Hyperthreading helps a bunch, offering more physical parallel paths for processing concurrence. The processor in #1 does support Hyperthreading though (you'll see them show up as physical processors in performance monitor). You're right, the target computer does not have it which is unfortunate. 


              Considering no hyperthreading it becomes even more important that things be offloaded to the GPU. Your GPU doesn't score terribly at around 3,597 on PassMark which is substantially higher than your #1 systems 440 SLI. Even still, I would think spending ~$300-$400 on the GPU would be expected for a GPU utilizing kiosk (average avid PC gamer cost) which would put you in the GTX 680 (5,707) / 770 (6,280). PassMark is just one of many benchmarks but it's an easy way to understand the significant performance difference. 


              For the future, do note that on-chip intel HD graphics require the use of system RAM. That alone is a huge halt in performance even if the memory isn't running over the FSB and is connected directly to the CPU. You not only are using system memory but much slower paths and memory as compared to the GDDR5+ speed RAM on discreet video cards. Never use Intel HD for a kiosk.


              All things you've mentioned considered, I think you need to work on how you optimize the mixing of GPU with the display list (CPU). If you simplify your carousel I bet you'll see the performance increase you need.


              If you can, for testing purposes simplify the objects in the carousel down to opaque shapes (square, circle, etc). A carousel undoubtedly is scaling and perhaps even skewing and rotating objects, so you will not get the benefit of cacheAsBitmap, causing the system to redraw each item every frame. Once what is being forced to redraw each frame is simplified as mentioned I think you'll see overall smoothness returned.


              Try not to look at the CPU usage as your guide to if Flash runtime is struggling to render your display list. Only on extremely efficient, CPU-specific tasks can you really inundate a CPU, usually something repetitious. If you want to see some real CPU usage out of the runtime, do something simple and singular like playing a very large video using the Video (CPU rendered) class. That's moving a ton of data through the CPU and you'll see it spike up.


              In contrast, outside AVM1/AS2.0, redrawing drawing tons of objects on the display list each frame, especially if the GPU is involved, becomes a battle of parallel execution in opcode. It's a ton of small work units that need processing with limited processing lanes rather than a ton of work in very few units which can make better use of few lanes. So keeping the redraws down on that carousel is going to be pinnacle to its overall performance on that hardware.

              1 person found this helpful