PDA

View Full Version : Low fps even on empty canvas.



sphere
12-11-2009, 08:16 AM
Hi!

I create an empty 1680?1050px canvas with gl.clear only. It shows ~30 fps in Chrome on E8400@3000Ghz & 8800 GTS.
Where I am wrong?

Here is the code:


<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<title>webgl test</title>
</head>
<body>
<canvas id="canvas" width="1680" height="1050"></canvas>
<div id="log">log here</div>
</body>
<script type="text/javascript">
var log = document.getElementById('log');

var canvas = document.getElementById('canvas');

var gl;
try
{
if(!gl)
gl = canvas.getContext('moz-webgl');
}
catch(e){ }

try
{
if(!gl)
gl = canvas.getContext('webkit-3d');
}
catch (e) { }

if(!gl)
alert('no webgl');

gl.clearColor(0.2, 0.2, 0.2, 1.0);
gl.clearDepth(1.0);

var fps = 0;
function render()
{
gl.clear(gl.COLOR_BUFFER_BIT | gl.DEPTH_BUFFER_BIT);
gl.flush();

fps++;
}

function getFps()
{
log.innerHTML = fps;
fps = 0;
}

window.setInterval(render, 10);
window.setInterval(getFps, 1000);
</script>
</html>

Coolcat
12-11-2009, 10:18 AM
Maybe this does happen because you are calling flush() explicitly? You don't need to call this.

sphere
12-11-2009, 10:24 AM
Same result without flush().
I`ve tested it on 2 different configs -- slow on both.

gero3
12-13-2009, 08:26 AM
nope seems like minefield has the same problem

I guess the framerate won't stay in the high 60's when you go over 700px x 700px canvas so try using a smaller canvas or use it with that framerate

Coolcat
12-13-2009, 03:07 PM
This reminds me to something:
I'm not 100% sure, but this might have something to do with scaling of the canvas element. It's possible that the scaling is done using software, not hardware. However, I had similar problems when I applied width 100% and height 100% to the canvas using CSS. Then I read the element size using JavaScript and set width and height attributes of the canvas element to that size. For some reason Minefield showed scrollbars and was incredible slow. I'm not sure, but I think an CSS-style "overflow:hidden;" solved the problem.

sphere
12-14-2009, 11:09 AM
2Coolcat: I`ve tried several canvas size definitions with the same result. It`s really looks like software processing.
Did you fix it? How many fps do you have now?

Coolcat
12-15-2009, 10:27 AM
Did you fix it?
Yes, but I don't know how ;)
It might also have something to do with restarting Minefield.


How many fps do you have now?
I'm rendering a full scene (*) at 72 fps.


(*) my current project: UltimateConquest
http://www-users.rwth-aachen.de/martin. ... quest.html (http://www-users.rwth-aachen.de/martin.weusten/develop/uc/uc091214/UltimateConquest.html)
http://www.youtube.com/watch?v=JDTiq3RWfTc

sphere
12-17-2009, 01:22 PM
I thought, an empty canvas or scene like this should show a thousands fps :|

Coolcat
12-17-2009, 02:01 PM
I thought, an empty canvas or scene like this should show a thousands fps :|
No, not necessarily. I don't think that WebGL does support such high framerates.

sphere
12-18-2009, 06:53 AM
No, not necessarily. I don't think that WebGL does support such high framerates.
Maybe, but I can't believe that 30(70) fps and ~100% cpu loading in empty scene is normal for hardware rendering. I think it's some kind of gaps in early implementation.

Coolcat
12-18-2009, 07:11 AM
My scene is not empty... :wink: Also I didn't say anything about the CPU load. However, when running UltimateConquest the CPU load is at about 60%, using only one of four available cores.

sphere
12-18-2009, 07:48 AM
I talk about my own tests. I`ve tested an empty scene on several configs with the same result: tooo low fps, high cpu load.
UltimateConquest consists of several balls. I don't want to minish it, but it's not the big deal for 8800GTS. Crysis show more fps on my pc, and I think, it's not a problem of UltimateConquest.
So, my conclusion is simple: WebGL needs a __full__ hardware support.

aho
12-26-2009, 04:31 PM
http://khronos.org/webgl/wiki/Getting_Started

"Tight integration with HTML content, including layered compositing, interaction with other HTML elements[...]"

This is the problem. It behaves like Flash with wmode=transparent by default. Which is nice. But this is also very slow and in many cases it's also completely pointless.

