VW graphical look [Was: Re: MacOS X]

I was one of the people that originally tried to create a compatible display context that used cairo backend, and honestly I’ve only gotten as far as displaying lines and rectangles and bitmaps. Nonetheless, I’m curious myself as to what exactly makes it impossible to continue down that path and get immediate benefits of much nicer looking paths and text versus having to create whole new looks that use cairo-specific API? I don’t yet buy the generic “it’s very different” excuse, people fit propane engines in gasoline cars all the time, but like I say I probably just haven’t gone far enough yet, hence me asking for specifics ;)

 

From: Travis Griggs [mailto:[hidden email]]

Upon reflection (and a nice walk-n-talk to the local Subway), I think the synopsis of this discussion might be boiled down to two viewpoints:

1) I'm fine with the VW GC API, but want what it does to be done better.

2) The VW GC API is old fashioned, I don't care how it does what it does, but I want an API that does more things.

There are some overlaps surely. To date, those of us who have been playing with Cairo are probably more in the #2 camp. 

Brilliant analysis! And many thanks for keeping this discussion calm.

 

I've been talking here about camp #1. We all have a lot of stuff existing at a high level, built on the low-level VW GC API. If we throw that API away, we're reduced to moving all that existing stuff to work on the new API, which is at a substantially lower level than we are used to. Or then we have to re-build the graphics layers on top of Cairo, so we can work at a high level again. Either way, a lot of work. I think camp #1 is better served by a solution that keeps the old API but adds anti-aliasing and alpha. Changing a couple of lines of C in the VM, and linking to GDI+ rather than GDI, may be a good solution to get this working on Windows. (OK, so it will be more complicated than that, but you hopefully get the point.)

 

I'm all in favour of the many extra Cairo features. We need them more than many people, as we are building a graphical modeling tool. I wrote pure Smalltalk implementations of gradient, radial, square and path fills, with multiple color points. Optimizing that so you can directly edit the angles and color points of the fills in real time was fun, but hard enough that I'm happy if I don't have to keep doing things like that. Being able to do Cairo drawing (with low-level calls) to a VW GraphicsContext may be a good solution for this.

 

Steve

This is a very good way to do it.  One successful implementation is
VisualSmalltalk with an OS/2 and a Windows version.  In this flavor of
Smalltalk all the graphics and windowing code is handled in the image
and written in Smalltalk.  Applications are easily portable between
Windows and OS/2, though not binary compatible.

-Carl Gundel
http://www.libertybasic.com

Subject: Re: VW graphical look [Was: Re: MacOS X]


