Awesomium performance - Strange behavoir

0 favourites
  • 8 posts
From the Asset Store
Firebase: Analytics, Dynamic Links, Remote Config, Performance, Crashlytics on Android, iOS & Web Browser
  • I have run some test on different machines to determine the performance of Awesomium.

    We all know the performence is poor especially in fullscreen, but there is more to it than that.

    I have testet my game on these two machines:

    AMD e300 with integrated GPU and a very slow cpu.

    Intel i5 2500k + GeForce 560ti

    Both machines run the game in fullscreen 1920x1080 with about 12-15 fps and 1280x800 with 35-40 fps!

    Judging from this, it is clear that there is some kind of bug in Awesomium and that is not related to the performance of the CPU or GPU - but rather some kind of software bottleneck.

    Please make your own tests with different resolutions on different machines to confirm this bug.

    I'll write to the Awesomium team about this.

    Cheers!

  • The problem with Awesomium is that there's an indirection in the rendering. Awesomium by default generates a 'pixel buffer' for every rendering frame. An 'image' is then built from this buffer. Then the 'image' is showed on screen. That's overly simplificated but that's pretty much what happens. That really hurts performance. To get an idea in a real world example: If you have a web page rendering. The process runs one time at start to generate the web page frame. If nothing changes, ex.: No animation on page, no button clicked, nothing, there's no need to generate a new frame, no refresh occurs. Then when you move the mouse a refresh happens. In a game, which is highly dynamic most of the time, that process happens every time normally 60 times per second. So you get the idea. Of course that buffer copy can be optimized but it's not always enough. Then again of course there can still be a bug that makes things worse.

  • The problem with Awesomium is that there's an indirection in the rendering. Awesomium by default generates a 'pixel buffer' for every rendering frame. An 'image' is then built from this buffer. Then the 'image' is showed on screen. That's overly simplificated but that's pretty much what happens. That really hurts performance. To get an idea in a real world example: If you have a web page rendering. The process runs one time at start to generate the web page frame. If nothing changes, ex.: No animation on page, no button clicked, nothing, there's no need to generate a new frame, no refresh occurs. Then when you move the mouse a refresh happens. In a game, which is highly dynamic most of the time, that process happens every time normally 60 times per second. So you get the idea. Of course that buffer copy can be optimized but it's not always enough. Then again of course there can still be a bug that makes things worse.

    That doesn't explain why there is no difference between a very slow computer and a fast computer. Same performance with same resolution.

    So while Awesomium maybe rendering slowly - there is clearly some kind of bug or bottleneck besides this.

  • Since Awesomium supports WebGL, C2 games render on the GPU using WebGL.

    Then, due to the architecture of Awesomium, it sends all the pixels of the final rendered game to the CPU. So we just turn it around and send it right back to the GPU to be displayed. So every frame is pointlessly sent to the CPU and back. This makes performance dependent on the CPU<->GPU bridge, which I don't know much about, but is hard to find specs for and can vary widely depending on the system often which unexpected performance results. (In fact, unexpected results in performance testing are pretty much to be expected!)

    We've known about this since we started using Awesomium and have been encouraging them to fix it. Luckily, they've already tweeted that they're working on it, so it should be fixed in the near future. Then Awesomium should render at least as fast as Chrome, or faster.

  • This is good news for me!!!

    One step closer to releasing my game :)

  • Great news !

  • Awesomium guys finished Direct to Window rendering ! :D

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • I'm not sure why but Awesomium is using Canvas2d in Windows 7 with 111. Is anyone else getting this?

    EDIT: 12.1 OK so I found another post that answers this.

    Ashley:

    makedit - Awesomium exports from r106 should force WebGL on all the time regardless of the graphics card. How are you determining that WebGL is disabled on these cards?

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)