[Bf-viewport] Viewport

[Antony Riakiotakis]

Hi,

While the design of the new viewport is not final, I would not invite
people to start working on that, but the viewport target is full of
little
subtargets that can be handled collectively.

I think the easiest pick for a new developer is to find and eliminate
immediate mode drawing calls throughout blender's code base.
Those should be substituted by our GPUBuffer system (Check
GPU_buffers.h and gpu_buffers.c). This should not be that difficult
and
there's actually much drawing code in blender so help there would be
quite welcome.

The GPUBuffer system in the file itself is a bit tied to how
derivedmeshes work, but ultimately, GPUBuffers are just, well, arrays
of data.
What is missing from the GPU buffer system, is a -generic- way of
representing the vertex format, where again the code is too tied to
the derivedmesh system. However for most drawing code in blender (UI
for instance) we need a few ready-made vertex formats, such as
vertex-uv or vertex-color-uv, which don't really require a specialized
system to deal with.

So again, if you'd like to help, I'd recommend:

* Scout the code for glBegin/glEnd/glVertex
* Create small GPUBuffers to hold the data instead. These could be
dynamically generated and deleted if the underlying code treats them
like that or cached somewhere if the size remains the same or if a
clear owner of the buffer with clear invalidation rules can be
determined. Keep in mind that there mush be a way to clear those
GPUBuffer caches centrally (in case of context invalidation, user
preference changes for type of buffers used, etc). For some reusable
things like button styles, rectangles etc, we could probably have some
cached reusable buffers somewhere.

Another subproject we could use help with is substituting the OpenGL
matrix stacks with our own. There is already code that does that in
the temp_viewport_fx_merge branch but the way it does it currently is
by hooking a matrix flush to OpenGL before every draw call which is
horribly inefficient and was done only to prove the proof of concept
works. Ideally flushing should be done before drawing only if the
matrices haven't changed. The lazy way to do this is to just add
checks before each draw call, but the proper way to do it is by
examining the code and only do it when we must (no checks, just
programmer vigilance). The reason is simple: Not all draw calls use
matrices. In fact, for some things like UI we could very well use
entirely 2D pipeline/shaders in the future). Flushing in that case is
just wasted cycles.
It's a highly volatile project though and would not recommend it to beginners.
Probably there will be some code from me there first, then we can
proceed and do the call for help, just like with the recent
looptriangle refactor.