[m-dev.] Mercury UI framework proposal

[Jonathan Morgan]

On 1/27/06, Ian MacLarty <maclarty at cs.mu.oz.au> wrote:
>
> On 27 Jan 2006, at 03:08, Ralph Becket wrote:
>
> > Ian MacLarty, Monday, 23 January 2006:
> >> I've managed to implement the UI framework Julien and I were designing
> >> without constructor classes.
> >
> > As a proof-of-concept sketch, I rather like it.
> >
> > I have some ideas about efficiency if this approach is going to fly
> > (e.g., the GC burden would be huge if a complex interactive GUI had to
> > be recomputed on every mouse event), but we should probably discuss
> > these in the office.
> >
>
> My intuition is that this won't be a problem, because UIs normally work
> in a "do some work, wait for an event, do some work, wait for an event,
> etc" manner.  We could force a garbage collection during the "wait for
> an event" periods.  Anyway we can discuss this further when I return.


That is an option.  However, how much would compile-time garbage collection
affect the situation?  Is it a matter of the load associated with the work,
or with the GC associated with the work.

I think there are also some issues to explore with regard to how we
> render native GUIs (e.g. gtk).  Do we redraw the whole GUI each time,
> or just compute the difference between the old and new gui and redraw
> the bits that have changed.  I think we'll need to adopt the second
> approach, if not for performance, then to avoid flickering or other
> strange artifacts of redrawing the whole GUI (such as maybe windows
> jumping around).



In some cases it will lead to more work having to look for the differences
(ie. if it's just about all different), but it should save work in most
applications at most times (and drawing pixels is what often makes them
crawl, at least in my observation).

Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurylang.org/archives/developers/attachments/20060201/7ffa7ad6/attachment.html>