Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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.  What are the semantics
of an NSView?  I'm imagining something more along the lines of a
Window than a GC -- would you get one NSView into which a
number of GC's would draw, or would you get one NSView per
GC?  If the former is the case, then operations must be individually
bracketed unless there are no side-effects from keeping the NSView
perpetually locked.  In the latter case, the constructor/dispose
approach might work, but again only if there are no side-effects
from keeping the NSView locked for long periods of time.

Introducing new API to enfore the locking rules is not likely to
happen except perhaps as an optimization since depending on
these calls would break existing code.  I could see perhaps
a future gc.lock()/unlock() pair that did the appropriate task
and set/reset a boolean.  Each GC operation would check the
boolean and, if false, bracket the operation with whatever
necessary locking code.

Something else you should be aware of.  GC's may be used to
draw into a variety of things, including printers.

[IMHO, GC should have been an interface, with some kind of
getGC() factory interface implemented by all objects that can
provide a GC for raster operations instead of new GC(Drawable)
which precludes the design of GC subclasses.  You can still
use delegation of course with a (probably unnoticeable)
performance hit.]




Back to the top