Initalizing Texture2D from a background thread => lock #515

Closed
WaaghMan opened this Issue Jun 12, 2012 · 9 comments

Comments

Projects
None yet
6 participants
@WaaghMan
Contributor

WaaghMan commented Jun 12, 2012

When loading a Texture2D from a thread (via ContentManager.Load<>), that thread gets locked.

I've checked a bit the internals and it looks like Threading.BlockOnUIThread() is called, resulting in the action added to a pending action list (so the UI thread can perform them later), but this never happens ( Threading.Run() is not even called once in MonoGame? )

@dellis1972

This comment has been minimized.

Show comment
Hide comment
@dellis1972

dellis1972 Jun 12, 2012

Contributor

Which operating system is this on?

Contributor

dellis1972 commented Jun 12, 2012

Which operating system is this on?

@WaaghMan

This comment has been minimized.

Show comment
Hide comment
@WaaghMan

WaaghMan Jun 12, 2012

Contributor

Sorry, Windows 7 64bits. A "find all references" to Threading.Run() doesn't show any call to the method, and it looks like the only place where those pending actions could be performed.

Contributor

WaaghMan commented Jun 12, 2012

Sorry, Windows 7 64bits. A "find all references" to Threading.Run() doesn't show any call to the method, and it looks like the only place where those pending actions could be performed.

@KonajuGames

This comment has been minimized.

Show comment
Hide comment
@KonajuGames

KonajuGames Jun 13, 2012

Contributor

Are you running this on Windows? Which version of MonoGame are you using?
The Threading support is my area, and I have yet to fully implement it on
Windows. It should use a shared GL context similar to iOS (which doesn't
need the call to Threading.Run).

Sly

On 13 June 2012 01:38, WaaghMan <
reply@reply.github.com

wrote:

When loading a Texture2D from a thread (via ContentManager.Load<>), that
thread gets locked.

I've checked a bit the internals and it looks like
Threading.BlockOnUIThread() is called, resulting in the action added to a
pending action list (so the UI thread can perform them later), but this
never happens ( Threading.Run() is not even called once in MonoGame? )


Reply to this email directly or view it on GitHub:
#515

Contributor

KonajuGames commented Jun 13, 2012

Are you running this on Windows? Which version of MonoGame are you using?
The Threading support is my area, and I have yet to fully implement it on
Windows. It should use a shared GL context similar to iOS (which doesn't
need the call to Threading.Run).

Sly

On 13 June 2012 01:38, WaaghMan <
reply@reply.github.com

wrote:

When loading a Texture2D from a thread (via ContentManager.Load<>), that
thread gets locked.

I've checked a bit the internals and it looks like
Threading.BlockOnUIThread() is called, resulting in the action added to a
pending action list (so the UI thread can perform them later), but this
never happens ( Threading.Run() is not even called once in MonoGame? )


Reply to this email directly or view it on GitHub:
#515

@WaaghMan

This comment has been minimized.

Show comment
Hide comment
@WaaghMan

WaaghMan Jun 13, 2012

Contributor

Yes, on Windows. I'm using the develop3d branch of a week ago approx.

Debugging step by step, the new Texture2D does a BlockOnUIThread call, which checks if the current thread is the UI thread (it isn't), and then adds the action to the pending action list. since Run() is never called, the action is never performed.

I'll redownload the branch later today, just in case it's already been fixed.

Contributor

WaaghMan commented Jun 13, 2012

Yes, on Windows. I'm using the develop3d branch of a week ago approx.

Debugging step by step, the new Texture2D does a BlockOnUIThread call, which checks if the current thread is the UI thread (it isn't), and then adds the action to the pending action list. since Run() is never called, the action is never performed.

I'll redownload the branch later today, just in case it's already been fixed.

@KonajuGames

This comment has been minimized.

Show comment
Hide comment
@KonajuGames

KonajuGames Jun 13, 2012

Contributor

Hasn't been fixed yet. Keep an eye on the pull requests and you'll see
when the fix goes in.

Sly

On 13 June 2012 17:50, WaaghMan <
reply@reply.github.com

wrote:

Yes, on Windows. I'm using the develop3d branch of a week ago approx.

Debugging step by step, the new Texture2D does a BlockOnUIThread call,
which checks if the current thread is the UI thread (it isn't), and then
adds the action to the pending action list. since Run() is never called,
the action is never performed.

I'll redownload the branch later today, just in case it's already been
fixed.


Reply to this email directly or view it on GitHub:
#515 (comment)

Contributor

KonajuGames commented Jun 13, 2012

Hasn't been fixed yet. Keep an eye on the pull requests and you'll see
when the fix goes in.

Sly

On 13 June 2012 17:50, WaaghMan <
reply@reply.github.com

wrote:

Yes, on Windows. I'm using the develop3d branch of a week ago approx.

Debugging step by step, the new Texture2D does a BlockOnUIThread call,
which checks if the current thread is the UI thread (it isn't), and then
adds the action to the pending action list. since Run() is never called,
the action is never performed.

I'll redownload the branch later today, just in case it's already been
fixed.


Reply to this email directly or view it on GitHub:
#515 (comment)

@totallyevil

This comment has been minimized.

Show comment
Hide comment
@totallyevil

totallyevil Jun 19, 2012

Contributor

I may have seen something similar to this in our game port to XNA with MG3. Now and then I see the UI lockup when swiping through our help screens or other screens with some graphics as buttons. I don't have specifics, but I know it always happens on one of our screens - as in every time I visit it, the screen locks up and I have to back out of the app and restart it. Hmm. It might just be similar to this bug report.

I also had to wrap my sound calls in ThreadProcs to get away from locking on the UI (did the same on the Android Java version too).

Contributor

totallyevil commented Jun 19, 2012

I may have seen something similar to this in our game port to XNA with MG3. Now and then I see the UI lockup when swiping through our help screens or other screens with some graphics as buttons. I don't have specifics, but I know it always happens on one of our screens - as in every time I visit it, the screen locks up and I have to back out of the app and restart it. Hmm. It might just be similar to this bug report.

I also had to wrap my sound calls in ThreadProcs to get away from locking on the UI (did the same on the Android Java version too).

@Chaosus

This comment has been minimized.

Show comment
Hide comment
@Chaosus

Chaosus Feb 11, 2015

Contributor

@tomspilman I guess he tried initialize OpenGL content in separate thread. Of course it fails. Does this issue is neccessary or should be closed ?

Contributor

Chaosus commented Feb 11, 2015

@tomspilman I guess he tried initialize OpenGL content in separate thread. Of course it fails. Does this issue is neccessary or should be closed ?

@tomspilman

This comment has been minimized.

Show comment
Hide comment
@tomspilman

tomspilman Feb 11, 2015

Member

I think this is fixed/hacked to work on OpenGL with the resource creation being done on the main thread under the hood.

Member

tomspilman commented Feb 11, 2015

I think this is fixed/hacked to work on OpenGL with the resource creation being done on the main thread under the hood.

@tomspilman

This comment has been minimized.

Show comment
Hide comment
@tomspilman

tomspilman Mar 16, 2016

Member

This is fixed for OpenGL and DirectX.

Member

tomspilman commented Mar 16, 2016

This is fixed for OpenGL and DirectX.

@tomspilman tomspilman closed this Mar 16, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment