Compact Framework - Lightweight GUI Framework? [closed]

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

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.

Answer 2

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 3

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 4

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.

Also, 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.