Re: [platform-swt-dev] MacOS X port status?

["Mike Wilson/OTT/OTI" <Mike_Wilson@xxxxxxx>]

fwiw, the photon port does a lock/unlock around *each* graphical operation. It does seem to be a bit of a performance bottleneck, but it works. I suggest you try this initially.

If we wanted to manifest the lock/unlock story as API, it could still be done in a non-breaking fashion, by just having the code for each graphical op check to see if it is already locked before doing the "for free" lock/unlock. This would mean that existing code would continue to run (albiet a bit slower), but performance could be easily optimized in user code.

McQ.

"Jeff Brown" <j9brown@xxxxxxxxxxxxxxxxx> Sent by: platform-swt-dev-admin@xxxxxxxxxxx 11/25/2001 08:35 PM Please respond to platform-swt-dev

To:        <platform-swt-dev@xxxxxxxxxxx>         cc:                 Subject:        Re: [platform-swt-dev] MacOS X port status?

> One new issue showed up:
> 
> - The use of NSView.lock/unlock. Any drawing code must be bracketed 
> by invocations of these
> methods to set up the clipping and other graphics state information. 
> For SWT this is not a problem
> if the drawing code is executed in a PaintListener callback. However, 
> in SWT you can always create a GC and perform direct drawing on a SWT 
> control. This code cannot be easily bracketed without an API change. 
> The only solution I see is to invoke NSView.lock/unlock in the 
> constructor/dispose methods of the GC class.

Not much we can do here.  It looks like each GC operation much
be individually bracketed by the lock/unlock. 

<snip>