FULL_SCREEN, Stage3D and OS/X is very slow?

[Mal_CanDo]

I can't find the previous version of thread, the last email I had with an update shows it as having been deleted.

Anywho, here's a demo showing the issue.

On my Mac Mini ( purchased last year ), in Safari if I stretch this link to full-screen, it is very fast ( basically full-screen other than the top header ).  If I press the Full Screen icon in the top right, the frame rate drops a LOT.

Here's the link...

http://www.cando3d.com/art

( click on the Search icon, type some text to google image search for, and press RETURN or ENTER, then wait ).  Note that some images won't be loaded due to crossdomain.xml issues - we have an optional local proxy server solution which will load all of the images, but this doesn't show loading progress ).

I'd be interested in hearing if any other OSX users are seeing the slow down problem ( or even Windows users ).

Many thanks...

Mal

[jeromiec83223024]

When I look at this in Safari with Flash Player 11.8.800.95 on OSX 10.8.4 is that performance is fine in both embedded and full-screen, unless the app is actively trying to load images.  Once the loading process is complete, performance returns to normal.

I see a similar performance hit in Firefox, but it definitely appears to be more severe in Safari.  Most of the network activity is handled by the Browser, so it may be more performance intenstive there.

I'd recommend taking a look with Adobe Scout to see if you can identify any hot spots in your code.

[Mal_CanDo]

Hi Jeromie,

Thanks for taking a look, and for the feedback!

The performance drop I'm seeing is just going from windowed to full-screen ( even if no images are loaded ) - the FPS drops from a very smooth windowed version, to a mildly smooth full-screen version.

I'm seeing the issue on a Mac Mini ( about a year old ) with 10.8.4.

The loading performance hit issue is mainly the fact that I'm kicking off 50 image loads in a short space of time - I'll code up a system shortly to load a limited amount, and try a new load as an old load completes, but this is a different issue that I'm seeing from toggling full screen / windowed.

[Colin Holgate]

I don't think it's a fullscreen issue, the pwerformance is poor even if I just make the browser window bigger. It's as if you're not using GPU at all.

[jeromiec83223024]

Interesting.  I'm running 10.8.4 on one of the retina MBPs with an old-school cinema display attached, and I'm not seeing the performance issue, even when vigorously scrubbing the mouse around -- it's snappy.

I don't have easy access to an older mac mini at the moment, but I can find someone that does.  Can you give me the pertinent details from About This Mac > System Config so that I can direct them to the right hardware?

Colin, any chance you're running the content debugger?

[Colin Holgate]

Yes, I'm using the current 11.8 beta, debug version. How are you judging the performance difference? I don't even load any images, I just click on the different blank picture frames. When the browser window is bigger the performance gets much worse. When the window is small, the zooming and panning is super smooth.

Here's a significant thing, the performance remains good using Chrome if I let it use the 11.7 player. If I disable that and enable the 11.8 player, then the performance problems happen in Chrome, like it does in Safari.

So, it could be an FP 11.8 issue.

[jeromiec83223024]

You're definitely going to take a large performance hit with the debugger version.  If you compare performance between the 11.7 and 11.8 release versions, I'm pretty sure you'll see similar behavior.

[Colin Holgate]

The non-debug version of 11.8.94 (the new one from yesterday) shows the same performance issues as the debug version does.

Mal, could it be worth posting the link here: https://www.facebook.com/groups/stage3d/?bookmark_t=group ? The Flare3D folk may have some ideas.

[jeromiec83223024]

