On Mon, 31 Jan 2005, Daniel Vogelheim wrote:
> > 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 have seen GUI code (GDI and Swing, if I recall correctly) that uses
> exactly this strategy: Drawing only ever occurs at the system's request.
> If the app wants to redraw something, it sends an invalidate call to
> system and later handles the corresponding redraw event. The advantage
> is a) uniform redraw handling, and b) the system may optimize such
> events. (E.g., don't redraw hidden things, or batch small redraws into a
> single event.) I thought this was common, but as my initial disclaimer
> says: I haven't done any GUI stuff in a while, and never with OOo.
This is also how Aqua/Cocoa works.
> However, I do find it rather strange that immediate redrawing could
> possibly cause application instability. I can't help but think that
> Cocoa must be at fault...
This wasn't the part causing the instability, it was the long call chains.
First, when calling OOo's MouseDown function directly from the Cocoa event
processing function, I ran into a lot of locking issues that I didn't
really want to deal with. Furthermore, performance really sucked since
the app was blocking while OOo was doing all its drawing. Worse yet,
some menu calls run dialogs that would then sit in the OOo event loop
and block the rest of the app since they hadn't returned to the event
processing function because they called Dialog::Run().
Cocoa Event loop gets Menu Down
Calls OOo menu down function for the Menu
Calls Dialog::Run()
Expects events, but none happen because we
are no longer processing events because we
haven't returned to the Cocoa event loop
The second pass I did was to have the App's Cocoa event loop in a separate
thread and pass the events into a queue, that the main OOo thread would
pull events from and shove them to the rest of OOo. That also proved to
be quite slow and had issues with multiple windows (like Dialog::Run()
which enters a completely new iteration of the OOo event loop). Dialogs
were severely unstable, as were menus, since pulling down menus is
controlled by the _system_ and not the application. OOo wants to control
the menus, so menus were also slow as the Cocoa events were bridged to the
menu system. Furthermore, since OOo wants to know stuff like "did the
menu get clicked on, if yes let me modify its structure", that code would
get run in the main Cocoa thread of the application and cause some of the
lcokign issues. Forwarding the events to the OOo event thread would be
useless since the menu was already pulled down before the OOo event thread
would get the signal, and the OOo would want to modify the menu's items
_while the menu was down_. Worse, Cocoa only allows each submenu to have
only 1 parent, while OOo tries to pass the same menu structure around
between windows because it expects each window to have its own menu bar.
Part of this is my failure as a developer, and part of it is the mismatch
between Cocoa and OOo. Some of the problems were solved (for example the
submenu parent problem) through gross hacks (re-parent the submenu when
any of its parents is pulled down), and some were not (the menu-expose
event calling OOo code directly).
Patrick and Ed seem to have made some very good progress with many of
these issues with NeoOffice/J, since it uses soem of the same concepts
(the Java event code is in a separate thread from the OOo event loop and
they use a queue to share pass events to each other).
Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
