RE: [Mesa3d-dev] Buffer sizes for swrast, confusion

[Matt S. <ma...@ki...>]

> -----Original Message-----
> From: mes...@li...
> [mailto:mes...@li...]On Behalf Of Brian Paul
> Sent: Tuesday, June 03, 2003 6:06 PM
> To: Philip Brown
> Cc: mes...@li...
> Subject: Re: [Mesa3d-dev] Buffer sizes for swrast, confusion
> 
> 
> Philip Brown wrote:

> > Would GetBufferSize()_also be a good place to doublecheck window location?
> > I'm thinking it should be
> 
> If Matt has to deal with window position changes too, he may have to 
> do more checking beyond window size changes.

I don't.

We render relative to window top left, or screen top left, but never to
both. We have a virtualisation which means while the current Screen has
only one BitMap, it can have a hundred RastPorts which contain pointers
to top-left pixels inside that BitMap, strides to get to the next virtual
row, and that sort of thing.

That's software for windows anyway. Since we render to the virtual thing,
and not to the hardware thing, it's better that way. For software on
the Screen, we poke directly to the video card resident BitMap, but
since it's impossible to move or resize a screen without Closing it
first, we never have to bother with anything so complex.

For hardware in windows, we allocate a clone bitmap of the current
Window's (which references a RastPort which is virtualising the
Screen BitMap), but for the required size. We render hardware
polygons etc. to that bitmap, and on SwapBuffers(), Flush() or
whatever, we blit it to the Screen BitMap in the right position.

Doing hardware direct to the Screen is similar, but we allocate
ScreenBuffers, which means we can actually do a hardware page
flip instead of blitting.

So full screen hardware is fastest and more close to hardware,
in a window or with sofware, we actually render out to temporary
bitmaps and arrays instead.

Not technically brilliant, but it works pretty well :)

-- 
Matt Sealey <ma...@ki...>