Can you give me info on which machine you have (i.e. Retina 15", Early 2013) so I can ask someone check it out on comparable hardware?

[Colin Holgate]

I’m using the more recent 13 inch Retina MacBook Pro, and I see the lower frame rate with either the internal LCD screen, or with a connected 27 inch monitor. In either case 11.7 performs well. 2.9 GHz, i7, 8GB RAM Intel HD Graphics 4000 1024 MB.

[jeromiec83223024]

Thanks.  I sent the thread out to the whole QE team to get some more eyes on it.

[simplezeroec]

nable to reproduce this with Macbook Air which is 13 inch and Intel HD Graphics 3000 384 MB and 15 inch Retina MBP which is Intel HD Graphics 4000 512 MB with 11.8.800.94 build.

[Mal_CanDo]

I get the issue on Mac Mini, 2.5GHz i5, 4Gb memory, AMD Radeon HD 6630M 256Mb, OS/X 10.8.4

At 1920x1080 on Safari windowed, it's smooth ( even taking up the max space, with title bar ).  If I go full-screen, then it goes slow.

Taking the resolution down...

At 1400x1050 on Safari windowed, it's smooth, on full-screen it's smooth ( for those seeing a slowdown, maybe try changing to a lower resolution temporarily )

I would have thought that running full-screen ( ie no drawing the sytem menu bar etc, and only having that bars width of extra pixels to render ) would have been faster, but am def seeing major slowdown at 1920x1080 ( pixel res for the monitor ).

[Mal_CanDo]

Hi Colin, was going to post that I posted at that link earlier ( thx for the link ), but I see you already posted there earlier

[jeromiec83223024]

This has been bugging me, so I checked it out on some older personal machines, and I'm able to reprouce it.  I see a pretty severe amount of dropped frames in both full-screen and embedded mode using the release player in Firefox and Safari.  The problem seems to get worse at higher resolutions. 

I see a more subtle version of the problem in Chrome.  I'm seeing the performance problems both in Flash Player 11.7 and 11.8 (I don't use this machine much, so it was behind on patches which was kind of convenient). 

I played around with this a little in Scout, and I consistently see a big spike in onEnterFrame() is called when I click the right-left buttons in the UI, and when I zoom in and out from the image.  I'd be interested in taking a deeper look to see what's going on. Scout would give us a lot of detail about what's happenging with the GPU, but the SWF needs to be compiled with the -advanced-telemetry flag to enable the additional details.  At that point, it should be pretty clear as to what's eating up all the cycles, and we can directly compare across versions to see if there is a regression in the player.

If you'd rather take a look for yourself, Scout is included with Creative Cloud, and you can pick up a free trial if you don't have CC membership: https://creative.adobe.com/products/scout

[Colin Holgate]

I think what you're seeing is something different. You're having to go to an old machine to see problems, and then see them in 11.7 too. I'm using a fast modern machine and only see the problem in 11.8.

One interesting thing is that I can set the window to be over 2500 wide, or over 1200 tall, and still get good performance, so long as it's narrow in the other direction. If I set the window to a more normal ration, like 1600x1000, then I get the frame drops.

I will need to reinstall the debug version of Flash Player to be able to look at what Scout sees.

[Colin Holgate]

Ok, here's my Scout file:

http://xfiles.funnygarbage.com/~colinholgate/files/ImageSearch3D.flm

This is a short session where I had the window quite large and saw the low frame rate, then I resized the height of the window, and things became smooth. You can see the size I used in the Regions view.

The most interesting part is that the time taken for ActionScript is a lot longer when the window is bigger. It's typically in the 50 mS range, but sometimes goes over 100 mS. When the window is shorter the AS time goes down to around 20 mS.

So, something about the screen area is causing ActionScript to take longer, which goes back to what I was suggesting about how the 3D hardware isn't being used correctly. Note too how high the CPU usage is. If I use Activity Monitor to see how much is used, it's in proportion to the area of the window. With a small window it's still over 100% CPU, but with a large window it goes over 300% CPU.

Mal, you're constantly fading the wall color, how is that done? How is performance if you don't do that?

[Colin Holgate]

Ok, problem solved! And solved by reading Jeromie's next forum post, which was about microphone inputs. At some earlier stage I had been following that thread, and had tried the advice given (not that I was having problems, but just in following the topic). The advice given was to turn off Use Hardware Acceleration, and so I happened to be using hardware under 11.7, and not using hardware under 11.8. Turning hardware back on gives good frame rates at all sizes, and CPU usage came down from >300% to <25%.

[jeromiec83223024]

Thanks.  I probably should have asked.  Because you were seeing more contention as the size of the display increased, I figured we had to be doing more per-pixel operations in CPU.  I was concerned that we might have accidentally blacklisted a driver or something, but I didn't remember seeing a change go by that would have done that, either.

Anyway, this thread has gotten a little convoluted so let me just summarize where we are:

