Merge lp:~compiz-team/compiz/compiz.fix_1016364 into lp:compiz/0.9.8
Status: | Rejected |
---|---|
Rejected by: | Sam Spilsbury |
Proposed branch: | lp:~compiz-team/compiz/compiz.fix_1016364 |
Merge into: | lp:compiz/0.9.8 |
Diff against target: |
170 lines (+47/-26) 5 files modified
plugins/opengl/include/opengl/opengl.h (+1/-1) plugins/opengl/include/opengl/texture.h (+5/-0) plugins/opengl/src/privatetexture.h (+1/-0) plugins/opengl/src/screen.cpp (+7/-9) plugins/opengl/src/texture.cpp (+33/-16) |
To merge this branch: | bzr merge lp:~compiz-team/compiz/compiz.fix_1016364 |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Sam Spilsbury | Needs Resubmitting | ||
Daniel van Vugt | Needs Fixing | ||
Review via email: mp+111539@code.launchpad.net |
Commit message
Fix broken mipmap support. Mipmap support was broken in the following ways:
1. glGenerateMipmapEXT is called multiple times for tfp textures
2. glGenerateMipmapEXT is called after glTexParameteri with GL_LINEAR_
3. We check for GL::fbo support before actually setting it from the extension lookup after glXCreateContext is called. As such, when we lookup an optimal pixmap fbconfig, we never find one that supports mipmaps, and it is merely "luck of the draw" as to whether or not we actually get one that does
4. We generate mipmaps for tfp textures even though mipmaps aren't actually supported on the config target, because we don't check priv->mipmapSupport
This generally results in white windows when mipmapping is enabled. See (LP: #1016364)
As such the following measures were implemented:
1. Virtual method to generate a mipmap, different for tfp textures as
mipmap generation has to happen on damage there
2. Always generate mipmaps before setting texture filter
3. Do not check for GL::fbo support when checking fbconfigs for mimap support
4. Use GLTexture::mipmap () to determine if we actually can do mipmaps - this
checks if the fbconfig supports mipmaps, that the texture is not
an NV_TEXTURE_
support
Description of the change
== Problem ==
1. glGenerateMipmapEXT is called multiple times for tfp textures
2. glGenerateMipmapEXT is called after glTexParameteri with GL_LINEAR_
3. We check for GL::fbo support before actually setting it from the extension lookup after glXCreateContext is called. As such, when we lookup an optimal pixmap fbconfig, we never find one that supports mipmaps, and it is merely "luck of the draw" as to whether or not we actually get one that does
4. We generate mipmaps for tfp textures even though mipmaps aren't actually supported on the config target, because we don't check priv->mipmapSupport
This generally results in white windows when mipmapping is enabled. See (LP: #1016364)
== Solution ==
1. Virtual method to generate a mipmap, different for tfp textures as
mipmap generation has to happen on damage there
2. Always generate mipmaps before setting texture filter
3. Do not check for GL::fbo support when checking fbconfigs for mimap support
4. Use GLTexture::mipmap () to determine if we actually can do mipmaps - this
checks if the fbconfig supports mipmaps, that the texture is not
an NV_TEXTURE_
support
== Test ==
None yet, will add autotests when appropriate to do so (eg, after this fix lands or shortly after, since its a higher priority than normal).
Can be verified at least by turning on mipmap support and observing that scaled down windows don't go white.
Unmerged revisions
- 3257. By Sam Spilsbury
-
Fix broken mipmap support. Mipmap support was broken in the following ways:
1. glGenerateMipmapEXT is called multiple times for tfp textures
2. glGenerateMipmapEXT is called after glTexParameteri with GL_LINEAR_MIPMAP_ LINEAR as the filter mode, and sometimes not called at all, which is undefined
3. We check for GL::fbo support before actually setting it from the extension lookup after glXCreateContext is called. As such, when we lookup an optimal pixmap fbconfig, we never find one that supports mipmaps, and it is merely "luck of the draw" as to whether or not we actually get one that does
4. We generate mipmaps for tfp textures even though mipmaps aren't actually supported on the config target, because we don't check priv->mipmapSupportThis generally results in white windows when mipmapping is enabled. See (LP: #1006216)
As such the following measures were implemented:
1. Virtual method to generate a mipmap, different for tfp textures as
mipmap generation has to happen on damage there
2. Always generate mipmaps before setting texture filter
3. Do not check for GL::fbo support when checking fbconfigs for mimap support
4. Use GLTexture::mipmap () to determine if we actually can do mipmaps - this
checks if the fbconfig supports mipmaps, that the texture is not
an NV_TEXTURE_RECTANGLE_ EXT, checks for fbo support and NPOT texture
support(LP: #1016364)
Corrected bug IDs.