GLSL fill-rate

127 views
Skip to first unread message

Bram Stolk

unread,
Jan 24, 2014, 6:29:55 PM1/24/14
to emscripte...@googlegroups.com
Hi,


So I use a GLSL v1 shader with GLES2 and SDL.
I'm happy to report that in a small window mode, I actually hit 60fps in the emscripted JavaScript.
That's awesome!

Now, if I switch to full screen, my fps drops to 30.
Normally, this is not that strange: more pixels, means that the GPU fill-rate can't keep up.

But weirdly enough, the native version (c++) of my game can do 60 regardless of window size.
Even though I use exactly the same vertex and fragment shaders in both the native and emscripted version.

How could it be that the webgl version struggles with fill-rate, but the native version is just fine?
It does not really make sense to me.

Does the webgl version need to read back the entire frame-buffer to bring it back into the browser or something?

Is a full screen mode by a browser different from a native full screen?

Thanks,

 Bram

Alon Zakai

unread,
Jan 24, 2014, 6:46:30 PM1/24/14
to emscripte...@googlegroups.com
There are big differences in browsers here, which browser and version did you test in? Is there a url we could test as well?

- Alon



--
You received this message because you are subscribed to the Google Groups "emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-disc...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Bram Stolk

unread,
Jan 24, 2014, 6:52:37 PM1/24/14
to emscripte...@googlegroups.com
Thx,


I use firefox 26 on Ubuntu.
(I use AMS.JS so I think I can only use firefox?)

I will try to put it up on a server, as soon as I figure out how to compress my js and data files, they are far too large at the moment, and I understand that lzma is deprecated, and server side compression is preferred.
I know very little about web servers, so have to investigate.
(16M js and 24M data. Ugh... )

Bram



--
You received this message because you are subscribed to a topic in the Google Groups "emscripten-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/emscripten-discuss/wbaoVGg6eOo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to emscripten-disc...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.



--

“Programming today is a race between software engineers striving to build bigger and better idiot- proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.” (R Cook).

Alon Zakai

unread,
Jan 24, 2014, 7:00:07 PM1/24/14
to emscripte...@googlegroups.com
asm.js works very well on chrome too, and it should run in all other browsers as well, it is nothing more than (specifically structured) standardized JavaScript. Always worth trying stuff in multiple browsers in my experience, often one has a bug or slowness and it becomes clearer in comparison to the others.

Regarding firefox, you may want to enable hardware acceleration in about:config (layers.acceleraton.force-enabled), that might make a difference.

- Alon

Bram Stolk

unread,
Jan 24, 2014, 7:11:57 PM1/24/14
to emscripte...@googlegroups.com
It's HW accelerated all right.
The config change with Firefox did not change anything.

My game works with Firefox 26.

With Ubuntu Chrome 32.0.1700.77 or Ubuntu Chromium 31.0.1650.63 I get:


XMLHttpRequest cannot load file:///home/bram/apps/LittleCrane/JS/bin/tlctc.data. Cross origin requests are only supported for HTTP. tlctc.html:1
Uncaught NetworkError: A network error occurred. tlctc.js:46

Jukka Jylänki

unread,
Jan 24, 2014, 8:51:17 PM1/24/14
to emscripte...@googlegroups.com
You need to have a web server to run the file in Chrome - running from a local directory does not work. Try emrun ( https://github.com/kripken/emscripten/wiki/Running-html-files-with-emrun ) or "python -m SimpleHTTPServer" to host an ad hoc web server to run the file in.

As for the fillrate requirements, it is possible that a browser requires additional fullscreen compositing passes over the native build, which causes the extra overhead. Or some other performance issue. Try making the canvas pixel size the same in fullscreen to the one with windowed mode to see if that has an effect, and then conversely make the canvas full page width in windowed mode without fullscreen. That should rule out if there's anything wrong with the fullscreen mode transition/support itself.

   Jukka


2014/1/25 Bram Stolk <b.s...@gmail.com>

Bram Stolk

unread,
Jan 24, 2014, 9:37:01 PM1/24/14
to emscripte...@googlegroups.com


On Friday, January 24, 2014 5:51:17 PM UTC-8, jj wrote:
You need to have a web server to run the file in Chrome - running from a local directory does not work. Try emrun ( https://github.com/kripken/emscripten/wiki/Running-html-files-with-emrun ) or "python -m SimpleHTTPServer" to host an ad hoc web server to run the file in.


Thanks, the python command works well.

But it turned out that by default, WebGL is disabled on linux/chrome for Intel graphics.
With chrome://flags I could override the Render list.

It turns out that even though Chrome's FPS is a bit better in full screen, every now and then the browser freezes for a second or so.
I guess that is the reason why they disabled WebGL.


As for the fillrate requirements, it is possible that a browser requires additional fullscreen compositing passes over the native build, which causes the extra overhead. Or some other performance issue. Try making the canvas pixel size the same in fullscreen to the one with windowed mode to see if that has an effect, and then conversely make the canvas full page width in windowed mode without fullscreen. That should rule out if there's anything wrong with the fullscreen mode transition/support itself.
 
Good idea.
When running a large windowed instance, the slow down is just as much as the full screen option.

  Bram

 
   Jukka


pem....@gmail.com

unread,
Sep 22, 2015, 1:37:11 AM9/22/15
to emscripten-discuss
This thread helped me.  I haven't done a lot of web stuff, so it took me a while to discover that I needed to use emrun for the file system (FS) stuff to work.  Since I'm using cmake, I added --preload-file and --emrun to my CMakeLists.txt linker step:

set(CMAKE_EXE_LINKER_FLAGS_RELEASE "-s USE_SDL=2 -o ${PROJECT_NAME}.html --preload-file ${CMAKE_CURRENT_BINARY_DIR}/@/ --emrun")

But if you just open the HTML file directly then it gives you an error:

XMLHttpRequest cannot load file:///H:/code/build-emscripten/pemDemos.data. Cross origin requests are only supported for protocol schemes: http, data, chrome, chrome-extension, https, chrome-extension-resource.

I guess the reason for this error is that the FS (file system) stuff requires a web server.  But if I instead run (emrun --browser chrome pemDemos.html) then my simple OpenGL ES 2.0 demo works.  The (--emrun) is a nifty bonus to print stdout to my console (eg Windows cmd.exe).  cheers for the mailing list - I found this by searching the mailing list for "cross origin" :-)

I'm curious to understand exactly why emrun is necessary...  Or if there's away to change my "browser CORS rules" such that I can just open the html file directly in the web browser instead of needing to use emrun...

Next I'm curious whether this will work (without effort) (so anyone can try my demo on my website from their web browser) when I upload the files (hello.html, hello.js, hello.data, hello.js.mem) to my web server via FTP...  Of if there is more work I need to do for that to work properly?

Robert Goulet

unread,
Sep 23, 2015, 9:07:19 AM9/23/15
to emscripten-discuss
Browsers don't allow to read files from the file system directly, without enabling some options, for security reasons.

Personally I don't use emrun. I just open a terminal and run python -m SimpleHTTPServer in the .html folder, and then I point my browser to http://127.0.0.1:8000.

Note that, by default, the python simple http server will use port 8000. You can change that with options.
Reply all
Reply to author
Forward
0 new messages