search

Gamua / Starling-Framework

The Cross Platform Game Engine
http://www.starling-framework.org
Other
2.85k stars 819 forks source link

Purging buffer causes #3672 issue #869

Closed shanemccartney closed 8 years ago

shanemccartney commented 8 years ago

With Starling this error is being reported in our error logging software.

starling.rendering::Effect.purgeBuffers():-1

It seems that the disposing of a VertexBuffer causes for this which I suppose should be allowed to happen as the error is internal to Stage 3D, I am wondering have you considered putting a try catch around this and maybe having a system in place to reattempt this as maybe its just at this particular time the vertex buffer can't be disposed but later it can. At the very least I suggest a try catch block to prevent reporting on this issue as I don't think it results in a crash or a negative experience for the player.

PrimaryFeather commented 8 years ago

Mhm, looking at the code, if vertexBuffer.dispose() may cause such an error, only a try/catch will help.

But before I do this — could you maybe try to add that change temporarily to one of your next updates, and see if it helps? My fear is that even if we've got a try/catch around this specific dispose(), the error will simply pop up a few lines further down the source code. If that's the case, the change would be useless. (Obviously, I can't try/catch all context related stuff.)

Would that be possible?

shanemccartney commented 8 years ago

Yup definitely get in touch with me and we'll include the updated Starling source in the next update.

I know this is an AIR bug but I feel there's a chance you can handle this. As I mentioned maybe the error is only an issue at that time to dispose VertexBufferData and if you were to dispose at another time the issue would not happen.

Not to worry we don't get too many reports on this issue but it's one we would like to fix or handle as its been a bug with the AIR runtime for quite a long time now.

Since we added the try catch our selves we of course don't get the exception reported anymore and have not noticed any increase in crashes from this. So we've already done this. We added a try catch around both the vertex and a seperate one for the index buffer.

PrimaryFeather commented 8 years ago

Since we added the try catch our selves we of course don't get the exception reported anymore and have not noticed any increase in crashes from this. So we've already done this. We added a try catch around both the vertex and a seperate one for the index buffer.

Perfect, that's just the information I needed! :smile: In that case, I agree: that code can't do any harm, and it should help overall stability.

shanemccartney commented 8 years ago

So will you be storing these cases when the dispose fails on Vertex and Index buffers then reattempt the dispose at a later time ?

PrimaryFeather commented 8 years ago

No, I don't think that's necessary. If the dispose failed due to an "internal error", I don't think we should access that object again; we don't know if it failed prior or after releasing any resources, and accessing it after it has been disposed (even for another dispose call) is probably not a good idea.

Since this is a quite rare issue, I'd rather just ignore the error and look another way. :wink: