| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
We sometimes need a rendering context when deleting renderbuffers.
Pass it explicitly instead of trying to grab a current context
(which might be NULL). The next patch will make use of this.
Note: this is a candidate for the stable branches.
Reviewed-by: Jose Fonseca <[email protected]>
|
| |
|
|
|
|
| |
We're now using the functions that live in swrast.
Reviewed-by: Eric Anholt <[email protected]>
|
| |
|
|
|
|
|
| |
The functions to allocate software color, depth, accum, etc buffers aren't
called from anywhere else.
Reviewed-by: Eric Anholt <[email protected]>
|
| |
|
|
|
|
|
|
| |
This was only used by the xlib driver to add an alpha channel to the
front/window color buffer. This was no longer going to work well with
the move to direct mapping of renderbuffers.
Reviewed-by: Eric Anholt <[email protected]>
|
| |
|
|
|
|
|
|
|
|
| |
Mesa core's is generic for things like osmesa.
For swrast_dri.so, we have to do Y flipping. The front-buffer path
isn't actually tested, though, because both before and after it fails
with a BadMatch in XGetImage.
Reviewed-by: Brian Paul <[email protected]>
|
| |
|
|
|
|
|
| |
INLINE is still seen in some files (some generated files, etc) but this
is a good start.
Acked-by: Kenneth Graunke <[email protected]>
|
| | |
|
| |
|
|
| |
Reviewed-by: Brian Paul <[email protected]>
|
| |
|
|
| |
Reviewed-by: Brian Paul <[email protected]>
|
| |
|
|
|
|
| |
Include mtypes.h for gl_buffer_index symbol.
This is a follow-up to commit 65da73c5f87bc39c76ba9e45945da95fff354308.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
After all the recent color-index visual support removal,
_mesa_add_color_index_renderbuffers is no longer used anywhere.
Signed-off-by: Ian Romanick <[email protected]>
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Nicolai writes:
When the pixmap pixel format has no alpha channel, the x11 driver
(software rendering) adds a wrapped alpha channel on request.
During SwapBuffers, this alpha channel is not copied from back to
front, which means that the front buffer doesn't really contain the
contents that the back buffer previously contained.
A subsequent glReadPixels from the front buffer will return an
incorrect result. The following patch attempts to fix this.
|
| |
|
|
|
|
|
| |
Use _mesa_reference_framebuffer() and _mesa_unreference_framebuffer() functions
to be sure reference counting is done correctly. Additional assertions are
done too. Note _mesa_dereference_framebuffer() renamed to "unreference" as
that's more accurate.
|
| |
|
|
|
| |
Added _mesa_dereference_renderbuffer() to encapsulate renderbuffer
reference count decrement, delete, locking.
|
| | |
|
| | |
|
| |
|
|
| |
Update some comments, code, etc.
|
|
|
Main driver impacts:
- new code for creating the Mesa GLframebuffer
- new span/pixel read/write code
Some drivers not yet updated/tested.
|
