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.
With the rise of mobile devices, companies have even greater incentive to streamline and scale their agile processes through the use of enterprise test management software.
Agile methodologies have put countless software makers in position to move quickly on demanding projects, through a combination of rigorous testing regimens and close collaboration between developers and operations teams. With the rise of mobile devices, companies have even greater incentive to streamline and scale their agile processes through the use of QA management tools, which support manual and automated testing and coordination of development across multiple project groups.
Mobile app development and the need for automated testing
Last quarter, more Internet traffic originated from mobile phones than desktop PCs. Plus, most of that activity – 80 percent – came from native apps rather than Web browsers, underscoring key changes in what end-users expect from software, namely speed, reliability and usability. According to Appurify CEO Jay Srinivasan, a 2013 uSamp study found that more than 70 percent of respondents will delete a mobile app after it crashes, even if it’s the first such incident.
Certainly, the challenges of creating high-quality, stable mobile apps can become a money sink for some shops. There are many platforms to address, each with its own nuances, and development costs can easily run past six figures. How can developers and QA analysts keep up with the growing demands and pressures of the current mobile app environment?
For starters, it’s worth reexamining what kinds of tools are currently being used and if and how they ensure that quality standards are being met. Some teams may limit themselves to crash analytics and manual tests, but such an approach is increasingly unsuited for development schedules that require software to be pushed out rapidly to substantial - and growing - user bases. The maturity of the mobile hardware ecosystem also means that numerous devices have to be accounted for in each testing cycle.
“Another issue we see is that developers have an over reliance on manual testing methods,” observed Srinivasan for BetaNews. “With device fragmentation resulting in more than 30 device and OS combinations for iOS, and an order of magnitude more for Android, manual testing is not a scalable approach for mobile developers. To ensure performance and functionality of your app prelaunch, across all selected device and OS combinations, developers should add test automation to their mobile testing tool kit.”
Mobile devices are also subject to myriad volatile conditions such as mobile data connection strength and limited memory allotments. Performing diligent testing requires the definition, reuse and analysis of complex test scenarios. Fortunately, organizations can use test management systems to overhaul and scale their testing process for current market realities.
Does agile development enable the right level of testing?
Automated testing is a key enabler of agile and test-driven development, methodologies that have allowed enterprises to “produce higher-quality software within swifter release cycles that is more in tune with user needs,” in the words of Skytap executive Sumit Mehrotra. With more devices to manage and applications becoming fundamental to consumer and business workflows (it’s perhaps telling that Bank of America now does more development than Microsoft), it seems that organizations could never perform too much manual and automated testing, considering the stakes.
“The standard explanation for why we create automated tests is that by having them, we can know that our system continues to work properly even while adding new functionality or refactoring existing code,” wrote Mark Balbes for Application Development Trends on agile testing practices. “Test-driven and behavior-driven development takes this a step further by using automated tests to drive software design.”
However, there has been some recent debate about the place of test-driven development and automation and whether they have caused teams to actually implement excessive levels of testing. Balbes himself takes up this point in his article, pointing out that such practice could increase the difficulty of refactoring down the line.
The key may be developing a knack for knowing when to perform unit and integration tests on given types of objects, which may take time - and is ultimately more of an art than a science. But for organizations committed to agile development, tools such as agile test management platforms provide the foundation for setting up testing processes that are tailored to their respective needs. Both manual and automated tests are supported, and progress can be easily tracked so that measures can be refined over time.