RE: [OSX] Compositional Graphics API

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Andre Schnoor
> Sent: June 4, 2007 3:07 PM
> To: VW-Development List
> Subject: [OSX] Compositional Graphics API
>
>
> As mentioned before, I did considerable experimentation and
> prototyping w.r.t. a compositional API for modern graphics
> platforms (OSX in this case, but also suits others). My goal was to
>
> 1. get a working solution asap
> 2. require only minimal changes to L&F and UI packages 3.
> keep existing application code without major changes 4.
> increase performance in the 10x - 20x magnitude 5. get and
> idea of how future APIs could look like
>
> I now have a working prototype VM. It implements four new GC
> primitives in order to cope with persistent host GCs and
> nested graphics compositions. The existing graphics
> primitives had to be modified in order to support the new
> drawing model. While hacking my way through the code, I also
> found some minor bugs (see below).
>
> Composition and resource management is done by a package
> "Graphics-Composition". The necessary changes to the L&F and
> UI packages (currently only Chimera L&F and Wrapper) were
> minimal. This is how compositional drawing works on the image side:
>
>     aGraphicsContext
>         compose:[ .... any drawing goes here ... ]
>
> All drawing that occurs during the execution of the block
> (incl. nested recursions and "orphan" copied GCs) are
> transparently collected in a composition and flushed to
> display when done. The message #compose: is also understood
> by GraphicsMedium (Window, Screen) and ApplicationModel for
> convenience.
>
> Optimizing existing packages for use with the compositional
> API is simply a matter of wrapping sensible portions of
> drawing code into compose:[ ... ] -- that's all. This has
> proven to be a rewarding and fun task. For backward
> compatibility, #compose: could be provided as a dummy method
> (evaluate the block only).
>
> This is roughly what I've changed with the VM:
>
> * Host GCs created once and re-used frequently, cached in
> GraphicsContext instance variable
> * Selective "write-though" and lazy application of parameters
> (saves a big deal of redundant calls)
> * Resource management supported by finalization
> * New ObjC class STGraphicsComposition
> * Draw to NSView directly, when surface is a window
> (eliminated NSImage
> buffering)
> * Eliminated the window refresh timer
> * Forward view scrolling to window manager (got rid of NSImage copy
> operations)
>
> Current results are quite satisfying. The VM is really snappy now.
> Hopefully I fixed the last stability issue today. The Music
> Prototyping Studio (which I consider the worst case and
> general acid test concerning graphics load) survived the
> visualization of Anton Bruckner's 7th symphony in its
> entirety (~40,000 graphics ops per page) with scrolling, even
> while playing. It could still be a bit faster, though. I'll
> see what I can do.
>
> Without the #compose: construct, the new VM is ridicuously
> slow for a standard image (like the current VM without the
> refresh timer). After wrapping a few #displayOn: methods, it
> gets faster very quickly. As of currently, I identified
> approx. 15 sensible spots, making the VM feel really snappy -
> almost like on Windows. Double buffering BTW is redundant and
> can be eliminated.
>
> I am currently testing a combined mode that uses a delayed
> window refresh (timer based) for "orphan" drawing calls that
> aren't wrapped into a composition. This may lead to
> acceptable results even on standard images that lack the
> "compose:" enhancement.
>
> Regardless whether these VM modifications will ever get
> beyond my development machine: The compositional framework is
> definitely useful for all sorts of modern graphics
> interfaces, wheter primitive-based or via DLLCC. It's forward
> compatible. Upgrading existing code is easy and non-critical,
> which makes the proposed scheme a good solution for practical
> needs (as opposed to a "perfect solution" which would require
> major rewrites of almost all graphics-related packages, the
> base image and existing applications otherwise).
>
> If current directions of VM development point to this
> direction, I am willing to further support this idea.
>
> Andre
>
>
>
>