[PATCH wayland 1/2] protocol: replace pointer.attach with pointer.set_cursor

William Swanson swansontec at gmail.com
Wed Jun 20 10:15:21 PDT 2012


On Tue, Jun 19, 2012 at 12:40 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> IMO a first step in clarifying everything is defining how we think
> about pixels: are they squares of width and height 1.0, or do we think
> of them as points, with unit spacing.

The best way to deal with this, I have found, is to treat all
coordinates as distances from the edge. Imagine the image as a sheet
of graph paper, and use a ruler to measure the distance from the edge
of the sheet. An x coorinate of 0 would be the left edge of the first
pixel, and an x coordinate of 1 would be the right edge of that same
pixel. An x coordinate of 1.25 would mark a point 1/4 of the way into
the 2nd pixel, traveling from the edge. A line beginning at x=2 and
ending at x=6 would be exactly 4 pixels long:

| | |*|*|*|*| |
0 1 2 3 4 5 6 7

The beauty of this system is that distances always add up correctly;
it basically eliminates off-by-one errors. More importantly, this is
the system everyone already uses in the analog real-world where there
are no pixels. When you really think about it, the rasterizer's pixel
grid is almost like an implementation detail.

> Then, we need to define the
> sub-pixel coordinates:
> - how to convert from a real coordinate into the nearest pixel (index)?

Thinking about pixels as numbered squares is wrong, but obviously
there are older API's that do this. In the system above, all
coordinates from 1.0 - 2.0 describe points inside then 2nd pixel
(index 1). Thus, the floor() operation will correctly convert any real
coordinate to an index.

> - does a real coordinate with a 0 fraction hit the pixel at the center
> or at the leading edge of entering the pixel's area?

It would be the edge.

-William


More information about the wayland-devel mailing list