Chromium Code Reviews| OLD | NEW |
|---|---|
| 1 | 1 |
| 2 /* | 2 /* |
| 3 * Copyright 2011 Google Inc. | 3 * Copyright 2011 Google Inc. |
| 4 * | 4 * |
| 5 * Use of this source code is governed by a BSD-style license that can be | 5 * Use of this source code is governed by a BSD-style license that can be |
| 6 * found in the LICENSE file. | 6 * found in the LICENSE file. |
| 7 */ | 7 */ |
| 8 | 8 |
| 9 | 9 |
| 10 | 10 |
| (...skipping 144 matching lines...) Expand 10 before | Expand all | Expand 10 after Loading... | |
| 155 #endif | 155 #endif |
| 156 | 156 |
| 157 #if !defined(GR_GL_MUST_USE_VBO) | 157 #if !defined(GR_GL_MUST_USE_VBO) |
| 158 #define GR_GL_MUST_USE_VBO 0 | 158 #define GR_GL_MUST_USE_VBO 0 |
| 159 #endif | 159 #endif |
| 160 | 160 |
| 161 #if !defined(GR_GL_USE_NEW_SHADER_SOURCE_SIGNATURE) | 161 #if !defined(GR_GL_USE_NEW_SHADER_SOURCE_SIGNATURE) |
| 162 #define GR_GL_USE_NEW_SHADER_SOURCE_SIGNATURE 0 | 162 #define GR_GL_USE_NEW_SHADER_SOURCE_SIGNATURE 0 |
| 163 #endif | 163 #endif |
| 164 | 164 |
| 165 // We now have a separate GrGLInterface function pointer entry for the IMG/EXT v ersion of | |
|
robertphillips
2013/08/23 17:25:34
setting setting -> setting
bsalomon
2013/08/23 17:28:49
will do
| |
| 166 // glRenderbufferStorageMultisampled. However, Chrome is setting setting the one we now | |
| 167 // now use for ES3 MSAA to point to the IMG/EXT function. This macro exists to m ake | |
| 168 // Skia ignore the presence of ES3 MSAA and instead use the IMG/EXT version with the | |
| 169 // old function pointer entry. It will be removed as soon as Chrome is updated t o | |
| 170 // set the new function pointer. | |
| 171 #if !defined(GR_GL_IGNORE_ES3_MSAA) | |
| 172 #define GR_GL_IGNORE_ES3_MSAA 0 | |
| 173 #endif | |
| 174 | |
| 165 /** | 175 /** |
| 166 * There is a strange bug that occurs on Macs with NVIDIA GPUs. We don't | 176 * There is a strange bug that occurs on Macs with NVIDIA GPUs. We don't |
| 167 * fully understand it. When (element) array buffers are continually | 177 * fully understand it. When (element) array buffers are continually |
| 168 * respecified using glBufferData performance can fall off of a cliff. The | 178 * respecified using glBufferData performance can fall off of a cliff. The |
| 169 * driver winds up performing many DMA mapping / unmappings and chews up ~50% of | 179 * driver winds up performing many DMA mapping / unmappings and chews up ~50% of |
| 170 * the core. However, it has been observed that occaisonally respecifiying the | 180 * the core. However, it has been observed that occaisonally respecifiying the |
| 171 * buffer using glBufferData and then writing data using glBufferSubData | 181 * buffer using glBufferData and then writing data using glBufferSubData |
| 172 * prevents the bad behavior. | 182 * prevents the bad behavior. |
| 173 * | 183 * |
| 174 * There is a lot of uncertainty around this issue. In Chrome backgrounding | 184 * There is a lot of uncertainty around this issue. In Chrome backgrounding |
| (...skipping 10 matching lines...) Expand all Loading... | |
| 185 * trick every 128 array buffer uploads. | 195 * trick every 128 array buffer uploads. |
| 186 * | 196 * |
| 187 * Hopefully we will understand this better and have a cleaner fix or get a | 197 * Hopefully we will understand this better and have a cleaner fix or get a |
| 188 * OS/driver level fix. | 198 * OS/driver level fix. |
| 189 */ | 199 */ |
| 190 #define GR_GL_MAC_BUFFER_OBJECT_PERFOMANCE_WORKAROUND \ | 200 #define GR_GL_MAC_BUFFER_OBJECT_PERFOMANCE_WORKAROUND \ |
| 191 (GR_MAC_BUILD && \ | 201 (GR_MAC_BUILD && \ |
| 192 !GR_GL_USE_BUFFER_DATA_NULL_HINT) | 202 !GR_GL_USE_BUFFER_DATA_NULL_HINT) |
| 193 | 203 |
| 194 #endif | 204 #endif |
| OLD | NEW |