Image mesh drawing

Dear all:
I want to drew a screen image mesh (by subdividing a screen quad into a mesh with resolution w*h). When I draw a tiny small triangle (for example, at one corner of the screen), I expect three pixels would appear, but only one pixel would be rasterized. I would like to know the reason.(depth culling and back face culling are turned off).
In other words, I generate a triangle, whose vertexes are exactly located at the center points of a pixel, another pixel on the right, and another pixel on the top in image space. I would expect three pixels would appear, but instead only one appears. I would like to know the theory of how a triangle with vertexes exactly on the sample point is rasterized.

VBO generate code:

for(int x = 0;x<rasterWidth;x++)
for(int y = 0;y<rasterHeight;y++)
{
if(x==0&&y==0)
;
else
continue; // hear we only draw one triangle, others are invalid

Vertices[PointId++] = make_float2((float)(x+0.5)/rasterWidth,(float)(y+0.5)/rasterHeight);
Vertices[PointId++] = make_float2((float)(x+1.5)/rasterWidth,(float)(y+0.5)/rasterHeight);
Vertices[PointId++] = make_float2((float)(x+1.5)/rasterWidth,(float)(y+1.5)/rasterHeight);
Vertices[PointId++] = make_float2((float)(x+0.5)/rasterWidth,(float)(y+0.5)/rasterHeight);
Vertices[PointId++] = make_float2((float)(x+1.5)/rasterWidth,(float)(y+1.5)/rasterHeight);
Vertices[PointId++] = make_float2((float)(x+0.5)/rasterWidth,(float)(y+1.5)/rasterHeight);

}
glGenBuffers(1,&VBO);
glBindBuffer(GL_ARRAY_BUFFER,VBO);
glBufferData(GL_ARRAY_BUFFER,sizeof(float2)* rasterWidth rasterHeight * 6,(GLvoid)Vertices,GL_STATIC_DRAW);
glBindBuffer(GL_ARRAY_BUFFER,0);

vertex shader:
#version 430

layout (location = 0) in vec2 position;
void main(){
gl_Position.xy = (position.xy- 0.5) * 2.0;
gl_Position.z = -0.1; //just not clip the vertex
gl_Position.w = 1;
}

pixel shader:
#version 430
layout (location = 0) out vec4 color0;
void main()
{
color0 = vec4(1,0,0,1); //only the pixel at the left bottom is ra
}
result:only the pixel at the left bottom is rasterized red.

Unless anti-aliasing or multi-sampling are enabled, rendering a triangle affects exactly those pixels whose centres lie within the triangle. If a pixel centre lies on the boundary of a triangle, the results are unpredictable, as the test ends up being decided by rounding error, which is effectively random (obviously, it’s not actually random, but the factors which affect it aren’t covered by the OpenGL specification and will vary between implementations).

However, if two triangles share a common edge, any pixel whose centre lies on that edge will be part of exactly one triangle. Rounding error means that you can’t reliably predict which triangle it will be inside, but the result will be consistent. If it’s outside of one it will be inside the other; it won’t be inside both or outside both.

If anti-aliasing or multi-sampling are enabled, rendering a triangle affects those pixels which intersect the triangle.

The details can be found in section 14 of the OpenGL 4.5 specification (they can be found in any version, but section numbers may vary between versions).

For triangles, the results are more predictable if vertices lie on pixel corners (integer window-space coordinates). That still results in many indeterminate pixels in the case where the slope of an edge is the ratio of small integers (e.g. for a triangle which is half of an axis-aligned square, every pixel on the diagonal edge is indeterminate), but it means that horizontal and vertical edges are well defined. Placing the vertices on pixel centres means that every pixel on a horizontal or vertical edge is indeterminate.

For lines, the opposite is true: the results are more predictable if vertices lie on pixel centres. In particular, rendering horizontal or vertical lines with the vertices on pixel corners makes the entire line indeterminate.

[QUOTE=GClements;1281225]Unless anti-aliasing or multi-sampling are enabled, rendering a triangle affects exactly those pixels whose centres lie within the triangle. If a pixel centre lies on the boundary of a triangle, the results are unpredictable, as the test ends up being decided by rounding error, which is effectively random (obviously, it’s not actually random, but the factors which affect it aren’t covered by the OpenGL specification and will vary between implementations).

However, if two triangles share a common edge, any pixel whose centre lies on that edge will be part of exactly one triangle. Rounding error means that you can’t reliably predict which triangle it will be inside, but the result will be consistent. If it’s outside of one it will be inside the other; it won’t be inside both or outside both.

If anti-aliasing or multi-sampling are enabled, rendering a triangle affects those pixels which intersect the triangle.

The details can be found in section 14 of the OpenGL 4.5 specification (they can be found in any version, but section numbers may vary between versions).

For triangles, the results are more predictable if vertices lie on pixel corners (integer window-space coordinates). That still results in many indeterminate pixels in the case where the slope of an edge is the ratio of small integers (e.g. for a triangle which is half of an axis-aligned square, every pixel on the diagonal edge is indeterminate), but it means that horizontal and vertical edges are well defined. Placing the vertices on pixel centres means that every pixel on a horizontal or vertical edge is indeterminate.

For lines, the opposite is true: the results are more predictable if vertices lie on pixel centres. In particular, rendering horizontal or vertical lines with the vertices on pixel corners makes the entire line indeterminate.[/QUOTE]
Thanks for your reply