Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411423 Posts in 69363 Topics- by 58416 Members - Latest Member: JamesAGreen

April 18, 2024, 07:40:45 PM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsDeveloperTechnical (Moderator: ThemsAllTook)Android - game thread wait for GLThread to finish drawing
Pages: [1]
Print
Author Topic: Android - game thread wait for GLThread to finish drawing  (Read 1828 times)
ndnninja15
Level 1
*


I make games


View Profile
« on: October 23, 2016, 12:41:15 PM »

I'm developing a game with OpenGL ES on Android and have a separate logic thread from the thread created from setting a renderer (Android calls it GLThread, and it lives inside GLSurfaceView). The renderer thread is responsible for executing the glDraw calls via OnDrawFrame() and I'm wondering how do I communicate between the threads to let the logic thread know that the GLThread has finished drawing?

The renderMode is set to render when dirty and I make a call to draw via requestRender() but I do NOT want to request render if the GLThread is in the middle of drawing the last frame.

How can I tell when the render thread inside GLSurfaceView has finished drawing?
Logged
agedev
Level 0
**


View Profile
« Reply #1 on: October 23, 2016, 02:46:08 PM »

Probably the simplest way would simply be to use a synchronisation object. Create an Object called lock.

For your requestRender() call you want to wait on the lock so
synchronized(lock) { requestRender(); }

And in your onDrawFrame()
synchronized(lock) { draw stuff here; }

Basically you want your logic thread to get a lock only when not drawing (i.e. drawing will have finished).

This is rather coarse grained though. You have essentially treated your two threads as a single thread. I am not sure what your use case is, so I can't say if it even makes sense to use render when dirty. It does if you don't have animations and are turn-based; in that case the only draws are going to be after the user initiated something that causes a change.

Most other cases you don't use render when dirty, just let it constantly redraw. Then you actually do one of two things. You either do everything in the GLThread, so you have an update() and a draw() in onDrawFrame. This has the advantage in that is eliminates all thread management except for when you deal with input (e.g. touches), or networking. It is also quite common since most folks would rather work on their game than resolve threading bugs (especially ones that are fatal but only show extremely rarely).

Or you have fine grained locks when you do updates to the renderable aspects. E.g. (drastically simplified) my engine relies on requests the logic (or other) thread pushes to a thread safe queue for the GLthread. In this way neither thread blocks the other (except very briefly, during queue changes). Or you can simply lock down as close as possible to shared data (e.g. the position of an object can only be modified or read when locked) This is more common in heavily engineered code since it requires threading experience (or a LOT of patience; bugs can be very detached from their causes).
« Last Edit: October 23, 2016, 02:55:07 PM by agedev » Logged
ndnninja15
Level 1
*


I make games


View Profile
« Reply #2 on: October 23, 2016, 03:18:36 PM »

I'm trying to accomplish double buffering, so I would want my game thread to continue while the GLThread is drawing. Therefore, I'm not so sure the sync object is the right way to go.

EDIT: Found an article from Replica Island where he is using one thread for game logic and the GLThread specifically for rendering. I'll probably look through the source code to see how he does it.

Here's the link
« Last Edit: October 23, 2016, 05:59:15 PM by ndnninja15 » Logged
Pages: [1]
Print
Jump to:  

Theme orange-lt created by panic