summaryrefslogtreecommitdiffstats
path: root/services/jni/com_android_server_input_InputManagerService.cpp
diff options
context:
space:
mode:
authorfun <forfun414@gmail.com>2013-03-01 23:06:43 +0800
committerRicardo Cerqueira <cyanogenmod@cerqueira.org>2013-09-17 16:22:41 +0100
commit1311a90e4adf82702e3eef17f20a487e1f14deb6 (patch)
treed83e098c8ebf78e6c52a4dda559884e793d19702 /services/jni/com_android_server_input_InputManagerService.cpp
parentd8574e9aa82071f85b751e1f7dccd19759ffc7a9 (diff)
downloadframeworks_base-1311a90e4adf82702e3eef17f20a487e1f14deb6.zip
frameworks_base-1311a90e4adf82702e3eef17f20a487e1f14deb6.tar.gz
frameworks_base-1311a90e4adf82702e3eef17f20a487e1f14deb6.tar.bz2
Rework thumbnail handling
Since ids of media file are usually not continuous, the original file of thumbnail are sparse. When there are big numbers files on ex\ ternal storage, the size of this file will be horrible. Ex, when the id is 20000, then the .thumbnails/.thumbdata3-xx file will be 50000*10k = 488.28M. Can refer http://stackoverflow.com/questions/12396715/android-huge-thumbdata4-file-in-dcim-folder Because after 4.0, MediaProvider will scan any files, this will be a big problem. So I modify MiniThumbFile.java to avoid this. According to the id, we now produce an index file. In this index file, one id will use BYTES_PER_MINTHUMB_INDEX(8) bytes in offset (i\ d+1)*BYTES_PER_MINTHUMB_INDEX. The data of these 8 bytes is the index of thumbnail file. The first BYTES_PER_MINTHUMB_INDEX bytes kee\ p next available index. And when you need insert a thumbnail, the index increase by 1. In this way, the block data in thumbnail file \ will be continuous. And thus unnecessary zero paddings will not be saved. Change-Id: I66005dd69b0a5c8f4353bd7a8225d163a654fd2d
Diffstat (limited to 'services/jni/com_android_server_input_InputManagerService.cpp')
0 files changed, 0 insertions, 0 deletions