We really need some kind of switch to bypass all those extra steps completely. Something which makes it behave like an opaque overlay. LWJGL (http://lwjgl.org/) applets are like that for example. The framerate is almost completely unaffected by running it in a browser.

Coolcat
12-27-2009, 02:32 AM
You can disable alpha when creating the context. According to spec (https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/WebGL-spec.html) you can pass a WebGLContextAttributes object to the getContext() method. However, I didn't try it yet.

aho
12-27-2009, 03:09 AM
You can disable alpha when creating the context. According to spec (https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/WebGL-spec.html) you can pass a WebGLContextAttributes object to the getContext() method. However, I didn't try it yet.

Not implemented anywhere yet. But even if you disable it, you'd still get that copying around etc, because the browser is still compositing around. (I.e. you can put other HTML elements on top of it - and they will be visible.)

My suggestion is to use something like compositing=transparent|opaque|overlay instead of alpha=true|false.

Transparent would be like alpha=true, opaque would be like alpha=false, and overlay would mean it's just rendered on top. Flash handles it exactly this way for example. Flash uses "window" instead of "overlay" though, but "overlay" is a bit clearer, I think.

Or buffer=transparent|opaque|overlay. I really don't care how it's called. But this option should be there. Layered compositing is very slow and generally not required.

aho
12-27-2009, 03:31 AM
The forum software just decided to throw my edit away. Great.

"Very slow" = ~27fps with older Chromium builds, ~85fps with a very recent one. While taking 100% CPU for drawing an empty 800x600 window.

Without compositing the CPU usage would be below 1% at this framerate.

If we want full screen gaming and good performance (=lower energy consumption) on mobile devices, we really need a way to bypass the compositing completely.

giles
12-29-2009, 02:11 PM
This definitely sounds like a good topic for the public WebGL mailing list, where the details of the spec are being hammered out: https://www.khronos.org/webgl/public-mailing-list/

spoob
01-02-2010, 08:07 AM
I have been encouraged to post so that this issue receives more attention. At the moment, I'm drawing a simple 30x30 textured sphere full screen, and Flash is much faster than the 8fps speed that I'm getting. What I'm doing is a very common operation for displaying 360 degree panoramas, and this is definitely a minimum base standard that WebGL needs to be able to handle.

This is apparently due to browser compositing, with glReadPixels being used to transfer from pbuffers to display, so that HTML objects can be laid over the top of WebGL views. I have absolutely no need for this, and I do really very much need to have full screen full speed displays with the full power of OpenGL ES 2.0 being applied to compensate for Javascript slowness.

Would it be possible to have a wmode=window or other setting that will effectively say "thanks browser, I'll look after this bit of the screen", so that the mighty hardware powers can be unleashed onto that area of visual splendour? I feel this is a matter of life or death for WebGL!

giles
01-04-2010, 04:15 AM
Just to echo what people are saying on the mailing list; that does sound very slow. I've hacked up my last lesson (which draws a sphere with 30 lats and 30 longs and textures it) to scale it up to 1200 by 1000, and it seems absolutely fine -- JS's timing function is reporting less than a millisecond for a repaint, and while that seems a bit dubious, by eye it looks perfectly smooth so I must be getting order of 60fps. This is on a pretty low-end office-spec PC with an ATI 2400, running Minefield under Vista. Perhaps, as you were thinking on the list, it might just be the OS/browser combo you're using right now has specific problems in that area.

aho
01-04-2010, 04:56 AM
The problem is that you're utilizing 100% CPU for drawing that at merely ~60 FPS. Without that copy/compositing overhead you'd be at ~1% (at that framerate).

For example if the canvas is big enough to limit your empty scene to 60fps... and then you add some game logic which would limit the framerate to 60 if there were no copy/compositing overhead... then your effective framerate is halved.

Doesn't sound that bad with 60/30, but what about 30/15 or 20/10?

If you do heavy math which would limit it to 30 fps, you'd also get only about 20fps instead of 30.

1000/30=33.333 ~33msec for math
1000/60=16.666 ~17msec for drawing overhead

33+17=50msec for everything

1000/50=20fps (without actually drawing anything)

I'd rather use those resources which are wasted on copying/compositing on something else. Like drawing, logic, or reducing energy consumption.

It's an option in Flash for a reason. Compositing defaults to off there by the way.

sphere
01-09-2010, 04:05 AM
aho
Thank you for detailed response!

Toji
08-11-2010, 06:56 AM
Just wanted to add another observation: I've found that using setInterval in my rendering code seems to slow it down artificially. For example: If I use a setInterval with a delay of 10 I should theoretically be limited to 100FPS, but on my projects I'll typically only get 45 - 50. If I change up the event that triggers a draw, though (like using Vladimir's postMessage hack (http://people.mozilla.com/~vladimir/misc/ctest3d.html)) I can get much higher framerates.

Using that method for my Quake 3 (http://media.tojicode.com/q3bsp/) demo, which is rendered at 854x480, I can typically get ~120FPS in Chrome 6, which isn't too shabby for a fully rendered scene like that!

I don't know that this method is appropriate for all WebGL uses, but it seems to at least get you get a better idea of your maximum potential frame rate.

Cork
09-10-2010, 02:28 AM
It's a shame WebGL is dragging it's heals a bit on this issue.

"Tight integration with HTML content, including layered compositing, interaction with other HTML elements[...]"

This isn't what 3D content needs at all. What we need is a full screen hardware accelerated canvas, otherwise the battle is lost before it begins.

jenni75
01-21-2011, 12:39 PM
The forum software just decided to throw my edit away. Great.

"Very slow" = ~27fps with older Chromium builds, ~85fps with a very recent one. While taking 100% CPU for drawing an empty 800x600 window.

Without compositing the CPU usage would be below 1% at this framerate.

If we want full screen gaming and good performance (=lower energy consumption) on mobile devices, we really need a way to bypass the compositing completely.

I agree. hopefully they will address this and add a flag for bypassing the compositing.

SteveBaker
01-22-2011, 07:21 AM
It's a shame WebGL is dragging it's heals a bit on this issue.

"Tight integration with HTML content, including layered compositing, interaction with other HTML elements[...]"

This isn't what 3D content needs at all. What we need is a full screen hardware accelerated canvas, otherwise the battle is lost before it begins.

I disagree. Having actually produced a full 3D game using this technology rather than just talking about it in the abstract (see http://tubagames.net), I know that using HTML5 for menus and such like is extremely useful.

The issue is certainly with compositing - and the difficulty is that right now, not all browsers are using OpenGL or Direct3D for compositing - and that's an obvious issue at higher screen resolutions. However, it's getting fixed - albeit sporadically. Some browsers on some hardware and under some OS's have it (and I get 30Hz frame rates for a pretty complex scene) - and others don't (and I get a miserable 8 to 10Hz - even on pretty good hardware).

It's getting better.

While full-screen has its' uses - I doubt that more than a small percentage of 3D content (note that content!=games in many cases) will want to use it.

The market these days is in casual games - and casual gamers don't want full-screen - they want to be able to tweet their buddies, surf the net, play the game...and occasionally do the work that their bosses are paying them to do...all at the same time.

zed
01-23-2011, 04:37 PM
Ive gotta agree with Steve here.
Whilst I agree framerate is pretty poor ATM (it will improve though(*)), being able to integrate html stuff with webgl stuff is a point of difference with standard 3dapi implementations eg opengl native apps, otherwise youre better of writing a native app

Personally though I could live without the html5 integration. But I wouldnt like to see it removed

(*)If youre using chrome make sure youre doing
--enable-accelerated-compositing

zed
01-25-2011, 12:28 PM
Also I believe once webgl is mainstream (next month perhaps) things will get faster very quick

ATM(*) the last time I checked chrome renders webgl over twice the speed of firefox, now when websites start benchmarking webgl applications and browser X is performing terrible, the makers are gonna be so embarrassed with the benchmark results they'll do something about it.
Look at javascript performance over the last ~year.
chrome comes out + is 10x faster than the others, forcing all the other browsers to up their gameplay, I predict exactly the same senerio with webGL, web sites love benchmarks.
This will be a new arms race

(*) well chromium doesnt run webgl at all for me ATM so has a FPS of zero :lol:

SteveBaker
01-25-2011, 05:32 PM
The problem with benchmarking right now is that the performance depends rather drastically on the application.

* If your application is CPU-bound then JavaScript performance will be the determining factor.
* If you render at high resolution then the efficiency of the compositor system becomes paramount.
* If you make a ton of GL calls - then the efficiency of the WebGL implementation itself becomes critical.
* If your platform choice requires that the system use Direct3D to emulate OpenGLES - then you're going through ANGLE - and the performance of that layer becomes critical - and comparing it to a browser that can use OpenGL when available is exceedingly problematic.
* If one implementation offers some extension that the other doesn't - then even if it's worse at all of the previous things - it may turn out to be faster running your application simply because the extension offers a more efficient way to do something in your niche situation.
* ...and no matter what, different GPU and CPU hardware choices will alter the balance between those things - so even if you pick a "fair" benchmark to run, the results may vary widely between users.

Characterizing the performance of graphics systems is an exceedingly tricky matter.

The problem will be that (in all likelyhood) each browser will lay claim to being fastest in one or other of those areas and thereby demand the title "Fastest WebGL"...and with some justification for that subset of applications that uses it!

einSelbst
01-26-2011, 01:13 AM
This is an interesting blogpost on this topic. It is mentioned, why the framerate in firefox is limited.
http://hacks.mozilla.org/2010/08/more-e ... tionframe/ (http://hacks.mozilla.org/2010/08/more-efficient-javascript-animations-with-mozrequestanimationframe/)

Also, here is a site which seems to test the max number of available frames (just a guess). I dont know why this was just open in my browser right now and how I got there, but I might be of interest. BTW it slows down the browser A LOT.

http://people.mozilla.com/~vladimir/misc/ctest3d.html

Also again, this is probably the way to send optional attributes to the context request:

var ctx = WebGLUtils.setupWebGL(canvas,
{alpha : true ,
antialias : false ,
depth : true ,
stencil : false ,
premultipliedAlpha: false }));

I'm not really at the point where I have tested them but I read somewhere that the antialias is working in some os/browser combination, so maybe the others do too.

Have a nice day.

SteveBaker
01-26-2011, 08:03 PM
I've only seen the antialias setting work in Chrome under Windows - it doesn't work under Firefox because of the way the image is composited. Chrome doesn't do it under Linux - presumably because they didn't implement an OpenGL path for it yet...which probably means it won't work on MacOS either.

zed
01-27-2011, 01:00 PM
Ive never seen AA work at all (either browser win/linux) but Im not really too fussed ATM this will eventually come.
On a related note I'ld like to see better AF, looking at whats onscreen looks like 1xAF


The problem with benchmarking right now is that the performance depends rather drastically on the application.true there are a few more factors to worry about, but its always been thus eg PC games are CPU/GPU limited (fillrate,shader speed etc bottlenecked). My point is once webgl goes mainstream we will see websites benchmarking Application X/Y with browser A vs browser B vs browser C (even internet explorer might join the party :lol: ). This will drive the browser makers to drastically improve their overall performances. Honestly I expect within a year for performance to be 10x better than it is now

SteveBaker
01-27-2011, 05:05 PM
The benchmarking problem for WebGL is even worse than for PC games though - we have to factor in the performance of the JavaScript engine and also the WebGL/ANGLE layers and performance of the compositing engine. That's at least three more variables than we'd have to judge for Direct3D or OpenGL implementations alone.

AF? Anisotropic filtering? I don't think that's supported in OpenGLES without an extension - so it's not in WebGL right now.

zed
01-28-2011, 03:29 PM
cheers Steve yes Anisotropic filtering, Im doing a platformer ATM, thus all those glancing? (whats the word) platforms/walls look crap without AF.
ATM as the OP saiz 'Low fps even on empty canvas.' atm it seems the compositing is the main bottleneck

einSelbst
01-28-2011, 04:16 PM
Maybe the --enable-accelerated-compositing flag could help in chrome?

https://sites.google.com/a/chromium.org ... -in-chrome (https://sites.google.com/a/chromium.org/dev/developers/design-documents/gpu-accelerated-compositing-in-chrome)

aloha

SteveBaker
01-29-2011, 11:33 AM
cheers Steve yes Anisotropic filtering, Im doing a platformer ATM, thus all those glancing? (whats the word) platforms/walls look crap without AF.
ATM as the OP saiz 'Low fps even on empty canvas.' atm it seems the compositing is the main bottleneck

The compositing issue is gradually getting fixed - the developers know it's a problem...but it's not such a simple thing to change.

When you know the orientation of the surface to the camera (as is often the case in a platformer where the camera doesn't roll or pitch much) - you can change the texture to make that glancing angle problem much less. The reason there is a problem is because the hardware for MIPmapping has to pick the worst case texture 'compression' and prevent that from aliassing - so (for example) on a wall where the U direction of the texture runs along the length of the wall and the V direction is vertical - the most common problem is when the U axis is compressed and the V isn't...the reverse is almost never the case for "normal" camera angles - right? So if you make the texture much bigger in the V direction than in the U (so instead of having...say...a 128x128 map, you go with a 128x512) - then when the U-direction compression drops the MIPmap level to (say) the third MIP map then instead of sampling a 16x16 map, it'll be sampling a 16x64 - which will be much less blurry in the vertical direction.

Simply increasing the resolution of the map in BOTH directions won't help - if you had (say) a 512x512 map being viewed under similar circumstances, then the U-direction compression would still result in a 32x32 map being viewed. Ironically, a 128x512 map actually looks better than a 512x512 map under these circumstances!

That's so strongly counter-intuitive that you'll want to do the experiment to convince yourself that it works.

Only when the "shape" of the map (the width-to-height ratio) is a good match for the worst case viewing angle do you avoid this problem. In effect, you are pre-filtering your map and thereby avoiding the hardware filtering it for you!

Of course in the case of floor and ceiling textures, unless you are in a long thin corridor, you don't know whether it'll be the U or the V direction that is compressed - so you can't get this trick to work. However, you could consider making two different textures - one compressed in the U direction and the other compressed in V and switching between them depending on whether the camera is pointing north-south or east-west.

This technique leads to a more general solution called "RIPmapping" (rectangular MIPmapping) - but to do that properly requires hardware support - and these days, true anisotropic filtering is preferred. However, in constrained circumstances - and without that hardware support - this trick definitely helps!