[cairo] Write ups on Microsoft Avalon

[Owen Taylor]

On Mon, 2004-05-17 at 16:44, Carl Worth wrote:
> On Mon, 17 May 2004 15:20:38 -0400, Owen Taylor wrote:
> >  - The granularity of this is too big to be useful for current
> >    screen resolutions ... you don't want things to suddenly
> >    double at 144 dpi. These means that there still isn't going
> >    to be a fixed relationship between say, font size, and
> >    Cairo units.
> 
> Ah, but we're using 1/96. So things don't change until 192 dpi. So, you
> have a little more room to breathe at least. Whether that actually
> changes anything for you or not...

As Bill suggests, I was thinking 96 * 1.5 not 72 * 2.

> >  - Apps care about pixel sizes (window size is in pixels,
> >    they may have images in pixel sizes, etc.) Having to
> >    query and translate is very painful.
> 
> I'd prefer that new applications care less about pixel sizes. It would
> be nice if displays had pixels small enough to be ignored completely,
> (in which case cairo could be truly resolution independent), but that's
> just not the case. The scheme in cairo is intended to be a compromise.
> 
> If application/toolkit authors have to think a bit about how to work in
> non-pixel space, then I think cairo will have had a positive impact.

I think the elements of working in non-pixel space are already 
pretty well known:

 - Do automatic layout of controls
 - Specify spacing/paddding/etc in font-relative units not pixels

Beyond that, I consider making application authors have to worry about
multiple coordinate systems a loss, not a win. Adding the ability to
set up a different transformation matrix is not a bad thing ... 
it is useful in a lot of cases. But putting it in the critical path
of things you need to learn about before you can get some pixels
on the screen is making life unpleasant for the user.

> You're in the position to try to transition a large number of existing
> applications, so the analysis may be different.
> 
> >  - People are going to assume that 1-unit == 1 pixel in their apps,
> >    because virtually all displays are still < 144 dpi.
> 
> Shame on them.

The average developer is, from my experience, trying to figure out their
C syntax errors and where they need to free memory. They also have an
application that actually does something interesting that they are
trying to get working. I think they can be excused if when they 
get things to draw in the right place they don't notice that they 
are forgetting to multiply by 1.

> Print output is intended to be a primary output device in cairo. And a 1
> unit, 1 pixel assumption there is almost guaranteed to be wrong.

The places where people are going to get pixel coordinates are from
event coordinates, from the size allocated to controls, and so forth.
This is typically screen specific. I don't think there is much danger
of assuming 1 unit == 1 pixel when targeting a printing device...

But I do think that you want to keep the same conceptual simplicity
for printing ... applications should be able to work without having
to change the matrix.

(Say, you set up 1 unit == 1 postscript point, and the getPageDimensions
call returns the page size in postscript points.)

> >  - Also, say I want to draw a "hairline" - a pixel aligned very thin
> >    line.. how do I do it in that scheme? Do I make the line=20
> >    0.5 pixel with an offset of 0.25, 1 pixel with an offset of 0.5?
> 
> Do you really want to address a single row of pixels? You can always set
> up an identity matrix for that case.

The question is whether at screen resolutions people are going to be 
happy with 2 and 4 pixel lines or whether they really want 1 and 3
pixel lines. Most of the lines on my ~125dpi display are 1 pixel
and I think should be 1 pixel.

> >  - DPI is a wrong measure for screens as has been discussed here
> >    in the past (projectors, handhelds, etc.)
> 
> I'll gladly listen to proposals for alternate metrics. Something along
> the lines of pixels per radian in field of view?

The most relevant metric is what is the readable font size for the
user. I think that the right user interface is to make it very easy
for the user to zoom the primary UI font size in and out and then
base other sizes on that. But I don't think that should affect the
transformation matrix ... the font size, icon size, etc, has to change
continuously; adding on a transformation matrix that jumps discretely at
some point will just add confusion.

> > For these reasons, my current inclination for GTK+/Cairo integration
> > is to deviate and fix a 1-pixel : 1-unit default matrix.
> 
> That's the same matrix you get with the current scheme and today's
> display devices anyway. So naive users will do the same thing in either
> case.

If I can make what naive users assume right rather than wrong, I think
that's a worthwhile.

Regards,
						Owen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/cairo/attachments/20040518/347b2b5d/attachment.pgp