diff options
| -rw-r--r-- | docs/application-issues.html | 10 | ||||
| -rw-r--r-- | docs/codingstyle.html | 14 | ||||
| -rw-r--r-- | docs/debugging.html | 12 | ||||
| -rw-r--r-- | docs/devinfo.html | 24 | ||||
| -rw-r--r-- | docs/faq.html | 29 | ||||
| -rw-r--r-- | docs/helpwanted.html | 7 |
6 files changed, 50 insertions, 46 deletions
diff --git a/docs/application-issues.html b/docs/application-issues.html index 740713798eb..c4ac9d9b31d 100644 --- a/docs/application-issues.html +++ b/docs/application-issues.html @@ -48,16 +48,16 @@ start-up because of an extension string buffer-overflow problem. <p> The problem is a modern OpenGL driver will return a very long string -for the glGetString(GL_EXTENSIONS) query and if the application +for the <code>glGetString(GL_EXTENSIONS)</code> query and if the application naively copies the string into a fixed-size buffer it can overflow the buffer and crash the application. </p> <p> -The work-around is to set the MESA_EXTENSION_MAX_YEAR environment variable -to the approximate release year of the game. -This will cause the glGetString(GL_EXTENSIONS) query to only report extensions -older than the given year. +The work-around is to set the <code>MESA_EXTENSION_MAX_YEAR</code> +environment variable to the approximate release year of the game. +This will cause the <code>glGetString(GL_EXTENSIONS)</code> query to only report +extensions older than the given year. </p> <p> diff --git a/docs/codingstyle.html b/docs/codingstyle.html index e8832e7967c..aa1e09cba32 100644 --- a/docs/codingstyle.html +++ b/docs/codingstyle.html @@ -120,10 +120,11 @@ the opening brace goes on the next line by itself (see above.) _mesa_foo_bar() - an internal non-static Mesa function </pre> -<li>Constants, macros and enum names are ALL_UPPERCASE, with _ between -words. -<li>Mesa usually uses camel case for local variables (Ex: "localVarname") -while gallium typically uses underscores (Ex: "local_var_name"). +<li>Constants, macros and enum names are <code>ALL_UPPERCASE</code>, with _ +between words. +<li>Mesa usually uses camel case for local variables (Ex: +<code>localVarname</code>) while gallium typically uses underscores (Ex: +<code>local_var_name</code>). <li>Global variables are almost never used because Mesa should be thread-safe. <li>Booleans. Places that are not directly visible to the GL API @@ -131,8 +132,9 @@ should prefer the use of <code>bool</code>, <code>true</code>, and <code>false</code> over <code>GLboolean</code>, <code>GL_TRUE</code>, and <code>GL_FALSE</code>. In C code, this may mean that <code>#include <stdbool.h></code> needs to be added. The -<code>try_emit_</code>* methods in src/mesa/program/ir_to_mesa.cpp and -src/mesa/state_tracker/st_glsl_to_tgsi.cpp can serve as examples. +<code>try_emit_</code>* methods in <code>src/mesa/program/ir_to_mesa.cpp</code> +and <code>src/mesa/state_tracker/st_glsl_to_tgsi.cpp</code> can serve as +examples. </ul> diff --git a/docs/debugging.html b/docs/debugging.html index bd21e5cab4d..c6f69fe162d 100644 --- a/docs/debugging.html +++ b/docs/debugging.html @@ -20,9 +20,9 @@ Normally Mesa (and OpenGL) records but does not notify the user of errors. It is up to the application to call <code>glGetError</code> to check for errors. Mesa supports an - environment variable, MESA_DEBUG, to help with debugging. If - MESA_DEBUG is defined, a message will be printed to stdout whenever - an error occurs. + environment variable, <code>MESA_DEBUG</code>, to help with debugging. If + <code>MESA_DEBUG</code> is defined, a message will be printed to stdout + whenever an error occurs. </p> <p> @@ -30,12 +30,12 @@ (<code>--buildtype debug</code> for meson, <code>build=debug</code> for scons). </p> <p> - In your debugger you can set a breakpoint in _mesa_error() to trap Mesa - errors. + In your debugger you can set a breakpoint in <code>_mesa_error()</code> to trap + Mesa errors. </p> <p> There is a display list printing/debugging facility. See the end of - src/dlist.c for details. + <code>src/dlist.c</code> for details. </p> </div> diff --git a/docs/devinfo.html b/docs/devinfo.html index 07d154bb5e5..a636e37ad35 100644 --- a/docs/devinfo.html +++ b/docs/devinfo.html @@ -29,8 +29,8 @@ To add a new GL extension to Mesa you have to do at least the following. <ul> <li> - If glext.h doesn't define the extension, edit include/GL/gl.h and add - code like this: + If <code>glext.h</code> doesn't define the extension, edit + <code>include/GL/gl.h</code> and add code like this: <pre> #ifndef GL_EXT_the_extension_name #define GL_EXT_the_extension_name 1 @@ -41,18 +41,18 @@ To add a new GL extension to Mesa you have to do at least the following. </pre> </li> <li> - In the src/mapi/glapi/gen/ directory, add the new extension functions and - enums to the gl_API.xml file. + In the <code>src/mapi/glapi/gen/</code> directory, add the new extension + functions and enums to the <code>gl_API.xml</code> file. Then, a bunch of source files must be regenerated by executing the corresponding Python scripts. </li> <li> - Add a new entry to the <code>gl_extensions</code> struct in mtypes.h - if the extension requires driver capabilities not already exposed by - another extension. + Add a new entry to the <code>gl_extensions</code> struct in + <code>mtypes.h</code> if the extension requires driver capabilities not + already exposed by another extension. </li> <li> - Add a new entry to the src/mesa/main/extensions_table.h file. + Add a new entry to the <code>src/mesa/main/extensions_table.h</code> file. </li> <li> From this point, the best way to proceed is to find another extension, @@ -65,13 +65,13 @@ To add a new GL extension to Mesa you have to do at least the following. </li> <li> To determine if the new extension is active in the current context, - use the auto-generated _mesa_has_##name_str() function defined in - src/mesa/main/extensions.h. + use the auto-generated <code>_mesa_has_##name_str()</code> function + defined in <code>src/mesa/main/extensions.h</code>. </li> <li> - The dispatch tests check_table.cpp and dispatch_sanity.cpp + The dispatch tests check_table.cpp and <code>dispatch_sanity.cpp</code> should be updated with details about the new extensions functions. These - tests are run using 'meson test' + tests are run using <code>meson test</code>. </li> </ul> diff --git a/docs/faq.html b/docs/faq.html index a85c69c7151..183bd4e31d9 100644 --- a/docs/faq.html +++ b/docs/faq.html @@ -291,34 +291,34 @@ If you need a deeper you can modify the parameters to <h3>3.3 Why Isn't depth buffering working at all?</h3> <p> -Be sure you're requesting a depth buffered-visual. If you set the MESA_DEBUG -environment variable it will warn you about trying to enable depth testing -when you don't have a depth buffer. +Be sure you're requesting a depth buffered-visual. If you set the +<code>MESA_DEBUG</code> environment variable it will warn you about trying +to enable depth testing when you don't have a depth buffer. </p> <p>Specifically, make sure <code>glutInitDisplayMode</code> is being called with <code>GLUT_DEPTH</code> or <code>glXChooseVisual</code> is being -called with a non-zero value for GLX_DEPTH_SIZE. +called with a non-zero value for <code>GLX_DEPTH_SIZE</code>. </p> <p>This discussion applies to stencil buffers, accumulation buffers and alpha channels too. </p> -<h3>3.4 Why does glGetString() always return NULL?</h3> +<h3>3.4 Why does <code>glGetString()</code> always return <code>NULL</code>?</h3> <p> Be sure you have an active/current OpenGL rendering context before -calling glGetString. +calling <code>glGetString</code>. </p> -<h3>3.5 GL_POINTS and GL_LINES don't touch the right pixels</h3> +<h3>3.5 <code>GL_POINTS</code> and <code>GL_LINES</code> don't touch the +right pixels</h3> <p> -If you're trying to draw a filled region by using GL_POINTS or GL_LINES -and seeing holes or gaps it's because of a float-to-int rounding problem. -But this is not a bug. -See Appendix H of the OpenGL Programming Guide - "OpenGL Correctness Tips". -Basically, applying a translation of (0.375, 0.375, 0.0) to your coordinates -will fix the problem. +If you're trying to draw a filled region by using <code>GL_POINTS</code> or +<code>GL_LINES</code> and seeing holes or gaps it's because of a float-to-int +rounding problem. But this is not a bug. See Appendix H of the OpenGL +Programming Guide - "OpenGL Correctness Tips". Basically, applying a +translation of (0.375, 0.375, 0.0) to your coordinates will fix the problem. </p> <br> @@ -365,7 +365,8 @@ the archives) is a good way to get information. </p> -<h3>4.3 Why isn't GL_EXT_texture_compression_s3tc implemented in Mesa?</h3> +<h3>4.3 Why isn't <code>GL_EXT_texture_compression_s3tc</code> implemented in +Mesa?</h3> <p> Oh but it is! Prior to 2nd October 2017, the Mesa project did not include s3tc support due to intellectual property (IP) and/or patent issues around the s3tc diff --git a/docs/helpwanted.html b/docs/helpwanted.html index 44255902a72..5e0684bd6c0 100644 --- a/docs/helpwanted.html +++ b/docs/helpwanted.html @@ -48,7 +48,8 @@ You can find some further To-do lists here: </p> <ul> <li><a href="https://gitlab.freedesktop.org/mesa/mesa/blob/master/docs/features.txt"> - <b>features.txt</b></a> - Status of OpenGL 3.x / 4.x features in Mesa.</li> + <code>features.txt</code></a> - Status of OpenGL 3.x / 4.x features in + Mesa.</li> </ul> <p> @@ -56,9 +57,9 @@ You can find some further To-do lists here: </p> <ul> <li><a href="https://dri.freedesktop.org/wiki/R600ToDo"> - <b>r600g</b></a> - Driver for ATI/AMD R600 - Northern Island.</li> + <code>r600g</code></a> - Driver for ATI/AMD R600 - Northern Island.</li> <li><a href="https://dri.freedesktop.org/wiki/R300ToDo"> - <b>r300g</b></a> - Driver for ATI R300 - R500.</li> + <code>r300g</code></a> - Driver for ATI R300 - R500.</li> </ul> <p> |