Compact Framework - Lightweight GUI Framework?

Question

Winform on CF is a bit heavy, initialising a lot of windows handles takes serious time and memory. Another issue is the lack of inbuilt double buffering and lack of control you have over the UI rendering means that during processor intensive operations the UI might leave the user staring at a half rendered screen. Nice!

To alleviate this issue I would seek a lightweight control framework, is there one kicking about already or would one have to homebrew?

By lightweight I mean a control library that enables one to fully control painting of controls and doesn't use many expensive windows handles.

NOTE: Please don't suggest that I am running too much on the UI thread. That is not the case.

Answer 1

Actually, you can override the paint event.

And the idea is that you offload long-running operations to a separate thread. That's no different from any other event-driven framework, really. Anything that relies on a handling a Paint event is going to be susceptible to that.

Answer 2

a bit slow and you can't control the paint event so during processor intensive operations the UI might leave the user staring at a half rendered screen.

It's generally a bad idea to do expensive tasks on the UI thread. To keep your UI responsive, these tasks should be performed by a worker thread

Answer 3

@ Chris Karcher

Hi Chris, there is ONE processor, it is slow and there are lots of things to do. This means that even if you do put stuff on a background thread (which we do, we'd be idiots if we didn't) you still get the UI thread switching and leaving things half rendered.

Maybe this is somehow combined with the fact that the Compact Framework doesn't come with insta-double buffering so you always get this issue when you're doing a lot AND changing the UI. (the event in question actually stems from a background thread which eventually results in a UI page change).

@ Joel

No, I mean control the paint event. E.G. I say when it runs. This is so I can easily implement the double-buffering.

Answer 4

There's no system that lets you determine when the paint event is raised. That kind of event is generally raised by the window manager layer, which is outside of the application (or even the framework). You can handle the event yourself and just do no work some of the time, but I wouldn't recommend it.

Answer 5

@ Joel

Yes by standard there is no way of doing this, however what one can do is say create a panel. Then add custom objects to the panel that represent but are not controls. These controls will expose an image of their rendered contents or provide their own Paint event that you can control. Then override the Paint of the panel and call the API you have declared on your controls that are not controls. You then handle all the mouse events in the panel and work out which control they originated from so the mouse events work correctly. This will get around the problems you mention, will improve performance and ability to control when to paint and when not to paint (add a boolean property to the panel to control this).

This is what we would call a lightweight gui framework. It provides proper double-buffering for the compact framework and addresses a lot of issues (memory, performance) that you encounter when developing large systems on embedded platforms. However, it's a lot of work, so before embarking on this kind of implementation one should check if such a framework already exists, thus this question.

Answer 6

Ok, just an idea off the top of my head...

How about creating a synchronisation object, e.g. critical section or single lock, in your application, shared between your worker and gui threads. Override the paint. When you start painting, block all the other threads, such that you are not left with a half painted screen while they hog the CPU.

(this of course assumes that presenting a pretty picture to you user is the most important thing you require ;) )

Answer 7

I ran across this the other day, which might be helpful at least as a starting point: Fuild - Windows Mobile .NET Touch Controls. The look and feel is nice, but there is no design time support. I don't know too much about memory footprint, etc but everything is double buffered and the performance appears to be pretty good.