Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Updating the UI is Slow #8

Closed
GoogleCodeExporter opened this issue Mar 24, 2015 · 3 comments
Closed

Updating the UI is Slow #8

GoogleCodeExporter opened this issue Mar 24, 2015 · 3 comments

Comments

@GoogleCodeExporter
Copy link

What steps will reproduce the problem?
1. Pick any image as a source
2. Tune the resolution to, say, 500
3. Hit 'Generate Mosaic' and watch it chug along confusedly

The goal is to quickly update the UI so that the user can see progress.  
Currently we are signaling an 
event every time the mosaic is updated.  For large resoltions, this may be too 
often.  Additionally, it 
is probably not wise to do all the work of updating in the AWT Event Thread 
itself.  Instead, our 
listeners that catch these events should probably add to a queue that is 
running in a separate 
thread (pool?).


Original issue reported on code.google.com by csven...@gmail.com on 14 Dec 2007 at 4:45

@GoogleCodeExporter
Copy link
Author

The FlickrServices2 class aggregates all of its results and then adds it to the 
shared buffer for processing.  I 
think this might be slower than letting each query add to the buffer as it 
completes, because we are 
potentially bounded by the slowest query.

Another correct solution is to add to the shared buffer as each Query 
completes.  The articles about Thread 
Pools say to be wary of doing this because it introduces the potential for 
deadlock.  Note that this is not the 
case in this shared buffer scenario, as there is no 'hold and wait' condition.  
We have each thread potentially 
waiting (not holding the lock) for one other thread to finish some simple queue 
operations (which don't 
require any additional locks).

We'll have to do some performance analysis with various combinations of these 
methods, because it isn't clear 
to me how having multiple thread pools and multiple sources (flickr, facebook, 
etc), competing for the shared 
buffer will perform.

Original comment by csven...@gmail.com on 14 Dec 2007 at 5:36

  • Added labels: ****
  • Removed labels: ****

@GoogleCodeExporter
Copy link
Author

Responding to Comment 1:

This is something that we can discuss more at the meeting. However, we are 
already
submitting progress from FlickrService2 as each query completes.  The logic is 
as
follows:

foreach query:
    Start a new thread that will specifically query flickr //non-blocking call

foreach query:
    Submit our query results to the shared buffer // blocking call

The first loop is a very quick iteration just spawning threads, but the second
actually blocks to wait for results from each call.  I believe this is the best 
way
to do it.

Original comment by swegn...@gmail.com on 4 Jan 2008 at 5:30

  • Added labels: ****
  • Removed labels: ****

@GoogleCodeExporter
Copy link
Author

Original comment by csven...@gmail.com on 19 Jan 2008 at 6:03

  • Changed state: Fixed
  • Added labels: ****
  • Removed labels: ****

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

No branches or pull requests

1 participant