• On older hardware, when you zoom into the photos and pan left or right using the buttons, you can clearly see a lot of dropped frames, even with hardware acceleration enabled.
• Performance is fine if you stay zoomed out and pan around.  You can whip the camera around and you won't see dropped frames.
• When I look at the SWF using Scout, I see a really long EnterFrame() loop every time I click the arrow, and a lot of activity right as I change to/from fullscreen.

My guess is that there's something CPU-intensive happening in ActionScript.  I'd normally blame traversing the DisplayList for this kind of thing, but it's Stage3D content and it's compiled without the -advanced-telemetry flag, so I'm unable to get ActionScript-level detail.

My recommendation to Mal is to download Scout and take a look first-hand for hot spots in the code.  I'm pretty sure it will be obvious once you have the full debugging info enabled in the SWF.  Scout is free for Creative Cloud subscribers, and is available with the trial if you haven't upgraded or don't want to at this point.

[Colin Holgate]

It’s amazing in a way that with just CPU I could still get good enough performance at moderate sizes.

[Mal_CanDo]

I've recompiled with Telemetry enabled, and have a few different versions...

1) Normal one

http://www.cando3d.com/art

2) This has the code for the wall change disabled

http://www.cando3d.com/art/no_wall_change/

( Colin, we were just changing the colour value of a shader every frame, based on 3 separate bouncing RGB values )

3) Fullscreen, not full-screen interactive, mode - and also wall change disabled

http://www.cando3d.com/art/no_fullscreen_interactive

Jeromie wrote...

• On older hardware, when you zoom into the photos and pan left or right using the buttons, you can clearly see a lot of dropped frames, even with hardware acceleration enabled.

If you have images loaded, the code when moving between images will auto show either a thumbnail or the original high-res image.  This would be the cause of some dropped frames, but this is separate from the overall slow-down issue that we're seeing.  We get it even if no images are loaded, and if you just look around from the middle of the room.

• Performance is fine if you stay zoomed out and pan around.  You can whip the camera around and you won't see dropped frames.

As above, we're seeing a drop in performance if we stay zoomed out and pan around, in full-screne mode.  In windowed mode, it is very smooth / great performance.

• When I look at the SWF using Scout, I see a really long EnterFrame() loop every time I click the arrow, and a lot of activity right as I change to/from fullscreen.

For the toggle to / from full-screen, the code is pretty straightforward - see below...

private function _onMouseEventClick ( event:MouseEvent ):void

  {

   try

   {

    if ( _this.stage.displayState == StageDisplayState.NORMAL )

    {

     if ( bFullScreenInteractive )

     {

      _this.stage.displayState = StageDisplayState.FULL_SCREEN_INTERACTIVE;

     }

     else

     {

      _this.stage.displayState = StageDisplayState.FULL_SCREEN;

     }

     iconFullScreen.visible = false;

     iconFullScreenRestore.visible = true;

    }

    else

    {

     _this.stage.displayState = StageDisplayState.NORMAL;   

     iconFullScreen.visible = true;

     iconFullScreenRestore.visible = false;

    }

   }

   catch ( e:Error ) { };

  }

}

Hopefully the new links with Telemetry enabled will help narrow down the problem, which is of full-screen mode being a LOT less smooth than windowed mode, even when windowed mode is stretched to be practically the same size as full-screen mode.

[jeromiec83223024]

Thanks for the detail. 

Just to verify, please confirm that you have Use Hardware Acceleration checked in the Flash Settings, and that you're using the Release player and not the Content Debugger when evaluating performance.

[Mal_CanDo]

Hi Jeromie,

> Just to verify, please confirm that you have Use Hardware Acceleration checked in the Flash Settings, and that you're using the Release

> player and not the Content Debugger when evaluating performance.

The debug is only on my Windows development machine - the Mac Mini I test on in the office uses just the release version of the Flash plugin, and is the one that is showing the speed issues between windowed and full-screen mode.  Hardware Acceleration is def checked.

I've uploaded a new version of the app to http://www.cando3d.com/art

The changes are...

- Auto spin after 15 seconds from the center of the room camera.  This helps to show the diffence as you toggle full-screen / windowed.

- .antiAlias set to 2 ( down from 4 )