| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
This should make things easier for drivers wanting to work with a
"subclass" of gl_framebuffer.
The complementary "_mesa_initialize_framebuffer" function is now
called "_mesa_initialize_window_framebuffer" for the sake of
symmetry.
Signed-off-by: Brian Paul <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
The assertion is that the correct read type to be using is the native
type of the underlying read renderbuffer. For some fallback paths, this
may be worse than GL_RGBA/GL_UNSIGNED_BYTE for reads today, but it gets
all drivers the expected GL_BGRA/GL_UNSIGNED_BYTE for ARGB8888 or
GL_BGR//GL_UNSIGNED_SHORT_5_6_5_REV for rgb565 with no work.
This fixes the intel (and other) DRI drivers to report read formats that
should hit blit PBO readpixels paths.
|
| |
|
|
|
|
|
|
| |
framebuffer.c
(cherry picked from commit 9091015a9782ad15e58540a8fd61df83ea2bfe31)
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
decrement, delete and locking.
|
| |
|
|
|
|
| |
particular renderbuffers are present
|
|
|
|
| |
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.
|