Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Blank view in android with open gl(AsyncTask)

 
Jeet Dholakia
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
am using Open GL ES 2.0 to perform certain effects on bitmaps, now if i load a bitmap directly on UI thread it takes alot of time, hence im using AsyncTask....

Problem:-

When i use AsyncTask,all i get is a blank/black texture screen,without asynctask it display the bitmap after 7-8 seconds depending on the size.

Following is the code:-




I've tried refactoring here and there,but without any success...any help is appreciated,thanks!
 
Steve Luke
Bartender
Posts: 4181
22
IntelliJ IDE Java Python
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If we assume your AsyncTask actually works, then I don't understand how this line of code would save you any time: Bitmap bitmap=new BitmapWorkerTask().execute(myuri).get();. It is called from the loadTextures() method which appears to be run the the UI thread. The .get() method would force the UI thread to wait until the task is complete, so there would be no reason to run it in an AsyncTask.

Assuming that you have been modifying your code and the code you posted isn't the version that actually saves you time, and assuming that the AsyncTask works, then I think the issue is making sure the results of the BitmapWorkerTask are pushed into the UI thread when they are done. You would do this by using the AsyncTask's onPostExecute() method, which is run on the UI thread and has access to the results of the doInBackground() method. So here is an example, where I modify the loadTexture() method to take the result Bitmap in as a parameter, and use the onPostExecute() method to make sure that the loadTexture() method is called only after the Bitmap is loaded...

So the onPostExecute() method triggers the loadTexture() method, signals that the loading is done, and then makes sure the effects are rendered. I modified a couple of the other methods to make sure that things happen only when the bitmap is available. First, the onDrawFrame() method is modified to only work after the bitmap is loaded completely (the mInitialized variable is true). I also broke the rest of what was in the onDrawFrame() method out into its own method so it could be called either from onDrawFrame() of from the onPostExecute() methods:

Finally, I wanted to kick the BitmapWorkerTask off as soon as possible, so I figured I would run it from the onCreate() method:


So in this situation, the onCreate() method starts loading the BitmapWorkerTask. When the BitmapWorkerTask is done, it makes sure the bitmap is sized and processed, and rendered. Meamwhile, if the onDrawFrame() is called before the bitmap is complete, it won't do anything, afterwards, it will display the results. all this is relatively naive, of course. I haven't used OpenGL on the Android yet and I didn't compile or test the code. all I did was to organize it in a way that made sure the code that needed to execute only after the Bitmap was loaded did so, and to make sure that that code gets called as soon as the Bitmap is loaded.

This will NOT make the bitmap load faster. If it takes 7 seconds to load the bitmap that is how long it takes, and it still shouldn't show up until the end of that load time. What this will do is allow your UI remain responsive and allow other things to happen WHILE the bitmap loads.
 
Jeet Dholakia
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you so much for such a detailed reply, the solution you posted is pretty good and a cleaner approach, indeed i had a confusion making sure my bitmap worker returned the result to the ui thread

Although I'm still a bit confused, if a new thread is assigned to upload a bitmap,shouldn't it theoretically be faster than UI thread?

Thanks again!

Regards,

Jeet
 
Steve Luke
Bartender
Posts: 4181
22
IntelliJ IDE Java Python
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jeet Dholakia wrote:Thank you so much for such a detailed reply, the solution you posted is pretty good and a cleaner approach, indeed i had a confusion making sure my bitmap worker returned the result to the ui thread

I am glad I could help.
Although I'm still a bit confused, if a new thread is assigned to upload a bitmap,shouldn't it theoretically be faster than UI thread?

No, this is a common misconception with threads (not just in Android, but in Java and programming in general). A task takes as long as it takes, using Threads doesn't make it faster unless the task can be broken down into smaller pieces and done in parallel without interfering with each other - but that is actually not very common, and almost never the case with disk read/writes, network connections, or heavy CPU use. In fact over-using threads can actually make a task run slower: every thread competes for CPU time and it actually takes time to switch contexts from one thread to the next. So if you have too many thread context switches you could be spending a measurable amount of time moving between the threads instead of doing work.

What threads do is make tasks more responsive and makes unrelated tasks occur at the same time: you can do the disk writing in one thread and the network communication in another thread. This would mean the network comms don't have to wait for the disk writes to complete or vice-versa. The network communications take the same amount of time before or after threads, but maybe there is less wasted time where a message is waiting to be consumed but the app is busy writing to a disk.

So when you push a long-running task out of the UI thread and into a background thread you aren't making that task happen any quicker. What you are doing is allowing the User Interface thread to move on, allowing the user to interact with the application, and allowing other updates to the UI to occur while that process happens. It makes the application more responsive, which makes things appear faster to the user. Not doing so could 'hang' the UI while the process runs, and the user would think that the app is frozen or crashed.
 
Jeet Dholakia
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Apologies for not being prompt,but once again your description is to-the-point, thanks for the "threading 101 in android"!!!
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic