Issues

Higher Priority

Lower Priority

It would be convenient to provide a version of GPU_STRING_MARKER that does formatted text.

GPU_ENABLE_STRING_MARKER should probably be a build option.

State latching currently uses a static variable when it should actually depend on the OpenGL rendering context. This is generally related to the use of static and global variables in the GPU module.

gpu_tex_parameters_t in gpu_state_latch.h does not seem to be used.

The common matrix library could be easily extended to support user matrix stacks.

Questions

Unorganized

need to have string marker use more extensions than just GREMEDY's

should move the framebuffer error strings to GPU_utility.c

pixels aspect might not work the same with raster positions if a non-identity matrix is set

Cycles cannot depend on source/blender/gpu, so it needs its own solution to configuring Core/ES/Compatibility.

Not sure how to initialize an OpenGL 3 Core Profile using EGL

Determine if cmake variable SYSTEM_GL_INCLUDE_DIR is a good name. It is probably better to go back to OPENGL_INCLUDE_DIR even if it isn't set by the find_package macro.

In intern/cycles/util/CMakeLists.txt the definition -DGLEW_STATIC is added twice. Also, does Cycles need to use GL_DEFINITIONS instead? That might break the build when ES or Core are enabled.

Macros like WIN32_LEAN_AND_MEAN and _USE_MATH_DEFINES should be placed before any include files, just in case Windows.h is included in another include file unexpectedly.

GHOST_WindowWin32.h
Clean up commented code
"The type of window context *to* create"

Need to port changes to GHOST_WindowWin32 over to other GHOST_Window implementations.

rewrite the logic in GHOST_Window::setDrawingContextType to be less convoluted

The modification to intern/ghost/intern/GHOST_SystemX11.* is untested and should probably be removed for now.

The implementation of GHOST_kWindowStateFullscreen for WIN32 needs to be completed.

Replace includes like math.c with cmath where ever you can

Clean up commented code in GHOST_WindowWin32.c

GHOST_Window objects should not do so much in their constructors, instead they should have an initialization function that gets called after their construction.

In light of experience, are the WITH_GL_* configuration variables the best names?

add comment for GHOST_IWindow::releaseNativeHandles

generalized format chooser GHOST_PixelFormat class is incomplete

rework the _chk functions like you have for your own code

The changes in GHOST's CMakeLists.txt seem to be more than just change for OpenGL. Maybe there was a mis-merge or missed revision.

change to boost_locale_wrapper can be pushed separately

has fix to _MSV_VER to _MSC_VER in creator.c been pushed?

what is the 'Artificial dependency' line in buildinfo.h.rule? Where did that come from?

DM_DRAW_OPTION_NORMALLY needs to be renamed to something like DM_DRAW_OPTION_NONE

I should be free to apply the changes to tools/GL as it is 'my' module

Need to figure out how to get code coverage without a lot of hassle

There is a lot of duplication in bgl.c due to common functions between OpenGL and OpenGL ES

Need to create a core profile bgl.c as well

changes to BKE_animsys.h and BKE_brush.h should be pushed separately

rearrangement of header files could be problematic

stipple_quarttone should be hidden

places that use glDrawArrays and similar need to be made compatible

make sure that QUAD and POLYGON emulation is only used if needed?

since GL_NONE == GL_POINTS == GL_ZERO == 0, use GL_NOOP instead as special flag relating to primitive types

double check all 'DOODLE', 'SSS', and 'XXX jwilkins'

need to rewrite the uncommon format setting functions to just be a single function accepting a data structure
also, setting format should be tied to vertex array objects on systems that support VAO

VBO and immediate mode drawing for objects should be split in preparation for deprecation of the immediate mode version

replacing QUAD_STRIP with QUADS in subsurf_ccg seems like a bad idea

The *_format_attrib_vertex function in CDerivedMesh and subsurf_ccg seem to be redundant and could probably be combined somehow (this seems generally true of the code for the 3 object rendering methods)

replacing QUAD_STRIP with TRIANGLE_STRIP makes more sense

need to add more symbols to gpu_deprecated.h

read bk/intern/linestyle.c and see if there shouldn't be more in there that is related to viewport fx

The test code in pbvh (drawing leafs in different colors) has not been tested with new immediate mode

'GPU_compatibility' will be replaced with GPU_immediate in most cases I think.

bk/intern/DerivedMesh still contains gpuEnableLighting etc., how come this still compiles?
also, it contains gpuLineWidth without enabling GPU_ASPECT_RASTER and gpuShadeModel instead of GPU_BASIC_SMOOTH...
seems all this code must be disabled by #if 0

Need to have a discussion about bli_off_t type you invented for file sizes
bk/intern/bpath.c contains a cast of filesize to int

remove use of gpuShadeModel and other old names from comments

the GLSL generator paths have not been tested much at all

if the immediate mode is converted to use VAO then GPU_buffer should be able to use the same code if it is done right

in contexts that do not use immediate mode, there will need to be custom commit functions (e.g. gpu_color_from_mask_quad and gpu_color_from_mask_set)

alpha testing isn't supported in the basic shader yet, but I think this is only used by the game engine(wishful thinking?)

gpuBindTexture is used to capture the currently bound texture so it can be queried, but it is not really known if this is needed anywhere

The GPU_ASPECT_PIXELS aspect carefully keeps track of non-default state, but the other aspects aren't as friendly

The GPU_PROFILE_* macros are not used consistently. A better understanding of how to use this needed
On top of that, there needs to be a consistent use of the GPU_profile_* runtime variables (right now they aren't even runtime)

WITH_GLU might be a superfluous option

The reimplementation of the box filter for making mipmaps is not color/gamma correct (BOX_FILTER_HALF_ONLY in GPU_draw.h)

Could add use of gluScaleImage use back if decide to allow WITH_GLU (along with all the other glu code)

How do the OpenGL ES internal formats differ from desktop? (see use of GLEW_OES_required_internal_format)

check that all Enable/Disable of GL_TEXTURE_* has been replaced

check that all use of ShadeModel has been replaced

check that all use of matrix stack functions has been replaced
list all the functions here later
check that all use of BindTexture has been replaced (may not be needed if code can be written to not need to save the current texture binding)

gpu_glGenerateMipMap may need to be named GPU_generate_mipmap, since it has more logic than a simple wrapper (and isn't a pointer to a function)

check that all use of lighting state has been replaced with the common lighting system
list all the functions here later
includes LOCAL_VIEWER

The basic shader does not currently support alpha testing

The exact roll of GPU_state_init is unclear at this point. If it just needs to switch a default OpenGL context to use Blender defaults and it assumes the GL context is already set to GL defaults then it could be simplified according to the GL usage policy. If it is meant to be rock solid and completely clear a context then it needs expansion.

Truly resetting a context should probably be done by deleting the context and recreating it.

GPU_PROFILE_* variables are current constants, but I'd like them to be runtime, to enable the possibility of having a single version of Blender run both COre and Compatibility profiles.

Make sure that DepthRange is replaced everywhere. This function is needed to capture viewport state in case the gpuFeedback functions are ever used

Multisampling cannot be turned on and off after initializing a context when using an ES context. It would probably be easiest to use multisampling to replace smooth lines etc., but ES may force the use of a shader instead.

The GPU_state_print function has not been adjusted to work with ES or Core contexts

References to GPUGLSL_ES_info need to be removed, however it should be replaced with some kind of GPU_ASPECT_GENERATED shader switch (but the basic aspect might work with little adjustment)

The GPU_texture_dup_pixels is kind of a sledge hammer to make up for ES not allowing textures to be read back. There should be some way of making this more efficient than making a duplicate of the texture on the heap.

GPUGlobal contains a lot of int values used as bool

The GPU* data structures are inconsistently named. previous types are named like GPUData and my new ones are called GPUdata. I really like my convention, but not sure if I should gratuitously rename the old ones.

The get_max_textures function is based on the standard and applies to any use of ClientActiveTexture and ActiveTexture, but I have not checked that 1) every place that uses this value uses it correctly and 2) that every place that needs to use this value checks it first

GPU_extensions_init has grown out of its name and does much more than just initializing extensions. There should probably be a separate GPU_initexit module and all of these initialization functions should be refactored.

remove references to the gpu_object module (old module for handling es shaders that has been replaced by gpu_common)

GPU_CHECK_NO_ERROR should be at the beginning and exit points of every function that directly calls OpenGL (but not functions that do not call OpenGL directly)

Core GL does not allow RED_BITS, etc. to be queried, but GetFrameBufferAttachmentParameter seems to be broken or I'm using it wrong. Maybe work around this by adding a window_manager function which in turn queries this from GHOST

Although there is a flag that says non-power of 2 textures are forcibly disabled for some hardware, I think some parts of the window manager (the triple drawing method) might ignore this/

In GPU_print_framebuffer_error, may want to change the error strings so that they more directly match the enum they are generated by.

There are possibly thousands of places in the code that need a cast from void* because MSVC intellisense flags them due to EDG disagreeing with MSVC about certain C versus C++ warnings

Is there a potential problem with emulating a 1D texture with a 2D texture where the y dimension is 1? Does Blender even use 1D textures? (ES doesn't support 1D textures)

I corrected several places in Blender that just assume a Gen* function will succeed. The fix is to clear the buffer before hand and then check if it gets set, the other is to call glGetError. Either way, all instances of Gen* need to be checked that they don't assume anything.

GPU_glTexSubImageEmpty may have a replacement in newer version of OpenGL that allow an empty texture to be created (Still need to read how this is different than passing a null pointer to TexImage)

Some other places in Blender also upload empty data and could be replaced with this new function, but all instances of TexImage will have to be checked

All uses of !defined(GLEW_NO_ES) and !defined(GLEW_ES_ONLY) need to be checked to see if they make sense

Not sure how to handle depth textures on ES, in particular, not sure how to emulate DEPTH_TEXTURE_MODE=INTENSITY

Handling CLAMP_TO_EDGE vs CLAMP_TO_BORDER can probably be isolated into a function

All places that set format and internalFormat when loading textures need to be check to make sure they never pass in incompatible values depending on the profile

ES does not support textures with borders. I do not have a ready solution to this problem. Maybe all versions of Blender can be made to work without them.

I removed that saving and restoring of the currently bound texture from GPU_texture_from_blender and GPU_texture_from_preview, but I have not made sure that all code that might directly or indirectly use this function need it to not mess up the texture binding.

ES does not have IsTexture. Since Blender always uses GenTextures to make texture IDs, I do not see the use for this function and all uses should be removed once it is shown it isn't needed.

GetTexLevelParameter is not supported under ES, if the width/height of a texture are needed they will need to be stored on the client side somehow (most likely alongside the bindcode when the texture is uploaded)

Check that all uses of CLAMP_TO_EDGE/CLAMP_TO_BORDER are correct (again, this could probably be factored into a function)

Check that all uses of ActiveTexture or ClientActiveTexture will not violate the GPU_max_textures limit

make sure that all the functions that are wrapped in the gpu_extension_wrapper module are in facted replaced by their wrappers

It is invalid to set ReadBuffer to NONE(?)

ES cannot change the DrawBuffer and ReadBuffer without changing contexts. So it is probably possible to emulate multiple read and draw buffers, but it will require contexts changes.

Is it valid to query the viewport in ES?

Some confusion over whether the GPU_framebuffer_texture_bind function should also set the modelview/projection matrixes to identity

gpuViewport may be needed to cache the values of the viewport (and should probably be used to simply avoid the question above about queries), but the other functions like gpuScissor and gpuClear should be removed.

Find instances of _EXT and _ARB and see if they can be renamed to their non-extension names.

shader_print_errors still contains a forced enablement of shader error printing (should probably use a special debug code)

print_with_lineno is redundant, need to merge this with shader_print_errors

The code (in GPU_shader_create) to bind common attributes into locations that ATI cards are OK with might be moved to the gpu_common module?

gpuAttachShader should be gpu_glAttachShader? Why is that code commented out?

The code for printing linking errors is commented out? Why?

It should be OK to temporarily malloc a buffer for the error log instead of a fixed size buffer.

Also, no need to get an error log if printing it out has been disabled anyway.

Is it possible that if a certain shader doesn't use an option that compiling it again is a waste of time? if so, maybe a hashing system could allow the system to recognize this and only compile one copy

Is GPU_shader_uniform_vector ever used with a non-constant length param? If not then there is no reason for it to exist.

The aspect Gen/Delete can be rewritten as a C++ template or at least be generalized so it could be used to implement Gen/Delete for other resources

gpu_aspect currently does not make use of all of its potential features, such as multiple passes

The basic aspect should be isolated by having the current enable/disable state stored in the object parameter instead of being global

Another unimplemented feature is the ability to have multiple aspects use the same interface (enable/disable bits, etc.) and have this be checked at runtime.

There isn't an aspectfunc implementation and switch for generated shaders yet.

need to detect case when specular is not used and create optimized shader, same with texture matrix (could do this with a lot of state, the question is at what point do the number of shaders get out of hand?)

should their be a 'safe' shader to fall back too if compilation fails? perhaps something that only outputs magenta pixels

should their be a global 'no glsl' flag in config (or is this just a compat vs core selection?, not really GLSL, is available as an extension to all versions of GL)

really seems like the multiple shader compiling functions for each aspect could be combined (and further, the shader gen code could be merged in as well)

the *_shader_unbind functions tend to unconditionally change state back to default, but should they emulate the code from GPU_ASPECT_PIXEL? (in that code, only changes from default are actually called)

is it OK that a lot of GPU modules have singleton static data? It may be better to build a global GPU context so everything can be switched.

The gpu_deprecated.h file should contain all deprecated entry points, but also any symbols that are no longer used (use gl python script to find any remaining deprecated symbols that aren't in this file)

At the same time, it may be OK to use certain deprecated functionality of the compatibility mode is enabled, so these symbols need to be condtionally selected.

For example, I'm not completely convinced I should remove DisplayLists from the compatibility profile, although it violates the principle that there should be only one code path if it works in all profiles.

Extension wrapper has to copy/paste a big chunk of the OpenGL header files in order to allow pointers to functions. I think it might be better to wrap these functions in standard cdecl functions so that the function declarations don't have to use this copy paste (none of these functions are called in inner loops)

font shader is so similar to other shader compiling code it probably can be refactored and combined with the others

there is the beginnings of a system for 'restarting' (end_begin) the gpuBegin/gpuEnd buffer if it overflows, but it isn't complete yet. I think it might be less complicated to dynamically grow the buffer, however, I imagine that the buffer might get really big

vertex_copy needs to be made a pointer to a function again because it depends on if wire polygons or thick lines are being drawn, but this hasn't been implemented yet

already mentioned, but each common format (gpuImmediateFormat_*) should have a vertex array object and custom formats should have a data structure that also manages a vertex array object

The format logging conditional compilation is rather ugly. I'm sure it can be made a little nicer looking

The creating of non-default GPUimmediate for use like a display list is a little unintuitive, maybe I should create helper functions that are named like the original displaylist functions (i.e., gpuGenList)

append_client_arrays is moderately problematic in that there needs to be one version for each version of vertex_copy, which feels like a maintanence problem.

I've never been happy with the 'Single' 'Draw' 'Append' naming scheme. 'Draw' seems fine because it sits in the same semantic space as DrawArrays/DrawElements, etc. The others seem like there might be a better name.

The 'Single' functions are built on top of the lower level functions so maybe put them in a different file

The index management functions also seem like they should be in a separate file.

gpuErrorString shouldn't be in GPU_immediate.c

gpuImmediateSingleRepeatRangeElements ... nice name

the client side arrays stuff might be good in a separate file as well

Try to make note of any places where POLYGON is used and wireframe might be enabled. This should be replaced with LINE_LOOP instead of TRIANGLE_FAN

add comment about why buffers are aligned to GPU_immediate_gl.c

clean up all the extra uses of GPU_CHECK_NO_ERROR()

unsetup in GPU_immediate_gl.c unconditionally disables all the vertex arrays (I think this will be taken care of by adding vertex array buffer handling to format/unformat)

The handling of indexes and vertex buffer objects is so similar that I think the functions can be merged

The current implementation of QUAD emulation won't work if an index buffer is required. It seems like the solution there is to go ahead and rewrite the code to generate indexes for triangles (then again, all uses of QUADS should probably do this eventually)

The pile of functions before and after drawing actually drawing in gpu_end_buffer_gl (e.g., unsetup, setup) is mainly defensive and should be cleaned up by vao and putting more into gpu_commit_aspect

make sure that it is legitimate to replace DrawRangeElements with DrawElements (i.e., that it is just an optimization)

need to put all functions used outside of GPU into the top level and the internal functions in the subdirectory, then make sure all the functions are prefixed with GPU_ or gpu_ appropriately

probably want to break out GPU_compatibility.h into separate files instead of having a single catch all (makes it clearer what submodules a file uses)

the implementation of gpuColor3P and gpuColor4P seems like it could be optimized for big or little endian systems (cast the 4 byte array to an unsigned int and do a single assignment (if this is not undefined behavior))

Is MultiTexCoord used anywhere besides the game engine?

8 in GPU_light.c is a magic number, but is well known limit on OpenGL lights

gpu_commit_light should not set fixed function lights if there is a current GPUcommon (?)

gpu_commit_material should return after setting the GLSL uniforms if there is a current GPUcommon (?)

I guess the confusion about the above stems from if the GLSL shader will use the fixed function compatibility uniforms, but since they don't, I think it is safe to ignore the fixed function

I don't remember if I ever got the light direction control in the user prefs to work

old gpuMatrixCommit can be deleted

The math involved in computing the normal and modelview inverse and mvp matrixes has not been thoroughly tested

Can probably optimize by flagging matrixes that are set to identity and then having shaders ignore those matrixes, however, I think this behavior may need to be requested by the aspect that is requesting the matrixes be commited because optimizing all the matrixes requires 8 times as many possible shaders

How much memory to shaders take? Should it be possible to tell blender not to create certain optimized shaders (e.g., fast lighting), in order to reduce the load?

ES seems to have a way to save binary shaders? COuld this be used as a cache on embedded systems? Still not sure what the proper optimization strategy for compiling shaders is, should read up for all the different platforms.

gpuFeedbackVertex should be renamed GPU_feedback_vertex, also, it needs to be tested more thoroughly

There is an extension that makes re-implementing DrawPixels less of a pain (not requiring a special shader), but atm I don't recall if it is Core/ES or what

I intend to create the ability to cache the texture used to replace DrawPixels (this should be great for icons), but atm it isn't implemented.

The PIXEL aspect is different from others because it handles the setting of non-defaults and restoring defaults more gracefully. It is an example of what I consider being too smart, but it seems simple enough that I might convert the other aspects to employ a similar scheme.

I didn't even put all the state in GPU_pixel.c into a struct... (much less put it in a 'GPU context' like all GPU library state should probably be)

like the other aspect implementation, there seems to be a bit of redundancy in how shader compilation is handled

Some confusion, since a lot of the PIXEL aspects implementation existed before making it into a shader and because sometimes DrawPixels is used instead of glaDrawPixelsTexScaled, it may be possible that some combination of optiosn will cause BIAS and SCALE to be ignored.

Also, the logic involved in checking of there is a current GPUcommon also seems to not be implemented correctly yet(?)

glaDrawPixelsTexScaled should be moved to GPU_pixels.c and renamed GPU_draw_pixels_tex_scaled(?)

All of the gla* functions probably need to migrate into the GPU module

functions like gpuCacheBitmap should probably be GPU_cache_bitmap because they are not taken from GL

UNPACK_SWAP_BYTES emulation needs to be implemented

Since none of the functions in GPU_primitive are taken from GL, they should all be renamed with GPU_ names

gpuAppendLitSweep can be deleted(?)

The implementation of gpuImmediateSingleDraw* are in GPU_primitive, but they probably belong on their own (for some reason the declarations are in GPU_immediate?)

No reason to have separate sin and cos value tables (also the positive values should be aligned with the negative values)

'Draw' and 'Single' functions should probably be inline as long as they are short

gpuAppendCode is also commented out (I think all of these were replaced by a more general sweep function)

gpuSpriteBegin/End, etc. needs its own file. The implementation is still legacy, and the use of point sprites more generally still needs to be implemetned

There is a commented out chunk of code in GPU_primitive.h which looks like it got there from a bad merge

primFormat and primDraw probably need to just be static, not BLI_INLINE

My GLU quadric replacement code seems to work in the situations that Blender uses it, but it hasn't been tested generally.

GPU_profile is static right now, but should be dynamic. I don't think it can link directly with GHOST, but pretty sure it can come through the WM

The GPU_ASPECT_RASTER is still rather incomplete: no wire polygons, no thick lines, no stippled lines, no stippled polygons when using ES or Core

I don't remember if I've gone through an made sure that all uses of the 'linestyle' (I think this was renamed to GPU_raster_set_line_style) function are used within the GPU_ASPECT_RASTER

as with the others, the RASTER aspect shader compiling code is very similar to the other shaders

the raster aspect should be made similar to the pixel aspect and only change options that are different than default and automatically restore the default

The vertex_copy functions in GPU_raster are just copies of the defaults in GPU_immediate, but should be rewritten to enable wireframe and thicklines

I have ideas on how to use pixel shaders to make interesting wireframes, but they are not implemented yet.

GPU_SAFETY has not be applied to everything it could be. Will probably find more places to put it as the code is tested (to prevent regressions)

SELECT RenderMode replacement has not been implemented yet.

Should work to make GPU_state_latch.h unneeded by removing cases where state has to be queried

There is no need for GPU_view since none of these functions are deprecated

gpu_Viewport_gl should be moved to state_latch

In gpu_shader_material.glsl, B_GLES should be replaced with GPU_PROFILE_ES20(?)

Should check to make sure all the built in shaders use b_ instead of gl_ variables.

Make sure you use b_ModelViewProjectionMatrix where it can be used

the convention for header include guards in GPU should be consistent, maybe _GPU_FILE_NAME_H_ and _GPU_INTERN_FILE_NAME_H_

double underscore names are reserved to the compiler

shouldn't include guards come at the top of the file?

predeclaration of structs doesn't work in MSVC or C the way it works in C++ or GCC (not sure which combination), but in C and MSVC the predeclarations do not seem to work as intended

Could probably add more colors to GPU_colors, but need to look at use of gpuColorP

use of single GPU_compatibility.h header should be changed in favor of only including the parts needed (gpu_deprecated should always be included though somehow)

It appears the GPU_mipmap_2D is already public? Evaluate this in light of wanting to make gpu_glGenerateMipmaps into public function, maybe it should be gpu_generate_mipmaps instead

is it OK to have GPU_MAT_CAST_ANY? It is annoying, but I think it potentially covers up float/double problems when a user could just remember to tag a [0] onto the Blender matrix.

the primitive constants should probably be an enum and also the names should be GPU_PRIM_* instead of GPU_DRAW_* and GPU_NORMALS_*

Does there have to be a GPU_MAX_SEGS?

have you actually implemented a torus primitive?

The sweep primitives , sprites, and other primitives could probably be moved to separate files

some confusion in rna_image_api about texture coordinate clamping

I added a 'restore default' for gpuBindTexture in rna_image_api, but the TEXTURE_BINDING_2D state is 'defaultless' (meaning you always set it before using it), so this is probably a mistake?

The linking problems you had with makesrna with code coverage can probably be solved by making a GCOV_LIBRARY variable, instead of linking all of the PLATFORM_LIBRARIES (maybe this isn't a big deal, and more trouble than it is worth to really fix 'properly')

probably need to separate out BLI_stat and bli_off_t into a separate patch

gpu_init and gpu_exit need to be made so that only one function needs to be called to initialize the entire module

why are all of exit functions for GPU removed from WM_init_exit?

in answer to earlier question, the triple draw method does check for power of two support using GPU

Just realized that WM and GPU are mutually dependent, I wonder if this can be made one way (WM depending on GPU and removing WM dependency from GPU)

the triple draw method doesn't seem to work with ES but I haven't figured out what feature is missing or not working (doesn't seem to cause a GL error)

double check wmSubWindowScissorSet, don't want to get chewed out for messing it up again

wmOrtho2 should maybe generate a GPU_SAFETY violation if window size is zero? or does this happen as a matter of course?

a gluErrorString check and print was removed from wm_event_system.c (just before GPU_print_error("wm_event_do_handlers")), but maybe it should be kept? might still be useful if GPU_SAFETY is disabled

gpuLoadIdentity followed by gpuOrtho can be replaced with gpuLoadOrtho

windowmanager CMakeLists.txt addes GL_DEFINITIONS twice

Should GL_DEFINITIONS be OPENGL_DEFINITIONS?

There is no SCons build system for Viewport FX yet

Viewport FX has not been ported to Mac or Linux (The difficult part is the changes to GHOST)

I removed the typedef of mode_t from BLI_winstuff.h, but not sure why, I guess it was from my testing with MinGW, I think I end up relying on WIN32 or _WIN32 instead

should bli_off_t be BLI_off_t?

Also removed O_BINARY, similar story to mode_t

definition of the restrict keyword causes all kinds of trouble when not used consistently

is mat4_look_from_origin used anywhere?

would copy_v2_flfl and copy_v3_flflfl be better named as just copy_v3_fl3? copy_v3_fl implies copying one argumet to 3 components, but flflfl is long

in blf.c you use TRUE and FALSE, should be true and false

some DRY violations in blf with the _ascii and non ascii versions of the funcions

should have a GPU_font_begin/GPU_font_end pair like the other aspects?

Remove the DOODLE comments?

Remove the SSS comments?

Maybe replace them with VFX comments sot hey can still be found?

maybe aspect should be renamed something like 'drawmode' or 'shading', but I don't think it will clash with aspect ratio very often (could always rename any other use of aspect to aspectratio instead)

XXX comment about current color in blf can be made just a normal comment

another CLAMP vs CLAMP_TO_EDGE in blf_glyph

Also R8 vs ALPHA texture used for font texture depending on profile (seems to work, but double check the meaning)

bunch of extra GPU_CHECK_NO_ERROR in blf_glyph

glutil.c still needs to be absorbed into GPU

set_inverted_drawing is not quite right, since it doesn't enable blending when LogicOp is not available for use (logicop and blend are mutually exclusive?)

is it important to toggle DITHER if using blending instead of LogicOp to enable inverted drawing?

set_inverted_drawing should take a bool

get_cached_work_texture seems like a usless function in its original form, but maybe I am misreading it

get_cached_work_texture also contains some haggling over internalFormat and format due to differences beween GL versions

bglMats might be integrated into GPU_matrix better

bglFlush removed, but it contained a bug fix, so see how it was used before

can remove any changes to TEXTURE_ENV_MODE

the draw_keyframe_shape function seems like a good opportunity to use instanced geometry (as it is, I've removed the use of display lists, which may or may not change performance)

check to make sure that all points (that aren't meshes) are drawn using the sprite aspect (in other words, scrutinize use of POINTS primitives)

It might be better to directly draw the grease pencil using a quad strip instead of a line strip(already done thsi way?), it might also be nice to generalize this so that strokes can be drawn by other modules

the code added to text_draw for reducing the number of drawing commands has some redundancies

I think it should be possible to issue one command for an entire screen of text

still need to get rid of all uses of PushAttrib

putting Vertex and TexCoord on the same line is confusing (sequencer_draw.c)

I think the gpuPolygonMode is unneeded before uiDrawBox(GL_LINE_LOOP ...) because it isn't drawing polygons (sequencer_draw.c)

why is the gpuSingleFilledRectf(cfra_over ...) commented out in (sequence_Draw.c)

Code requiring ClipPlane has not been replaced

The drawsolidcube function could be moved to GPU_primitives (or it is already there and the code is redundant)

consider not deleting the old cylinder manipulator code

there is a stray 'int a;' in transform.c, guess it is some merge hair

I might have forgotten to make sure that Bitmap falls back to GL 1.1

need to insure that all angles passed into gpuRotate are in degrees, not radians

there are some commented out gpuShadeModel (which is obsolete now), the question is, why and should the RASTER aspect be used here

pretty sure can remove the glRasterPos2fv from before view3d_cached_Text_draw_add because the function doesn't draw anything

the default specular material is white, so no need to set it to white (but this may be needed because not all code that changes specular change sit back yet)

I'm not sure if my draw_view_axis code is what is in this branch or the new code that somebody wrote in response

multisampling and read/draw buffers need something like GPU_multisampling and GPU_read/draw since ES doesn't support these

draw_mesh and draw_object are both just too big as files

since CCG age visualization is a rarely used feature (?) could we find a way to make rendering of edges more efficient by not assuming edges will have individual colors? but still preserve the feature

many of the mesh drawing routines are especially redundant and need to be refactored

ccg, edit, and derived mesh renderers need to be split into legacy and vbo versions, but also need to have their commonalities combined

draw_volume should be updated to use GLSL?

could motion paths drawing be merged with grease pencil drawing?

Maybe I should pull back and make the names for selection mode more close to the original GL names

editarmature.c was deleted? No real need to keep it around for reference. Where did the code go? I'm guessing it needs to be re-ported to VFX

glutil still needs to be merged into GPU

editmesh_slide.c was deleted? same story as editarmature I guess

still some sommented out isntances of gpuEnableLineSmooth

gpuPIxelFormat should be GPU_pixel_format? It has the same purpose as gpuPIxelStore but only applies to drawpixels

maybe should make a GPU_NOT_IMPLEMENTED to warn about unimplemented features that get skipped when running on core or es

GPU_aspect_disable(_, -1) is kind of hackish

should switch_draw just be changed to use gpuDrawClientArrays?

clip_dopesheet_draw copy/pastes the _unit_diamond_shape display list code?

LogicOp NOR is not quite the same as inversion unless the color is black (clip_dopesheet_draw)

draw_curve_knot and draw_fcurve_handle_control were implemented as a display list, but new code doesn't do this, hmm

The WITH_GL_SYSTEM_LEGACY in macros.cmake should be replaced with WITH_GLU

This raises the question, do any of Blender's dependencies depend on legacy OpenGL?

All modifications to glew.h in the glew-es directory are marked with XXX

Setup of ES on windows could be easier

automatic use of ES on non-windows systems hasn't been tested (nothing on non-windows s ystems has been tested, lol)

利用者:Jwilkins/VFX/Issues

目次

Issues

Higher Priority

Lower Priority

Questions

Unorganized

案内メニュー

個人用ツール

名前空間

変種

表示

その他

検索

案内