Hey all,
I've been searching for techniques people use to make transparent controls. The problem with windows mobile is that windows always have the CLIPCHILDREN window style set. So you can't grab the contents of the parent window (in WM_ERASEBKGND for example) because it isn't there.
One technique would be to have the parent pass the handle of the background DC it uses to the child control but that involves having a memory DC around all the time. And if the child control is covering any sibling controls you'd be out of luck as well.
Another solution I've read about is to temporarily hide the child window so the parent window is forced to redraw the parts that would normally be obscured by the control. I personally do not like this approach. (the drawbacks are also discussed on some MS forum, i'm not allowed to post outside links yet, google for "Rounded Buttons : Does any one see any problems with this method" and you will find it)
So, there are ways to achieve what I'm looking for but they are far from optimal. Just wondering what everybody else is doing to achieve this.
The responses in that thread are pretty much spot on (funny to find I know over half the posters in that thread by reputation).
If you want to do this well, you really need to draw your own stuff, making a complete custom UI.
There is no proper way to do this in Windows Mobile (without runtime kernel patching, that is ).
Chainfire said:
The responses in that thread are pretty much spot on (funny to find I know over half the posters in that thread by reputation).
If you want to do this well, you really need to draw your own stuff, making a complete custom UI.
There is no proper way to do this in Windows Mobile (without runtime kernel patching, that is ).
Click to expand...
Click to collapse
What do you mean by "drawing your own stuff"? I am drawing everything myself now in all control i made using AlpheBlend() where needed. But that still doesn't resolve the background issue. Or are you referring to just drawing everything in a single WM_PAINT handler and only having one screen DC?
PegNosePete said:
What do you mean by "drawing your own stuff"? I am drawing everything myself now in all control i made using AlpheBlend() where needed. But that still doesn't resolve the background issue. Or are you referring to just drawing everything in a single WM_PAINT handler and only having one screen DC?
Click to expand...
Click to collapse
Well the method I use in my own new UI's is indeed per form (excluding WinAPI controls like edit boxes and such) draw using only one DC.
The problem is that any 'windowed' control, the parent will not draw to the DC if a 'windowed' control overlaps. Due to CLIPCHILDREN all data drawn to that position is simply lost.
Now, handling WM_PAINT you can get the entire update region, which tells you which parts of your form have to be redrawn. You must use this information, because blitting the entire form is very slow!
In essence, to do this right you well end up faking most of the GDI system, including your own 'fake' child windows, invalidating and revalidating portions, calculating the intersections of your 'fake' invalidated regions of the screen with the update region you get in WM_PAINT and redrawing those parts.
There are several different strategies to go about this, one is to redraw on demand, another one is to use double buffering.
I personally mostly use the double buffering technique, as this easily provides every 'fake' control with a bitmap of it's own region. A child control can then alphablend using the parent's buffer as one of the alphablend sources.
You can of course combine this with keeping state information whether a child, grandchild, etc is using alpha / transparency and this with an algorithm deciding which control needs double buffering or can draw on-demand, which can give both speed and memory use advantages. In a lot of situations you can then suffice with only double buffering the 'top' component (form) and a select number of child components.
Of course two drawbacks of per-control double buffering are speed and memory use. You can eliminate the complete-form double buffer with some smart coding and calculating. This will give you a slight speed and memory advantage. Memory use is high because many of your controls will have a copy of their current state.
This can be as complicated, feature-filled, fast and efficient as you are willing to make it. The better you can design the code the better it will work, but it is not a trivial task. There are many ways to go at this, no one way is definitely better than the other ways. It depends on what your applications does with it's display, how simple you are drawing (are you making a simple white background, or a background based on images for example gradient?), which method is more efficient.
The other method is getting the update region and actually perform redrawing of those invalidated sections (instead of copying from buffer). I can tell you from experience that if you are using image backgrounds and alphablend calls, this will be _much_ slower than double buffering (if done right).
I know all of this probaby makes little sense, I'm not a hero with explaining things ... you really have to figure this out for yourself, I guess.
Other advantages of building your own UI system are that if you do it smartly and buffering, it is very easy to port to directdraw, and possibly even GL. But I must warn you, on far the most devices actually using directdraw for this stuff is not much faster, it is in fact hardly noticable. If you manage to make a GL port, that can especially on older HTC devices (pre-HD2) be much faster.
Hi!
Note:
Sorry this posting got very long. But it will tell you how to configure Android's internal taskkiller which may help getting your hero really speedy again.. Without using any taskkiller.
Here the long story:
I just was curious if already someone tried to play around with Android's internal low-memory task killer.
We all know that Android uses a different way of handling processes. Instead of killing every process after its Activity ended, processes are kept until the system needs more memory. These processes usually should not harm the overall performance and should give speed improvements if you start an Activity again. That's the idea.
But when does Android kill a process? And which process? As far as I understood android keeps a LRU (last recently used) list and starts killing the oldest unneeded process. This way it is much smarter than any of the taskkillers we see in the Market.
Just for curiosity I started to investigate how this mechanism works. Please correct me if you think that I got something wrong:
What I found out:
ActivityManagerService.java tracks the "importance" of processes (is foreground, is running a service, ..) and reflects this importance by setting the "oom_adj" value of the process.
(For info: "oom_adj" is a value of every process under Linux which gives the kernel a hint, which process it can kill in an oom [out of memory] situation. You can see this value on every Linux 2.6 system in the proc directory: /proc/[PID]/oom_adj ). The higher this value is set, the more likely this process gets selected by the kernel's oom killer.)
It seems that on Android the current forefround application gets an oom_adj value of 0 and as soon it's not visible anymore it gets some higher value. I assume the concrete value is dependent by the processes' place in the LRU list.
The out-of-memory killer in the standard Linux kernel only runs in one situation: when the available memory is critical low. However in the Android Linux kernel there is implemented a more fine-grained handling of low memory situations.
I found the kernel source file "lowmemorykiller.c" (located in the kernel source tree under "drivers/misc/"; or look here for GIT source tree: http://tinyurl.com/lowmemkiller).
This module seems to be more configurable than the kernel's standard out-of-memory killer as you can define more than one memory limit, when it should get active and you can tell it which oom_adj values it may kill.
In other words:
You can say "if free memory goes below XXXX then kill some process with oom_adj greater then YYY; if free memory goes even more below than ZZZ then start to kill some processes with oom_adj greater than XYXY. and so on.."
So it's possible to define multiple memory criterias and matching processes which can be killed in these situations. Android seems to group running processes into 6 different categories (comments taken out of "ActivityManagerServer.java"):
Code:
FOREGROUND_APP:
// This is the process running the current foreground app. We'd really
// rather not kill it! Value set in system/rootdir/init.rc on startup.
VISIBLE_APP:
// This is a process only hosting activities that are visible to the
// user, so we'd prefer they don't disappear. Value set in
// system/rootdir/init.rc on startup.
SECONDARY_SERVER:
// This is a process holding a secondary server -- killing it will not
// have much of an impact as far as the user is concerned. Value set in
// system/rootdir/init.rc on startup.
HIDDEN_APP:
// This is a process only hosting activities that are not visible,
// so it can be killed without any disruption. Value set in
// system/rootdir/init.rc on startup.
CONTENT_PROVIDER:
// This is a process with a content provider that does not have any clients
// attached to it. If it did have any clients, its adjustment would be the
// one for the highest-priority of those processes.
EMPTY_APP:
// This is a process without anything currently running in it. Definitely
// the first to go! Value set in system/rootdir/init.rc on startup.
// This value is initalized in the constructor, careful when refering to
// this static variable externally.
These 6 categories are reflected by 6 memory limits which are configured for the lowmemorykiller in the kernel.
Fortunately, it is possible to configure the lowmemorykiller at runtime!
(But only if you are root). The configuration is set in the file: "/sys/module/lowmemorykiller/parameters/minfree"
So if you want to see the current settings, you can do:
Code:
# cat /sys/module/lowmemorykiller/parameters/minfree
This should produce output like this (or similiar):
Code:
1536,2048,4096,5120,5632,6144
These values are the 6 memory limits on which Anedroid starts to kill processes of one of the 6 categories above. Be careful, the units of these values are pages!! 1 page = 4 kilobyte.
So the example above says that Anddroid starts killing EMPTY_APP processes if available memory goes below 24MB (=6144*4/1024). And it starts to kill unused CONTENT_PROVIDERs if available memory goes below 22MB (=5632*4/1024).
So if you want to try if your Hero goes faster when fewer processes are running you can try to adjust these settings. For example if you practically do not want any empty processes you can set the corresponding value very high. For example, you can set the values like this:
Code:
# echo "1536,2048,4096,5120,15360,23040" > /sys/module/lowmemorykiller/parameters/minfree
This example will tell Android to kill unused Content providers if less then 60MB is available and kill empty processes if available memory goes below 90MB.
All other processes will stay untouched! Do you see the advantage compared to process killers?
One word about durabilty:
If you change the settings like this, they are NOT PERMANENT. They will be gone after the next restart of your phone. So you can try to play around a little bit. Please share your results if you find some improvements!
To make this settings survive also reboots you need to somehow set this at startup. I am running Modaco's custom rom and added the command to the startup script /system/init.d/ramzswap.sh, but there may be other ways to do this.
Currently I also disabled compcache on my Hero and set the lowmemkiller very aggressive, as it seems to me that this makes my hero very responsive.
So these are my (current) settings:
Code:
echo "1536,3072,4096,21000,23000,25000" > /sys/module/lowmemorykiller/parameters/minfree
(and compcache disabled)
But play around.. I am glad about any feedback.
Please also give feedback if I am wrong or missed something!
Thx!
i would be interested in changing the application which is startet when i long press on home (normally its the task changer of sense ui, but i want another program to be started)
this is excellent!, I just updated the ramzswap.sh to your settings and I can tell you it does an excellent job so far of running for like 20minutes, my ram is around 76 MB with facebook with all the htc widgets running, it usually drops to around 50 MB, does compcache save alot of ram when you disable it?
Thanks so much for the amazing info!, its hard someone to explain everything for you like you did.
woah!! i cannot stand my phone when RAM is less than 100mb
i keep it around 115~130
anyway whats new in ur method? why not use the Kill-All widgets after setting the ignore list ..or smth like "Automatic Task Killer" ??
inkredi said:
anyway whats new in ur method? why not use the Kill-All widgets after setting the ignore list ..or smth like "Automatic Task Killer" ??
Click to expand...
Click to collapse
Its more sensitive, and doesn't require any more input from the user, whilst having a constant effect
The difference of this method compared to task killers like "Automatic Task Killer" is that there is no separate application involved.
There is no widget or taskkiller process which needs to be run.
Instead you configure the Android kernel itself how to handle processes. While taskkillers need to be run regularly (automatically or by hand) to check memory and kill processes, the way I described this gets done complete automatically by the Android kernel, immediately when available memory goes under the configured limits.
There is also no need for ignore-lists or something like this, as the Android kernel knows which applications it can kill and which not. Furthermore you can configure much more fine-grained when to kill which processes and the kernel is using the internal "last recently used" list and kills the least needed processes first.
External task killer only can kill processes "blindly", they cannot see which processes are "empty" (not hosting an Activity) or which have been in the background for the longest time, and so on..
When people tell you that taskkillers are evil, they mean that taskkillers interfere with Androids process management in a way this was never intended. The way I described you still let Android handling processes itself, but you just tell it to be more restrictive.
So this is far less invasive into the Android system and (should ) have less side-effects..
But I'm still learning. I am a programmer who wants to understand things. And fortunately here we have the source to do so..
These values can be directly edited in your initrc
*APP_ADJ, *APP_MIN_ADJ, *ADJ, *PROVIDER_MEM, *SERVER_MEM and *APP_MEM
Thanks for the info!
Hmm.. but how can I change the init.rc? As it is placed directly in the root directory remounting and changing the file seems not to work (like on the the /system partiton).
I can remount and change the file, but the changes are gone after a reboot. The root dir is mounted as "rootfs".. No idea how to change files in there (without building a new ROM).
Well, you can extract the initrc from the boot.img (first you need to extract the ramdisk)
Edit, and repack.
Very interesting
My minfree: 1536,2048,4096,5120,15360,23040 (compcache disabled)
The system is very fluid and responsive. I dont know if this is by the tweak or compcache, but I see in EStrong Task Manager just the necesary process, no more empty process and more space for hidden process, second.
Very curious.
@adwinp: Ok, i thought already about this. I will try when I have some time. Thanks for the info.
Great Post !!
I try this for 12h
Code:
# echo "1536,2048,4096,5120,15360,23040" > /sys/module/lowmemorykiller/parameters/minfree
with compcache active and MCR 3.1 and hero has an incredible boost ! Apps load more quickly and fluidity is improved very well and i don't use anymore any "killall" app.
Background service also works perfectly.
Without this tweak, i noted random delay when many apps are loaded.
There is a way for disable compcache in MCR ?
@Xfight: Glad to see, I could help you.
Regarding compcache: I disabled it (for testing) on MCR by commenting out the line
Code:
/system/xbin/insmod /system/lib/modules/ramzswap.ko disksize_kb=XXXXX
in "/system/init.d/ramzswap.sh"
Or just temporarily (until next restart):
Code:
# swapoff /dev/block/ramzswap0
So exciting to hear this Anyway, I am some kind of new in linux programing. Would help a lot, if there is a step by step to add the command to the startup script /system/init.d/ramzswap.sh Do I have to go to recovery mode to do so? And use which application or just normal text editor to edit the script?
Thnks,
Anybody tried this on 2.1 Eclair AOSP ROMs?
I get permission denied when I try to change the values
# echo "1536,2048,4096,5120,15360,23040" > /sys/module/lowmemorykiller/parameters/minfree
Tzira said:
I get permission denied when I try to change the values
# echo "1536,2048,4096,5120,15360,23040" > /sys/module/lowmemorykiller/parameters/minfree
Click to expand...
Click to collapse
you need a rooted device for do this
This is just superb idea. I was looking for something like this for ages. Nice one mate.
By the way...
Tzira
I get permission denied when I try to change the values
# echo "1536,2048,4096,5120,15360,23040" > /sys/module/lowmemorykiller/parameters/minfree
Click to expand...
Click to collapse
Did you try type "su" and then the command ?
UPDATE to make more clear what these 6 values mean, when you enter a command like this:
Code:
echo "1536,2048,4096,5120,15360,23040" > /sys/module/lowmemorykiller/parameters/minfree
[B] #1 #2 #3 #4 #5 #6[/B]
Important: The unit of these numbers are "pages" (1 page = 4 kilobyte)
These define 6 limits of minimum "available" memory (which is not necessary equivalent to "free" memory under Linux, but this is an other story). These 6 limits are associated with 6 categories of processes under Android.
If the available memory goes below one of these limits, the kernel starts to kill processes of the corresponding category.
On Android the "ActivityManagerService" takes care of assigning processes into one of these categories (which means nothing more than setting an appropriate "oom_adj" value).
Details on the 6 categories:
#1: FOREGROUND_APP:
Only the current application in the foreground. This is the activity that is the focus for the user's actions.
#2: VISIBLE_APP:
Applications which are not in the foreground but are still visble to the user. That is, another activity lies on top of it and that activity either is transparent or doesn't cover the full screen.
#3: SECONDARY_SERVER:
First: The "HOME" application (or SenseUI on Hero) also falls into this category! So do not set this limit to high!
Further: All (secondary) services, which are currently running. These are all normal services as we know them from applications. ("Primary" services are life-critical services like the PhoneService which never will get killed by the lowmemorykiller.)
#4: HIDDEN_APP:
Any other Activity which falls not under #1 or #2. So any Activity as soon as it is not visible anymore (i.e. in the background, because of pressing Home, or starting another Activity).
#5: CONTENT_PROVIDER:
Processes which host a content provider that does not have any clients connected to it.
For explanation: Content providers store and retrieve data and make it accessible to all applications. Examples are: the contacts content provider, the calendar content provider, the sms content provider, and so on. These allow different applications to access the same underlying data (contacts, calendar, ...).
#6: EMPTY_APP:
This is a process without anything currently running in it. On Android a prgrammer can call "finish()" to close an activity. The system still can decide to keep the "empty" process running, to avoid the startup overhead when the user needs the activity again. All processes in this group are empty processes.
So, to sum up a little bit:
I definitely would be careful with the first 3 values, as they may affect directly the user experience! But it seems there is a wider range of settings we can try at the last 3 values. These applications could be safely killed. So try around until you find appropriate values for your needs.
As long as you just perform the "echo ..." command and do not change any startup script or something like this you should be on the safe side. If something goes wrong, just restart your phone and everything should be normal again.
Hope that helps..
[edit]
All said about this should apply to any Android device. Not only the Hero and not only Android 1.5. So try it also on Eclair!
[/edit]
eujene said:
Anybody tried this on 2.1 Eclair AOSP ROMs?
Click to expand...
Click to collapse
Im using it on the AOSP 2.0.1 rom for the CDMA Hero. I don't notice a whole lot of difference.
Have been doing some relatively extensive testing of the ROM and whislt it's not perfect by any means, here's what I have found makes it a hell of a lot more useable. The ROM does seem to be very fussy about what it does and does not like.
First off, I would suggest that you carry out a Task29 format of the device to ensure the ROM memory is clean.
In respect of this, I suggest that you remove any storage card as this causes a few issues in trying to get into bootloader by pressing the volume down key and the reset button.
It doesn't seem to make much difference if the SIM card is left in or not, but would recommend removal just in case.
(if you do carry out a Task29 format and brick your device, it's your problem, not mine, you didn't have to do it)
Once you have entered bootloader and re-connected you device to you PC, run the ROM update utility for 2.07.xxxxx
Once this has completed, turn off your device and re-insert your SD Card. (I tend to make sure the card has been formatted and is completely blank before re-inserting it).
Then, perform a hard reset. in doing this, it does seem to eradicate reported issues with the speaker phone and the call volume.
Then I install .NET3.5 and MemMaid 2.3. Actually, whilst I mention MemMaid, Sense 2.5 does not like certain elements, specifically the Quick Cleaner, Advenced Cleaner and the Reclaim RAM tools. Every time I have used these and soft reset, the device wants to make a data connection. Even un-installing MemMaid does not fix this, only a hard reset. MemMaid does have a good registry edit tho. I think I have narrowed this down to the HTC Peep app.
Next up is to carry out a number of registry tweaks, there's quite a few:
Change:
HKLM/System/GDI/GLYPHCACHE To: 524288 (change both keys in there)
This allows for much smoother font rendering, especially when scrolling and defiantely works!
Change:
HKLM/System/StorageManager/Filters/fsreplxfilt/ReplStoreCacheSize To: 131072
This creates a filesystem 128k sector cache filter, improves data throughput from ROM to RAM (probably) and does seem to improve indexing response and file browsing.
This didn't seem to make much difference on my device, but every little helps.
Change:
HKLM/Drivers/Display/VMMaxHeapSize To: 33554432
This changes the VideoMemory max heap from 16k to 32k. Definately works!
Change:
HKLM/Software/HTC/HTCMenus/EnableVSync To: 0
This turns off VSync in sense, making it MUCH smoother. check out the speed of the weather animations now! see that they "judder" less! On my device, this was set to 0 by default. On the weather demo, the windscreen wiper is on speed!
Change:
HKLM/Software/HTC/MemoryRequired_ByAP To: 524288
Lets allow SENSE to have some room to breath, shall we? - Definately works! i would go as far as saying as to even double that figure. Definately makes a diffeence when editing contacts.
Credit where Credit is due, the above is brought to you by g.lewarne Taken from here
Real Exit for HTc Album
By default, when you click on the ok/X button in HTC Album, the app minimizes and does not exit. Make the following change to really exit the app and thus save some program memory: HKEY_LOCAL_MACHINE\Software\HTC\HTCAlbum "ok_minimize" = dword:0
This works well, but then when viewing photos, they always start blurred and then clear, slightly annoying.
Boost Performance:
Navigate to: HKEY_LOCAL_MACHINE\System\StorageManager\FATFS
Change - CacheSize to 4096. Works for some and not for others though.
Not sure if this does actually make a difference, but it's good to go.
Speed Up Scrolling of Internet and People Tab, Album Page and All People Page
You can spued up the speed of scrolling when you flick your finger by modifying the following registry tweak.
HKLM/SOFTWARE/HTC/HTCScroll/velocity_factor
Change to 20000 or higher. Experiment to what suits you. Definitely works!
Again Credit due where credit due, these and other hacks are brought to you by tboy2000 which can be found Here.
Facebook albums not working?
Try adding this Reg entry:
HKEY_LOCAL_MACHINE\Software\HTC\OnlineAlbumSDK"PhotoPath"="\OnlineAlbumTemp\"
IIRC, this is a String value. You don't need the HTC hotfix for this although it won't do any harm installing it.
This is brought to you by eras2r and can be found Here There is also a cab file to do it for you on that page. Only thing is, I want it to point to a folder on my storage card
There are of course the other usual hacks and modifications for the TP2, but they have been heavily discussed in other threads.
I hope the above helps you out, it certainly makes this ROM a far more enjoyable experience!
Many thanks for posting these tweaks. I recall you had a lot of Sleep of Death issues - did you resolve them?
Edward Lowy said:
Many thanks for posting these tweaks. I recall you had a lot of Sleep of Death issues - did you resolve them?
Click to expand...
Click to collapse
Nope, only had that issue once.
Scroll Tweak - Thank you
Thanks so much for the scroll tweak. I've been looking everywhere for this! It would drive me nuts that it was sluggish.
Speed Up Scrolling of Internet and People Tab, Album Page and All People Page
You can spued up the speed of scrolling when you flick your finger by modifying the following registry tweak.
HKLM/SOFTWARE/HTC/HTCScroll/velocity_factor
Change to 20000 or higher. Experiment to what suits you. Definitely works!
Again Credit due where credit due, these and other hacks are brought to you by tboy2000 which can be found Here.
Click to expand...
Click to collapse
Verizon HTC TP2 WM 6.5
SpeedBooster 2.0
Product Overview:
An innovative product from Teksoft, Speedbooster helps you get maximum performance out of your mobile device. We've designed it to be completely safe for your hardware, and easy to use. The built in Benchmark module will easily show your performance gain.
SpeedBooster 2.0 is composed of 6 parts, built to work together to make your device faster and more powerful. In simple terms, we could say that SpeedBooster is "SAFE overclocking", since it allows you to focus the CPU power to various programs running on your device, without stressing the hardware. Besides this, a large number of tweaks have been added to control the functionality and performance of the Memory, Video and Storage!
Best practices list:
Speedbooster can help you distribute the resources of your mobile device to certain tasks, more important to you in a given time moment. Eg.: a user interface, a GPS program, a system component, etc.
You cannot use Speedbooster to gain more hardware power then your device already has, but you can use it successfully to make the important apps run faster at the cost of less important applications.
Here's a Best practices list to help you get started:
# Speed up only 1-2 tasks at a time
# Set lower non-zero priorities for the processes you don't need/use
# Give high priority to your GPS software/Multimedia player/Favorite interface
# To increase the system performance, "boost" gwes.exe, filesys.exe, devices.exe, etc
# Use the Benchmark to see the Hardware performance of your device, but keep in mind that boosting non-system tasks will not change the results.
# Explore, research and tweak various processes according to the configuration of your device for maximum performance!
U can get it here : http://www.teksoftco.com/index.php?section=speedbooster
Remember it s not a free program
there is a demo if u like it purchase it
i m already ...