i have been looking at the clipping issues with the
savage driver. this centers around the use of the scissor box. currently the
savage driver does not use the scissor box.
next are my observations. i am new to this so
please feel free to comment.
i noticed that in the savgeDDRenderStart function
the savageDDScissor function is called with the coordinates of the first
clip rect in the driDrawable. this effectively wiped out the value that was
given by any previous calls to glScissor, hence no scissoring. i commented this
command out and scissoring started working correctly well almost. it worked for
the first call but did not work for subsequent calls. i found that subsequent
calls were being held up in emitHWStateLocked. if the upload clip rects flag is
not set and the flags for uploading ctx, textures or buffers are set then the
registers are emitted and the scissor rect gets set. these conditions were not
being met on the second call so the second attempt to set the scissor rect
failed. to the conditions mentioned above, i added a check for scissor changed
and now everything works. this is not a good solution, just a proof of
all the other drivers i have looked at don't seem
to use the scissor rect to do general clipping. if i'm following the code,
before they draw something they take the context clip rects and copy them into
the sarea clip rects then execute the draw command. when draw command is
executed the clip rects in the sarea are uploaded to the video card by the
kernel driver. the savage kernel driver does not support uploading clip rects
this is why they use the scissor rect.
a proper implementation whether in the kernel
driver or elsewhere would involve uploading the clip rects to the video card. i
don't see any information on how to do this within savage driver code. i can't
imagine that everyother video card has this capability and the savage doesn't.
if someone knows of a source code sample please let me know.
as things are now, i don't see any reason to
intersect the scissor rect with the sarea clip rects. we draw to the back
buffer, therefore we don't need to clip to overlapping windows. the scissor rect
is intersected with the main draw region (window bounds) before it is uploaded
to the video card, so we don't have to worry about drawing outside the draw
region. of course this assumes that you only draw to the back buffer. as soon as
you start drawing to the front buffer your gonna have problems.
the swap buffer function does handle clipping
properly. it uses the serea clip rects to define regions to blit to the front
buffer. so no overlapping windows will be affected.
now for a question. i don't know if it is in the
opengl spec, but i would like to have the scissor rect taken into account during
swap buffers. this is simple to implement. i think the i810 driver does
something similar. this would provide a performance enhancement as the user
would be able to control the amount of data blit'ed from the back buffer to the
front buffer. most opengl optimization documentation mentions using the scissor
rect to minimize drawing or clearing of unwanted regions, this seems to play
directly into that strategy.