On Thu, 6 Dec 2001, Lewin A.R.W. Edwards wrote:
> Hi Mark,
>
> > > We don't use the chipset rotation features. We keep the chipset believing
> > > it is working with (say) a 640x480 display, and the application layer
> > > believes it is working with a 480x640 display. The GDI layer does the
> > > rotation and translation of coordinates, maintaining use of hardware
> > > acceleration features where available (including hardware cursor...).
> >
> > That's because rotating X-rendering correctly is an ominous task.
> >X11 is a pixel-perfect specification. Just rotating the coordinates
> >on lines and polygons won't render them correctly. None of this
>
> Can you explain this further? At the moment I have a system - running X
> actually - where I am emulating my older proprietary systems inside a frame
> buffer. Eventually I would have gotten around to looking at X's rotation
> possibilities anyway; I knew of it theoretically but have never tried to
> use it.
>
> Bear in mind that I know nothing about the internals of how things are
> represented in X. But the first part I don't understand is why rotating the
> coordinates of lines and polygons will not yield a correct result. A
> rectangle 100x25 pixels in size, 100 pixels right of the origin and 50
> pixels below it, is described completely regardless of the geometry of the
> screen (assuming a Windows-convention origin, not an OS/2 PM-convention
> origin, of course :)
The biasing rules for lines and polygon edges are octant-specific.
You won't get the same results for the same reason that Bresenham's
algorithm won't draw a line from point A to B on the same points as
a line from B to A without some octant-specific fixups.
>
> My understanding of how it would work is that it would abstract the
> rotation at the same level I abstract it - i.e. the client app would be
> unaware of the rotation and would only be aware of the fact that the
> screen's pixel dimensions are a bit strange. As far as the client is
> concerned there is no rotation; the dimensions and sign-directions of the
> display surface exactly match that of the physical display output. The
> client renders at (say) 480x640; the user sees 480x640. The fact that there
> is a rotation operation is purely a hardware issue related to the order in
> which the display controller DMAs pixels out of RAM; it's just an issue of
> internal frame storage.
That's the way it works now, except the copies from the shadow
buffer to the real framebuffer are done with the CPU due to the general
lack of user-space DMA capabilties on the operating systems we support.
>
> Where am I going wrong in my understanding? And is this a question of
> rigorous standards compliance, or one of basic functional failure that will
> be obvious to the user? (Oh, and in case this is not clear: I'm not at all
> being argumentative or implying that any XFree code is bad, I'm just trying
> to see why it is impossible to implement an efficiency improvement).
Perhaps I misunderstand what you were asking about. You've
described the way it currently works. I described why doing without
a shadow buffer has not been done.
Mark.
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