> Steve,
>
>     basically the VM code is at completely the wrong level.  By
putting
> things down in the VM
>
> - the VM has to mantain a complicated and ineffective cache of the
last
> graphics context used so that it doesn't have to rebuild the OS's
graphics
> context from it on every primitive operation.  In any case it has to
do
> significant work to verify the cache is valid (compare lots of state
in the
> VM's cached GC ith the image-level GC) and then update the cached GC
with
> whatever may have changed.
>
> - the VM code is inaccessible, not extensible, relatively hard to
mantain,
> not shared between platforms, and is C.
>
> The only advantages the VM code has are
> - allows the VI code to be platform-independent (and this is
increassingly a
> dubious benefit right?)
> - allows certain operations to benefit from C speed (e.g. characer
string
> writing where it has to be composed out of writing individual
characters)
> - its easy to enfore platform independence because the VM mediates all
> graphics access
>
> If work is put into the FFI then the speed advantage goes away.
Having an
> image-leve implementation allows direct use of an OS GC with no need
for the
> VM cache, allows the VI to get to whatever extensions the platform
provides
> easily, allows the VI to implement platform-independent fallback code
in
> Smalltalk instead of costly buggy C.  Platform-independence can be
> maintained using a test suite.
>
> Essentially moving the whole ball of wax up to the image will result
in
> something that can evolve much faster and be maintained much more
cheaply.
> But to do this the initial hump of implementing the existing
facilities in
> Smalltalk for three plaforms must be traversed.
>
> On 5/24/07, Steven Kelly <[hidden email]> wrote:
> >
> >
> >
> >  *From:* Travis Griggs [mailto:[hidden email]]
> > Upon reflection (and a nice walk-n-talk to the local Subway), I
think the
> > synopsis of this discussion might be boiled down to two viewpoints:
> > 1) I'm fine with the VW GC API, but want what it does to be done
better.
> > 2) The VW GC API is old fashioned, I don't care how it does what it
does,
> > but I want an API that does more things.
> >
> > There are some overlaps surely. To date, those of us who have been
playing
> > with Cairo are probably more in the #2 camp.
> >
> > Brilliant analysis! And many thanks for keeping this discussion
calm.
> >
> > I've been talking here about camp #1. We all have a lot of stuff
existing
> > at a high level, built on the low-level VW GC API. If we throw that
API
> > away, we're reduced to moving all that existing stuff to work on the
new
> > API, which is at a substantially lower level than we are used to. Or
then we
> > have to re-build the graphics layers on top of Cairo, so we can work
at a
> > high level again. Either way, a lot of work. I think camp #1 is
better
> > served by a solution that keeps the old API but adds anti-aliasing
and
> > alpha. Changing a couple of lines of C in the VM, and linking to
GDI+ rather
> > than GDI, may be a good solution to get this working on Windows.
(OK, so it
> > will be more complicated than that, but you hopefully get the
point.)
> >
> > I'm all in favour of the many extra Cairo features. We need them
more than
> > many people, as we are building a graphical modeling tool. I wrote
pure
> > Smalltalk implementations of gradient, radial, square and path
fills, with
> > multiple color points. Optimizing that so you can directly edit the
angles
> > and color points of the fills in real time was fun, but hard enough
that I'm
> > happy if I don't have to keep doing things like that. Being able to
do Cairo
> > drawing (with low-level calls) to a VW GraphicsContext may be a good
> > solution for this.
> >
> > Steve
> >
>

Hi Travis,

Travis Griggs schrieb am 24.05.2007 22:43:

Create a subclass of ScreenGraphicsContext. Add a lazy created instance

variable for the cairo context. Send carioContext to self to get it. 

Instances of ScreenGraphicsContext are created every time something has

to be drawn on the screen. If a Cairo context is created for each one of

them, and released only upon finalization, Cairo will quickly fail with

out of memory errors. At least that's what I observed with the Cairo DLL

coming with GTK+ for Windows. To avoid this problem, the Cairo context

should be cached at the Window level, or one has to find a way to

reliably release it when drawing is done. The obvious place where the

problem appears is during scrolling. See

ScrollWrapper>>update:with:from: - a new GraphicsContext is allocated

for every single movement. Quickly scrolling a Cairo based component

back and forth creates Cairo contexts faster than finalization releases

them.

Andre Schnoor recently suggested to cache the ScreenGraphicsContext to

speed up graphics output on MacOS X. I think this would be a must when

using Cairo in the way you suggest.

In

this way, it uses all of the original implementation, and you can

begin to override methods on a case by case basis to do it with Cairo.

Would it be necessary to use cairo_surface_mark_dirty before and

cairo_surface_flush after ever Cairo based output on a surface when

mixing Cairo operations with non-Cairo ones? It might make the

implementation cumbersome. What would that mean for performance?

You're never going to try and replace the text stuff. The other VW

text objects are just too intertwined.

I agree that replacing text output in a transparent way is almost

impossible when backward compatibility has to be preserved. Maybe it

would be a bit simpler to migrate a complete image to Cairo output - in

that case, one could replace ComposedText and TextMeasurer with all of

its subclasses by something else. But this would mean that not only

ScreenGraphicsContext, but also HostPrinterGraphicsContext and

PostscriptGraphicsContext have to be Cairo based. That would be more

than just a weekend's work...