[Prev][Next][Index][Thread]
Re: Executor for Linux with svgalib support.
>>>>> "Elan" == Elan Feingold <feingold@zko.dec.com> writes:
Elan> Doesn't the X server already take advantage of hardware
Elan> acceleration, which would make executor fast under X for
Elan> "rect fills and stuff" as well? I would assume that the
Elan> main advantage of running executor under SVGAlib would be
Elan> that executor could draw directly to the screen, as opposed
Elan> to using shared memory under X, which essentially takes
Elan> twice as long (program to buffer, buffer to screen). But I
Elan> could be mistaken :)
You're right that the big win is comes from drawing directly to the
screen. However, SVGALIB saves even more work than you might think.
Under X windows, Executor maintains its own internal bitmap
corresponding to the screen. Pieces of that bitmap are periodically
transferred to the X screen. If an app does a rect fill, Executor
itself fills in that rectangle in its internal screen bitmap, not the
X server. [*] The important thing to note is that Executor *does*
execute our blitter code to fill that rect in the internal screen
bitmap.
Under SVGAlib, the SVGA screen *is* the frame buffer that Executor
uses. So when the Mac app tries to fill in a rectangle, we tell the
SVGA board to fill that rectangle using hardware acceleration. The
key difference here is that Executor *does not* execute its own
rectangle filling code; that would be redundant.
So under SVGAlib (with a supported SVGA board) Executor says, "yo,
SVGA board, draw this rectangle" and then goes off and does other work
while the SVGA board is drawing. Under X, Executor has to draw the
rectangle itself and also update the X screen.
-Mat
[*] In some circumstances Executor will also have the X server draw
that rectangle on the real screen "in parallel", on the assumption
that most people have accelerated X servers.
References: