VW graphical look [Was: Re: MacOS X]

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

The primitives you talk about are pretty much 1:1 with their C equivalents. So it's not like we're actually calling "less low-level" stuff just because the VM implements it. We could move all of the current GDI code in the VM up in to the image. What would it get us? Not much.

We could push all of the modern GDI primitives down in to the VM and map them back up in to the image. Would that be better than putting the GDI primitives in the image in the first place? not really, no. In fact, it then ties our hands the way that the current VM based GDI primitives do. It adds another layer of "surprise" when it comes to maintaining them and providing forward compatibility.

Take the MacOSX Aqua VM for example. The quartz platform, like the WPF and Cairo platform, do graphics by specifying positions between points, not on points. This is an incredibly important detail - it's a fundamental graphics shift that happened a while back (and Microsoft only just caught up). It makes all of the graphics primitives that currently exist incompatible. Instead of drawing a line from 0@0@ to: 10@0, you actually draw a line of 1 thinkness between x: -0.5..0.5 to 9.5..10.5. That's in important distinction because if you want to fill an area, you must understand that you're not drawing /on/ pixels, you're drawing /between/ pixels.

The MacOSX VM team has done an amazing job trying to fake pixel drawing on this kind of platform. Poor guys!.. the truth is that we should have dropped found a way to drop on-pixel for between-pixel 10 years ago - but doing it cross platform back then would have been very hard, especially on the windows platform.

Today, however, we can pick up a library called Cairo. Contrary to the way you put it above - Cairo's graphics primitives are far less primitive than the primitives you get in GDI. First of all, they work between pixels, which is a huge bonus. They work across platform and finally, they describe higher level drawing constructs. For example - gradient blends, rotations, skews, so on and so forth.

So, your question was - do we (or in this case I) want to use "Cairo low-level primitives" .. heck yeah. It gives me so much drawing power. Much more than I get with GDI or GDI+. And back to your second question, wouldn't it be better to improve the VM GDI primitives? I hope my above diatribe has convinced you that that is undesirable and unrealistic.

I wasn't involved, but several people tried to do this and found significant issues in doing this. Not the least of which is the way the coordinate system is completely different.

I agree. Dropping back to a lower level (GDI) is a bad idea.

VW classes are getting parallel Cairo classes, e.g. ComposedText (sort of)

maps to (Text)Layout. Similarly VW methods like displayOn:, which the

whole graphics system depends on, are being written instead as

renderOn:.

This was a side effect of a primitive implementation. Now Travis's library can let you call:

aGraphicsContext cairoContext

That means that you can pick and choose which displayOn:'s you want to upgrade to draw with Cairo. It also means there's no need for a parallel hierarchy of renderOn: methods. The parallel classes that represents /similar/ concepts. Some of those may not need to exist - most of them are not actually used. For example, when you want to create paths, you do use regular Rectangles. Many of the existing classes could be better utilitised - it's still early days there. I'd consider this bit of the Cairo implementation a Work-In-Progress. Job #1 is to replicate the Cairo interface as honestly as possible. Job #2 is to make it convenient in Smalltalk.

So we have to create a new set of objects, and then call a

new set of methods. That basically means a rewrite from scratch, unless

something is done to help.

Right. Writing from scratch is exactly what you will need to do if you want to draw using Cairo. There's no two ways about tihs. It's like converting from ObjectLens to Glorp - the concept shift is massive yet subtly similar. On the whole it's "mapping to a database" but the approach is wildly different and more powerful.

Here it's the same story, it's all about "drawing to the screen". Except how they do it is wildly different. With GDI, you draw pixels straight to a surface - /now/. With Cairo, you describe a path, a transform, what you want to do, then apply it. That's like saying GDI has a pen with a colour, except then add on all those other operations before you actually get around to doing something.

So may be down the road it'll be possible to simplify some of the more common actions you take, but the world when approached the Cairo, Quartz or WPF way is completely different.

With the #cairoContext approach though, we can share the graphics display between GDI and Cairo drawing techniques. That's a huge boon and it means "rewrite from scratch" is an incremental thing, when and/or if it makes sense to do it for a particular widget.

Cheers,
Michael

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

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: