On Mon, 31 Jan 2005, Dan Williams wrote:
> On Mon, 31 Jan 2005, Philipp Lohmann - Sun Germany wrote:
> > > Having done native widgets twice over (GTK, and then Aqua for NeoOffice/C)
> > > I spent the majority of my time with the Aqua stuff being frustrated with
> > > tying together the event model.  There needed to be a couple threads: 1)
> > > The cocoa event loop for the NSApplication object, 2) The OOo event
> > > thread, and 3) The actual OOo drawing/everything-else thread.  It seemed
> > > that even on a dual-processor machine, events took a while to get from
> > > Cocoa to OOo.  The problem with Cocoa is that OOo tries to do too many
> > > things when an event is processed, including drawing and whatnot.  Cocoa
> > > really expects the app to simply update its internal state and then
> > > re-draw itself when _needed_ (and asynchronously when it gets a drawRect:
> > > message) rather thabn OOo's method of "get a mouse click and update
> > > everything before returning".  Or something like that.  I kept running
> > > into really really long call-chains, deadlocks, and crashes resulting from
> > > this issue.
> >
> > Huh ? When you press a VCL button it should be drawn clicked. How should
> > aqua know that it has to send a "drawRect message" when a button got
> > clicked ? Should vcl call some kind of invalidate method instead ?

I should point out here the one way that Apple was able to get the
fluidity of movement in the Aqua interface was the concept of MVC in some
ways.  They decouple the actual drawing from event that triggered it,
allowing event processing to continue during the draw.  In the Cocoa event
loop, they also combine drawing events/invalidate events into one
operation depending on how much time has passed, to make applications more
efficient when they update their views.  So even though the app may have
called Invalidate on 5 different areas of its views, it will only get 1
redraw message with all drawing clipped to the union of those 5 different
areas.  More efficient and deals better with fluctuating framerates (ie
smoother) AFAIUI.

Dan

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to