For my BlackBerry application, I am using a single thread to retrieve images from the server one at a time. My application has a number of images and it takes too long to load all the images. How can I speed this up?
If these are static images, you can also do something like CSS sprites - stitch them all together into one big image, then in code you display the portion of the large image that corresponds to the original image you want.
The last two arguments to Graphics.drawImage(...) indicate where to start drawing from the original image, and that's how you would select the part you want.
Use multiple threads instead of one. Also, if this is a server that you control, consider pre-sizing the images for the target devices or having the device send its size to the server to generate and cache device specific images.
its too late but sorry for that.
i have used observer pattern for it.
Link:-http://en.wikipedia.org/wiki/Observer_pattern
thankx
#Peter
Threads on a mobile phone is a bad idea. Firstly threading on phones suck! secondly phones can't really handle more then one http connection at a time stuff bombs out.
#Userbb
You can do sneeky things like stream them via a socket connection OR include multiple images in a single http request (creating a connection and http headers have overhead).
and also deff do what #peter suggested about resizing serverside.
Related
I have a search result page that returns around 40 images. I use mongohq to store my images.
Now these image will never change. They will either be removed or left as is.
So my Spring servlet streams the images after reading from mongoHq based on image id
/app/download/{uniqueImageId}
All works good. Except the load timings to stream the images. I feel that these images will remain constant for these unique ids so why not cache them. I can add a filter that applies to my above url type and add a caching header, which i plan to give a really long value like maybe cache the images for a week.
My question is, if i start telling the client's browser to cache all these 40+ images, will it cache all these images?
Aren't there any space restrictions from the client side?
Do you see any better option to handle such scenario?
My question is, if i start telling the client's browser to cache all these 40+ images, will it cache all these images? Aren't there any space restrictions from the client side?
Of course, there are space restriction on the client side (also the storage space of the whole world is limited... uhm, sorry for that...). The user may restrict the caching space, and/or the browser just takes automatically the free space available for caching.
Typically I would expect that the browser cache is always some megabytes (let's say 100+), so often needed images, like icons, transfered in a session will be cached. Whether the image is still in the cache, when the user visits your site three days later, depends on the cache size and the users activity in between. So you never know.
What the client or any intermediate proxies do, is out of your direct control. The only thing you do by setting the caching headers is, to say that it is legal not to refresh this resource for a while. Make sure you understand the HTTP1.1 headers correctly, if you do set the headers in your application.
Do you see any better option to handle such scenario?
The term "better" isn't very exact here. What exactly do you need to optimize?
If you have a lot of requests on the same image set, you can reduce server and database load by putting an edge server, like nginx, in front of your application, which is configured as caching reverse proxy. In this case, your own edge server is interpreting the caching headers. In general, I consider it a good design, if an application has no significant load on serving static resources.
I've been working on this problem for a while now. I'm working on a project where I recieve a stream of images which have been processed by OpenCV on a socket, and I need to display these feeds in MT4J. We are transferring the images inside of a Google Protocol Buffer message. In my current (and naive) approach, I grab images off of the socket and simply set them as a the texture in an overloaded draw method from MTRectangle. While this works, if I attempt to display more than 3 feeds at a time, the frame rate drops to an unacceptable rate (<1 fps), and it takes up ~70-80% of my CPU.
A co-worker managed to use GStreamer/Xuggler to display about 20 videos in MT4J, but was using static files instead of a real-time stream. Because of this, I attempted to find a tool in MT4J or Xuggler which would allow me to convert the images to a video stream on the fly, but everything seems to simply be converting a collection of images on the disk to a stream, or vice-versa, but not in real time.
So at this point I see two possible solutions. First, is there a more efficient way to set/draw textures in MT4J? Secondly, is there some tool that exists/some library in GStreamer or Xuggler which would do the image to video conversion in real time?
MT4J website for people who don't know what it is:
http://www.mt4j.org
Thanks in advance, and let me know if there is any information which I left out.
I want to write an app in java that lets two clients talk via webcam. The way it works is both clients connect to a webcam that takes pictures at a specified frame-rate (20 per second maybe) then reduced the size and resolution, then sends it to the other client via a UDP packet. My question is - should I send every picture in its own Datagram Packet? I've read that they can only hold half a kilobyte at most so should every pic be cut down that much? Or should I have it split up into several Packets?
Are you sure you want to transmit whole images, instead of using an algorithm / codec that transfers only what needs to be updated?
If you choose the second option you can take some ideas from this previous question and a already used and tested library for the purpose. I believe i'd go with VLC java bindings if i had to do it. You should evaluate what is the best codec for your specific purpose (bitrates, quality, etc).
If you nevertheless want to transmit images i'd suggest you break them down into udp datagrams, remember that they should be somehow numbered/tagged so that the client can reconstruct the image as packets come (they won't necessarily come in the same order you send them), also you need to think what the client needs to do when some of the packets fails to arrive (discard the image, request previous packet, etc.).
One last thought, the udp datagram max size might not be the best option as well, your server-client should perhaps implement a algorithm and negotiate the udp frame size depending on the speed of the transmission.
What you should be doing is encoding a video stream. Leave the network layer alone, let it do fragmenting for you.
Also, if you are sending video over UDP, you will likely want to throw in a keyframe every 2 seconds or so.
Do not send each frame as its own image. Use a video compressor.
I would like to design a PvP game uses flash in client and java socket server, but I do need server validates trajectory and if bullets hit target from cheating.
Is there any tutorial or paper provides how to do this ?
To do it you need to have a server-side logic.
Mainly you will use clients just to show gamestates that are sent by server (if you want you can also let your clients show whatever they think is right until a new gamestate is received and synch to it) and to send to the servers just actions that are done (clicks or key presses) while your server should take care of everything else..
clients should be mainly frontends for the world representation..
The general idea for a uncheatable multiplayer game is:
You should only send the keys the user is pressing, the server stores it and after some intervals, it processes the informations and send a snapshot of the current position of all objects in the game.
Maybe if you don't want to waste too much network traffic:
You could save everything's position for 2 seconds, record the last user input (with the input, he may also send his last snapshot id), then send only what differs from the position now and what the user have.
Since you asked for patterns, I am assuming you understand the kind of logic you want to write on server side, but not sure about how to organize your code.
You should look at strategy pattern (http://en.wikipedia.org/wiki/Strategy_pattern) once. Since in this problem based on various locations on the screen, you need to change the way server validates the data, strategy pattern is a good fit for the problem.
#Jack: +1, and you should not actually do physical exercises at server,server just check start point, end point, range and time ect... if they are reasonable!
An Android app I'm writing involves quite a lot of downloading of content (think podcatcher/RSS).
I would like to be able to give the user an indication of how many bytes they've downloaded, so they can make the decision whether they want to use Wifi or not.
To this end, I have found a way of counting the number of bytes read by the app, by wrapping an InputStream in a simple CountingInputStream.
However, this does not take into consideration basic things like packet headers and HTTP headers. More importantly, it does not take into consideration any compression that content may be encoded with.
So, how many bytes did my application download over the network? I'm not so interested in the number of bytes uploaded, but if know how, don't be shy.
I have gone down a fairly low level approach as I am feeding the input stream into an XML PullParser. I will also be needing to do a similar exercise with dumping bytes (images in this case) straight onto the SD Card.
Is this the best approach? What am I missing?
ufff... I think this is pretty transparent to underlying protocol, so you can't count all these bytes used in session or link layer, and operators like to charge even for control bytes which are not in any way visible to end user. Also they count traffic in both directions (your reqest to server takes also some), so - good question is: how to measure needed traffic/money for downloading that picture... ?
This isn't a direct answer, but you could try asking someone who has solved a similar problem before, e.g. a data counter application. I've used NetCounter by Cyril Jaquier (http://www.jaqpot.net/netcounter/), and he claims his software is open source. I couldn't get his download link to work, but there's a contact email address. If you got his source code, you should be able to use the same method as him.
As I know, there are two ways to count data traffic. One is /sys/class/net/{interface}/statistics as mentioned in android app named netCounter, the other is /proc/net/dev which is used in android app named wifi-tether. But I don't know the difference between these two methods nor which is better.
The number of bytes received by a particular app is stored in /proc/uid_stat//tcp_rcv where app_uid is the uid of your app on the particular device.