I'm having a very strange issue with a project I'm working on. When I try to display a duplicate of an already working image, the framerate drops horribly. I've tried making a second contructor for the alternate image, duplicating the image and displaying the duplicate, etc.. No matter what i do, the issue still persists. Here's the project. The line of code that keeps breaking the framerate is inside of "Game", and is the following:
a2.display();
If you remove that line, the framerate goes back to normal.
The function loadImage() should be called inside the class constructor or the setup function. The function is slow and only needs to be called once at the beginning of the game, to load an image from disk. In fact, this is the reason why games have load screens when starting up a level, because they are loading all images and assets from disk, and that takes time.
Specifically: move img = loadImage("PurpleSpaceship.png"); out of the display() function and into the Ship(int x, int y, int w, int h) function instead.
On the topic of optimization, you could have a single variable which holds the image, outside of the class, that is loaded only once even with many ships. But then, instances of you class would be sharing that data. Sharing can lead to bugs and confusion, as your program gets bigger and more complex. Or generally speaking, optimizing code tends to reduce its stability and create problems, so, it's good to seek compromise and to find "just enough" optimization.
Related
I’m working on a complex project in threejs.
Trying to cut the corner:
I have to load an obj, create some pivot point to use as parent of the mesh inside this obj, let the user move and rotate the pivots.
It takes somewhere about 10 to 15 seconds to load due to its complexity.
My problem is that it is working flawlessly if I load the page and don’t change the focus, but if I change the browser tab or collapse the browser window I got a very specific problem:
geometry.computeBoundingBox() gives different results.
Is there someone who can help me figure out what’s happening?
To help you better understand the situation: at loading time I have to rotate the obj to -90° on the X axis (inverting Y and Z as a consequence); I think it’s relevant because the boundingBox calculation somehow inverts Y and Z and changes its min and max also, but as I said only if I switch tab or collapse the browser.
p.s. No matter the OS nor the browser. It’s a super consistent bug
Ok, I somehow solved the issue, but take it with a grain of salt:
the problem can be tracked back to the execution stack of javascript:
the first function computes the bounding box, the second uses this computation, but if the first function is somehow slower to execute, the second could not have what it needs.
What I did is to force javascript to execute functions in a given order and only when the previous is finished.
The problem occurred only when changing the tab because browsers optimize resources of non visible tabs, but the code I wrote was anyway too much entropic to work properly.
I hope what I found will be understandable and useful to someone else in future.
I'm making a silverlight website which includes paint-like features including freedraw. To achieve this I used the technique described on the following website: http://codeding.com/articles/freehand-drawing-in-silverlight .
The problem is, when I run the demo project it will start to lag extremely after just a few seconds of drawing. I realise that that is probably caused by the amount of shapes this techniue requires, however, and this is my main question:
How on earth does the demo on the website not lag nomatter howmuch I draw, while my local project which should have the EXACT same code lags right away?
I tried finding something about improving canvas performance overall, but the only thing I found was turning the drawing into a static image, which is not really ideal since I use undo/redo functionality.
The number of shapes added to the Canvas shouldn't be the reason for the lagging, there must be something else like converting the drawing into image for undo/redo functionality. For undo/redo, you can save the strokes-information instead of images. Creating & storing images during each undo/redo operation will consume too much memory.
A stroke is nothing but a set of points from the start (mousedown event) to end (mouseup event), and a set of strokes forms a complete drawing. You can always recreate the drawing using the saved strokes-information (just like you can recreate using images). You can use simple data-structures like List<List<Point>> to store a complete drawing, this is very memory efficient instead of creating & storing the image itself.
I’m building a mobile web application, and even though I’m still in a prototyping kind of the process, I’m having a hard time fixing certain performance problems.
The application itself (works all smooth in desktop browsers, but significantly sluggish in Mobile Safari): Hancards webapp prototype. You may login as mifeng:wangwang or create a new user.
The overall clumsy performance could be tolerable though, except for one thing: the browser simply crashes (!) when you open a set page, tap ‘view’ (enlarge all cards) and then try to go back to the previous page.
The code that gets executed when ‘view’ is tapped is this (very sluggish by itself as well; any way to improve it?):
if ($(this).hasClass('big')) {
$('.card').unwrap().removeClass('big flippable').addClass('small');
$(this).removeClass('big');
}
else {
$('.card').wrap('<div class="bigCardWrap" />').removeClass('small').addClass('big flippable');
$(this).addClass('big');
}
And another thing, a pretty weird bug. Very often the ‘word of the day‘ block won’t display the text node for the last element (<div class="meaning">), even though it’s in the code. The text will not show unless you ‘shake’ the DOM anyhow (unticking and ticking back one of the associated CSS properties can also achieve that). This happens in both desktop and mobile Safari browsers.
The code that writes it in there is this:
// While we are here, also display the Word of the day
$.post('ajax.php', {action: 'stuff:showWotd'}, function(data) {
// Decode the received data
var msg = decodeResponse(data);
// Insert the values
$('.wotd .hanzi').text(msg.content[0]['hanzi']);
$('.wotd .pinyin').text(msg.content[0]['pinyin']);
$('.wotd .meaning').text(msg.content[0]['meaning']);
});
I don’t expect you to advice me on how to fix the performance of the whole application (I will probably have to revise the overall scope of the project instead of trying to find workarounds), but I at least would like to see how to solve these two problems. Thank you!
The only performance issue I see in the script is the wrap/unwrap calls - adding and removing elements from the DOM tends to be fairly slow, and you can probably get the same effect by always having a wrapper element and changing its class rather than adding or removing it.
However, the performance issues you are seeing are most likely in your css:
3D transforms can be much faster than 2D due to hardware acceleration. It looks like you already have this, though you do need to be careful about which elements it is applied to
Shadows have real performance issues, especially when animated. Removing them will probably fix most of the slowness.
Rearranging background images can help - A single background image under transparent pages is faster than having a background image for each page.
First of all, I know that displays lists were deprecated in OpenGL 3.0 and removed on 3.1. But I still have to use them on this university project for which OpenGL 2.1 is being used.
Every article or tutorial I read on display lists use them on some kind of object that is drawn multiple times, for instance, trees. Is there anything wrong in creating one list for a single object?
For instance, I have an object (in .obj format) for a building. This specific building is only drawn once. For basic performance analysis I have the current frames per second on the window title bar.
Doing it like this:
glmDraw(objBuilding.model, GLM_SMOOTH | GLM_TEXTURE);
I get around 260 FPS. If you don't about the GLM library, the glmDraw function basically makes a bunch of glVertex calls.
But doing it like this:
glNewList(gameDisplayLists.building, GL_COMPILE);
glmDraw(objBuilding.model, GLM_SMOOTH | GLM_TEXTURE);
glEndList();
glCallList(gameDisplayLists.building);
I get around 420 FPS. Of course, the screen refresh rate doesn't refresh that fast but like I said, it's just a simple and basic way to measure performance.
It looks much better to me.
I'm also using display lists for when I have some type of object that I repeat many times, like defense towers. Again, is there anything wrong doing this for a single object or can I keep doing this?
Using display lists for this stuff is perfectly fine and before Vertex Arrays were around they were the de-facto standard to place geometry in fast memory. Put display lists have a few interesting pitfalls. For example in OpenGL-1.0 there were no texture objects; instead placing the glTexImage call in a display list was the way to emulate this. And this behaviour still prevails, so binding a texture and calling glTexImage in a display list will effectively re-initialize the texture object with what's been done in the display list compilation, whenever the display list is called. On the other hand display lists don't work with vertex arrays.
TL;DR: If your geometry is static, you don't expect to transistion to OpenGL-3 core anytime and it gives you a huge performance increase (like it did for you), then just use them!
Interesting problem here - I'm making a small game using Flex 3 - now I have a static ImageAccess class, which first loads up all images and stores them in a static array for quicker access in the future.
Now since I address the physical bitmapdata without calling Clone() (for efficiency issues) and once by accident I've written directly onto the bitmapdata.
Now the weird part - Flex uses some kind of weird caching and stores the bitmap with the new changes made to it - no matter what I do (restart Flex Builder, delete my cache, restart browser) the bitmap data is still loaded with the extra info (even though the image is without all that data).
Please help :D
Can you give more details about what extra info you're talking about?
Correct me if I'm wrong but Flex doesn't cache anything as such, the browser does, in any case , viewing with another browser should display the original image. If it doesn't , you may consider the possibility of some forgotten function still acting on the original bitmap... have you tried viewing the application in another browser by the way?
there's also the possibility of the original image being corrupted for whatever reason...