[Openmcl-devel] I need Cocoa graphics help

[Gary Byers]

On Mon, 19 Jul 2010, Arthur Cater wrote:

> I have just submitted a ticket saying:
> The link to ffigen-bin-darwinppc-gcc-4.0.0-2005-5-17-11-45-56.tar.gz
> is an alias whose file has vanished.
>
>
>
> If it existed, is this what would be appropriate for my 32-bit OS X 10.5.8 
> with gcc 4.2?

FFIGEN's basically a modified version of GCC; binary versions are really 
sensitive to OS version and the versions of several dependent libraries,
enough so that we haven't really tried to distribute binaries in several
years.

<http://trac.clozure.com/ccl/wiki/BuildFFIGEN> explains how to build 
FFIGEN from source.  I'm fairly certain that you want to use the "Leopard
version with ObjC 2.0 support" described on that page, even if you aren't
using any ObjC 2.0 features.

>
> Do I need it to be able to do things with Core Graphics? I suspect not, but I 
> am having
> difficulties with drawing material into Core Animation layers, doing things 
> inspired by
> Aaron Hillegass's book 'Cocoa Programming for Mac OS X' chapters 31 and 32, 
> and
> also by Neil Baylis's contributed Core Animation Demo:
>
> ... (#_CGContextStrokePath context) crashes my CCL, although prior uses of
>  (#_CGContextMoveToPoint content x1 y1) and (#_CGContextAddLineToPoint 
> content x2 y2)
>  have completed   (whether successfully or not I cannot tell because I 
> cannot see what is drawn)
>
> ... (#_CGAffineTransformMake  ...) arguments are a mystery to me. I've tried 
> six numbers, too
> few args it says; I've tried prefixing them with M11 M12 M21 M22 TX TY and 
> then it says 12
> are too many.

If you can call these foreign functions ... well, that means that something
(interface definitions) are telling the #_ reader macro that there's a foreign
function named "CGContextStrokePath" that takes some number of arguments of
specified foreign types and may return a value of some specified foreign type.

If the #_ reader macro can find those definitions but calling the foreign
functions crashes or misbehaves, that suggests that the functions are sensitive
to the dynamic context in which they're called and that they aren't being called
in the correct dynamic context.  "Dynamic context" in this case includes things
like the current thread and the drawing state of the containing view.

Most drawing in Cocoa views happens in the view's #/drawRect: method,
which is called on the main thread when some system-level code thinks
that the view should be redrawn; the code that calls #/drawRect: does
the right things to connect the view to the Quartz-level graphics
context.  This process of connecting the plumbing is called "locking
the focus"; a thread can generally only draw in a view if it has
locked the view's focus first, and it's good practice to unlock the
focus after drawing is complete.  (If all drawing happens in
#/drawRect:, it's safe to assume that the locking/unlocking happens
before/after #/drawRect: is called.)

<http://trac.clozure.com/ccl/wiki/CocoaBridge> discusses this further
(and contains example code), and there are some other examples of using
Quartz from a drawRect: method in <http://trac.clozure.com/ccl/wiki/GradientWindow>.

Things that "work" from a drawRect: method will likely misbehave and
sometimes crash if called casually from a REPL running in some other
thread.  (The first link above discusses some ways around this and
discusses some of the issues.)


>
> ... The 'context' are got from (#/graphicsPort (#/currentContext 
> ns:ns-graphics-context))
> shows as a "ns:ns-object (uninitialised)" - is this as it should be for an 
> 'opaque data type'?

At least some CG state is per-thread, and I'd guess that that's part of
the listener thread's CG state (and not likely something that's associated
with a view or prepared to do any drawing.)

>
>
> Any assistance will be much appreciated.
>
> Arthur
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>