On 2013-05-28, at 21:19, Jeff Gonis <jeff.gonis at gmail.com> wrote:

> Hi Everyone,
> 
> Regarding vector graphics in squeak I believe that VPRI has been
> experimenting with Nile and Gezira as a method of getting compact
> vector graphics into their "Frank" system.
> 
> Bert released packages that can be used to generate a VM with support
> for Nile and Gezira, and I have use these to compile one.  I was able
> to play around and experiment with nicely anti-aliased graphics while
> developing in the live style that I enjoy so much.
> 
> I also grabbed a Pharo VM and played with Athens a bit this morning.
> 
> So my gut would say that there are two choices before us: Adopt the
> work that Pharo is doing with Athens, or go with the VPRI Gezira work.
> Below is a list of (IMO) pros and cons for each approach.  I would be
> curious what other people think.
> 
> Pros for Athens:
> - Relies on Cairo which is developed by a large outside group
> - Cairo appears to be relatively high performance
> - PDF support allows for easily printable image/document creation
> - Has dedicated development from the Pharo community
> 
> Cons for Athens:
> - Cairo is pretty complex if we want to ever patch or fix anything
> - Relies on NativeBoost enabled VMs which are not the VMs that Eliot
> provides and I believe these need pharo specific image-side code at
> this point
> 
> Pro for Gezira:
> - Very small and compact logic, does have ramp up time but would be
> much easier to modify than ~100,000 lines of cairo code
> - Used by VPRI for "Frank" so it is being used in a system of complexity
> - Seemed to have a pretty decent API from what I could understand
> 
> Cons for Gezira:
> - At this point the product of one man (Dan Amelang) or possibly one
> research group (VPRI)
> - Unknown performance relative to other libraries like Cairo.  Maybe
> Bert can chime in here.
> - Unknown support for PDF and other image types.
> - Diverges from Pharo, so could split the community unnecessarily.
> 
> Anyway, I think that getting high quality vector graphics in Squeak
> would be a fantastic boon, as Squeak is such a graphical environment
> and live coding with Morphs is great right up until you see chunky
> aliased lines on your canvas.
> 
> Thanks for your time,
> Jeff


Good analysis. 

I don't think Gezira is ready yet outside of a research system. Cairo is much more mature and more widely supported. 

The best solution IMHO would be Athens with a plugin-based backend (to make it work without NativeBoost, which as a form of FFI has no business being in the core system). 

Note that there are two orthogonal problems: quality, and speed. For quality the vector graphics would help, for speed, not really. What we need for speed is hardware-based compositing.

The two can work well together. Each top-level morph (e.g. window) would render into a "surface", and all surfaces would be composited onto the screen. This gets rid of damage redraw, and allows extremely fast moving of windows. Optionally, submorphs can be backed by such surfaces too. It would be for the individual morph to decide whether to use bitblt or vector graphics to draw into its surface.

This is basically how any modern UI framework works, and the only way to make it really fast. There are just too many pixels even for a fast CPU.

The price is added complexity, and less flexibility. There won't be easy/fast access to the whole display contents anymore. Developers will need to think in layers, not pixels. An Etoys car cannot easily bounce off a window in its way anymore.

That said, it's still worth doing. 

- Bert -