I've put together a fairly barebones example with Three.js - http://jsfiddle.net/4kehk2xv/7/ not very exciting but simple. If GPGPU works a square of randomly placed red coloured points should show, otherwise they'll all be positioned at the origin. The devices I'm testing on (Nexus 5 and iPad3) support the OES_texture_float extension and have MAX_VERTEX_TEXTURE_IMAGE_UNITS greater than 0. They don't support (as most mobile GPUs appear not to) the OES_texture_float_linear extension, but we should be able to get around that by using NEAREST filtering.
The error I'm coming across is below, Three.js also reports that OES_texture_float_linear isn't supported but this appears to be a check in the WebGLRenderer and not to do with the code I'm running.
[.WebGLRenderingContext]GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : glDrawElements: framebuffer incomplete (check)
Related
I'm building a creative simulation in p5.js by employing double pendula. Here is the link to the stripped-down version of the code (I'm not sure it can be made smaller):
https://github.com/amzon-ex/amzon-ex.github.io/tree/master/dp-sketch-stripped
Here is where you can see the animation: https://amzon-ex.github.io/dp-sketch-stripped/dp-sketch.html
When I run this on my laptop (Windows 10, MS Edge 88) I get about 55-60 fps, which is what I want. However, when I run the same sketch on a mobile device (Android, Chrome 88) the performance is very poor and I hardly get 5-6 fps. I do not understand what is complicated about my code that contributes to such a poor performance. I have ran other kinds of p5.js sketches before on mobile and they've worked well.
Any insight is appreciated.
Since I have a few files in the project link I provided, here's a quick guide (there is absolutely no need to read everything):
sketch.js is the key file, which builds the animation. It takes an image, builds an array filled with brightness values from the image (array lumamap, in setup()). Then I draw trails for my pendula where the brightness of the trail at any pixel corresponds to the brightness value in lumamap.
dp-sketch.html is the HTML container for the p5 sketch.
libs/classydp.js houses the DoublePendulum class which describes a double pendulum object.
As I've found out with some help, the issue is tied to varying pixel density on different devices. As mobile devices have higher pixel density compared to desktops/laptops, my 500x500 canvas becomes much bigger on those displays, hence leading to many more pixels to render. Coupled with the fact that mobile processors are weaker in comparison to desktop processors, the lag/low framerate is expected.
This can be avoided by setting pixelDensity(1) in setup(); which avoids rendering larger canvases on dense-pixel devices.
I use Pixi.js for my work project to draw simple shapes — circles and segments, and make some interaction between them. I work on Mac running El Capitan and test my prototype in Google Chrome. I use PIXI.autoDetectRenderer() method to set renderer and usually it is set to WebGL in latest browsers. I don't have any experience in WebGL, so might not know some important details.
When testing my application in Firefox I've noticed thin black border around shapes.
Turned out that antialias property set to true caused this effect:
renderer = new PIXI.autoDetectRenderer(width, height, {backgroundColor: 0xffffff, antialias: true})
I've done some investigation. On Pixi.js forums and on some other resources it's said that PIXI.Graphics() objects do not support anti-aliasing because of using the stencil buffer. On practice they do support anti-aliasing. Guess, something has changed since discussions took place.
I don't like the result I get with switched off anti-aliasing, here it is on images below.
I and my colleague had a talk about that, and we discovered that when any other graphic object lays behind, there is no black border around original one. So we added white rectangle behind other elements in case Firefox browser is used.
That solved problem of black border. Still I get far neater image in Google Chrome. There are lots of artifacts around segments and circles in Firefox.
They become more visible once elements get smaller.
In console I get following warning:
FXAA antialiasing being used instead of native antialiasing.
Is there a way to improve anti-aliasing quality in this case?
I am trying to render as much triangles as possible in webgl. Everything works pretty well with all webbrowser except with chrome. After 57000 triangles I get a blank canevas. So I check the chrome task manager and I saw that the GPU takes 2 700 000ko before this blank screen. Is it possible that the problem come from this ? Here the code : http://gogotriangl.orionhub.org:8000/triangles/ch04-05_BlueTriangles.html
You are creating too many buffers. Get the webGL inspector, and running your app for a few seconds and I see you already created over 1.6k glBuffers:
But when you are drawing, you are only using the most recent:
Either re-use the glBuffers with gl.BufferSubData or delete the previous glBuffers via gl.deleteBuffer.
I'm working on a project where workers have to locate components on a plane. Planes are going to be scanned and put on a web app where, after that, user select where are placed.
My first idea was img map (where I work, computers still have IE, we are trying to change to Firefox or Chrome) but I'm not sure how make an area visible for user (some kind of dynamic overlay coloured area), so my second suggestion was to use a HTML 5 canvas.
Is better to work with an img map and find some solution to overlay points at least or work with canvas?
Note: where I work, they have to change to non-Windows OS, and use Firefox-based browser or Chromium, so the browser have not be seen as part of the problem.
Yes, I'd suggest to use a canvas to do that.
Quoting from https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Canvas_tutorial:
<canvas> is an HTML element which can be used to draw graphics using
scripting (usually JavaScript). It can, for instance, be used to draw
graphs, make photo compositions or do simple (and not so simple)
animations. The image on the right shows some examples of <canvas>
implementations which we will see later in this tutorial.
<canvas> was first introduced by Apple for the Mac OS X Dashboard and
later implemented in Safari and Google Chrome. Gecko 1.8-based
browsers, such as Firefox 1.5, also support this element. The <canvas>
element is part of the WhatWG Web applications 1.0 specification also
known as HTML5.
This tutorial describes how to use the <canvas> element to draw 2D
graphics, starting with the basics. The examples provided should give
you some clear ideas what you can do with canvas and will provide code
snippets that may get you started in building your own content. Before
you start
Using the element isn't very difficult but you do need a
basic understanding of HTML and JavaScript. The <canvas> element isn't
supported in some older browsers, but is supported in recent versions
of all major browsers.The default size of the canvas is 300px * 150px
(width * height). But custom sizes can be defined using CSS height and
width property. In order to draw graphics on the canvas we use a
javascript context object, which creates graphics on the fly.
I am using globalCompositeOperation = 'copy' then a drawImage so that my new image replaces what is underneath.
This works fine in the latest Safari and Chrome browsers on Mac and Windows and also on the iPad.
It doesn't work in IE 9 and while it works in Firefox 3.6, it doesn't work in Firefox 4.0.
What seems to happen when it isn't working is the whole canvas gets erased, not just the area in the rect I pass to drawImage.
I think this is a bug in IE 9 and firefox 4.0 but should I not expect it to work?
These are the images of what Mozilla is assuming the Canvas is supposed to work:
https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Canvas_tutorial/Compositing#globalCompositeOperation
The problem is that the spec is written rather vaguely here. For example, for the copy composite type, it reads:
Display the source image instead of the destination image.
Which could be taken to be a synonym of source-over, or it could be taken to mean "clear the entire canvas and then copy the new drawing operation onto the canvas"
To see how the different browsers differ in their implementations, use the images provided by mozilla above with this live-firing (not images, canvases) of all the different composite shapes that has also provided by Mozilla:
https://developer.mozilla.org/samples/canvas-tutorial/6_1_canvas_composite.html
Just looking quickly it seems that Chrome 11 disagrees with Firefox 4 on source-in, source-out, destination-in, destination-atop, darker, and copy.
It seems at a glance that the thing to note is that all of the differences are related to whether the non-pertinent pixels should be cleared or not. Mozilla seems to think so, Google does not.
When you use drawImage() with globalCompositeOperation="copy", it's unexpected that the canvas is cleared outside the destination rectangle. But this seems to be the consensus of how to interpret the standard. Even with fillRect() or when drawing a line, the whole canvas is cleared. You have to set a clipping region to prevent that.
For a discussion see: https://bugzilla.mozilla.org/show_bug.cgi?id=366283