Executor 2.0/executorv2.0.iso/pc/linux/extra/docs/maillist/text/archive.95/text1558.txt

Text File | 1996-04-02 | 1.8 KB | 40 lines

>>>>> "Elan" == Elan Feingold <[e-mail]> 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.