Giter Club home page Giter Club logo

Comments (6)

leadedge avatar leadedge commented on August 12, 2024

I hope we can get to the bottom of this, but I don't know enough to say. Is this 32 bit or 64 bit code? Debug or Release? Visual Studio? What version?

Process B - the receiver - only needs to update the receiving buffer if the sender has changed dimensions. Are you checking for sender size change, or is the buffer being re-allocated every frame?

To isolate this, I would modify "spoutCopy::CopyPixels" in both sender and receiver. First, check to find out whether FlipBuffer is being used. If it is, the problem could be in this function. Either way, modify both functions to use standard memcpy. If that works OK, put things back in one at a time. Come back with your findings.

from spout2.

Golem235 avatar Golem235 commented on August 12, 2024

Thanks for your response!

  • 64 bit code
  • Debug
  • VS 2017

I only re-allocate my buffer if necessary i.e. if width or height has changed on the sender side and not every frame.

The buffer is only flipped on the sender side. So spoutCopy::FlipBuffer() is only executed on the sender side.

I used memcpy instead of memcpy_sse2 and I got an access violation like I got before.
I changed it on both sides also inside spoutCopy::FlipBuffer(). Unfortunately this did not change anything either.

from spout2.

leadedge avatar leadedge commented on August 12, 2024

At least that eliminates potential problems with the SSE code. You say it happens "sometimes". Is this when you start the application or after it has been running for a while?

I have had problems before with Windows "Data execution prevention" (DEP). Try turning that off.
System Properties > Advanced > Performance > Settings > Data execution prevention.

Does Process A fault with the Spout demo receiver?

Do the Spout demo programs work together OK?

Can you build the Spout Openframeworks examples and repeat the fault? If it does, strip the code back to the essential Spout functions with no rendering to isolate it.

Can you switch to texture share mode? This mode still uses a mutex.

If you need to reboot, do you mean that the problem occurs again immediately on start of Process A after it has happened once? You should be able to terminate the program with Task Manager without needing to reboot.

from spout2.

Golem235 avatar Golem235 commented on August 12, 2024

You say it happens "sometimes". Is this when you start the application or after it has been running for a while?

It seems that the problem occurs whenever the new image size is larger than the previous one.

First, I initialize my sender with a width and height of 1 as the image dimensions are unknown on program start.
In the first render call, the sender is updated with the correct width and height.
Then the picture is sent and also received - Everything works fine.

If the image is changed by a user input and an image of a different size comes in, the update function is executed again.
Here the SharedMemory is reset. The function interop.memoryshare.UpdateSenderMemorySize (sendername, width, height); does not throw any errors and the values inside the function ​​look plausible to me.
So it seems that the memory sizes are set correctly.

Still, the error looks like it might be caused by no or not enough memory having been allocated after the larger image was set:
I also checked the function void spoutCopy::CopyPixels() and the error occurs when writing the first 16 bytes.
If there were memory allocated and it was only a matter of the memory size being to small, it should not crash right in the beginning, right?

If the new image has a smaller size, everything works fine.
So the problem with the mutex handling might only be a side effect and not the actual problem.

"Data execution prevention" (DEP)

My setting shows "Turn in DEP for essential Windows programs and services only" - is that correct?

Does Process A fault with the Spout demo receiver?

Unfortunately yes. The sender will also run in an access violation.

Do the Spout demo programs work together OK?

Yes, they do. No problem there.

Can you build the Spout Openframeworks examples and repeat the fault?

I have not gotten around to test that yet.

Can you switch to texture share mode?

Unfortunately not. I don't have an OpenGL texture to send. The image data is stored in CPU/host memory only.

from spout2.

leadedge avatar leadedge commented on August 12, 2024

OK I can reproduce this with the Openframeworks example.

I don't know the cause yet. It is isolated to memoryshare mode and it looks like something to do with memory map creation, but it could be something else.

The problem occurs if you initialize the sender to 1x1 at the beginning. Normally you would not initialize the sender until you know the size to set it up with.

Even so, I have found that this is resolved in my example by making the initial size bigger than you would expect the user to select, say, 4k size 3840x2160. Of course don't make it too big or you will consume too much memory.

That should fix it so let me know, and I will investigate further why this is happening.

from spout2.

leadedge avatar leadedge commented on August 12, 2024

I found the problem.

The trouble is that for memoryshare, the receiver creates a handle to the sender's memory map but never releases it until program termination. That means the sender cannot release it either because a handle to it is still open. When the sender goes to resize the memory map, it is never released. So when it is re-created, a handle to the existing map is returned and this will have the original size. So all works fine but only if the first map created is larger than the new size.

This is a long standing bug which you will not notice because the Spout demo sender cannot be re-sized. It can be fixed by opening/closing the sender's memory map when reading which means modifying the all the read functions to include a sender name and including the required code to open/close the map.

I have done this and tested it for the next 2.007 release which I am working on but I don't have time to go backwards and change the existing code.

From what you say, I understand that your application is loading images that the user selects. In that case, a large initial size should do the job.

So I am going to close this one because thanks to your observations and time I have found the cause and have resolved it for the next release. But if you or anybody else needs the revision urgently I can provide the current state of 2.007 via email.

from spout2.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.