Blame synfig-core/doc/hw-gfx-mapping.txt

Carlos Lopez a09598
Shader Calculation Model:
Carlos Lopez a09598
Carlos Lopez a09598
inputs - variables that control the object
Carlos Lopez a09598
shader - joint vertex and pixel shader necessary for calculation
Carlos Lopez a09598
Carlos Lopez a09598
Parameter Types:
Carlos Lopez a09598
	Uniforms - things that are constant for the entire render setup
Carlos Lopez a09598
Carlos Lopez a09598
Layer render properties:
Carlos Lopez a09598
Carlos Lopez a09598
Blend - blends with layer behind (amount,blend-method), if complicated must use (pixel shader...).
Carlos Lopez a09598
Algorithmic - gets colors without sampling textures (exception for function look ups...).
Carlos Lopez a09598
Carlos Lopez a09598
Sampling - samples a texture map as part of the color calc process.
Carlos Lopez a09598
	Behind - use result(s) below to calculate color.
Carlos Lopez a09598
	Internal -
Carlos Lopez a09598
		Functions/Inputs - CPU generated internal texture maps (uniform)
Carlos Lopez a09598
		Dependent - GPU generated texture maps (unknown use...)
Carlos Lopez a09598
Carlos Lopez a09598
Parameters:
Carlos Lopez a09598
	Uniforms - layer-wide stats (color, blend-mode, amount, below texture, coverage map, etc.)
Carlos Lopez a09598
	Varying - pixel coordinate (in canv-space), texture coordinates for samplers, etc.
Carlos Lopez a09598
Carlos Lopez a09598
For optimized stuff:
Carlos Lopez a09598
	For layer constants that aren't simple calculations (i.e. changing the blend type),
Carlos Lopez a09598
	we can use global constants (however since OpenGL doesn't allow you to define those
Carlos Lopez a09598
	manually, we can probably do it with #defines or the like)... Just in time compiling
Carlos Lopez a09598
	(optimized by caching these changes of course) would allow us to operate in an optimal
Carlos Lopez a09598
	manner (rather than having dynamic branching at run time).
Carlos Lopez a09598
Carlos Lopez a09598
Considerations for Framework:
Carlos Lopez a09598
Carlos Lopez a09598
For truly optimal rendering, caching textures would be great, but it would take up a lot of space.  So an intelligent resource system should be implemented.  The resource eviction routine should be intelligent and should deal with the resources deepest in the tree (of course this doesn't entirely count for CPU generated stuff).  A priority system should be generated, mostly depending on how often it's used and even more, how expensive it is to generate (cpu and gpu side...).
Carlos Lopez a09598
Carlos Lopez a09598
Shader considerations for Operations:
Carlos Lopez a09598
Carlos Lopez a09598
Blend functionality can be done in a separate pass unless the blending shader part is also programmable (requires less JIT compiling).
Carlos Lopez a09598
Carlos Lopez a09598
Sampling function should be abstracted to use different forms of interpolation (for nearest and linear, the built in support is probably plenty).
Carlos Lopez a09598
Carlos Lopez a09598
Iterated calculations: either done using dynamic looping in GLSL or multipass rendering.
Carlos Lopez a09598
Carlos Lopez a09598
Carlos Lopez a09598
Shader considerations for layers:
Carlos Lopez a09598
Carlos Lopez a09598
solid_color - just use blend with an input global color parameter
Carlos Lopez a09598
Carlos Lopez a09598
circle - can calculate alpha in falloff based on interpolated pixel values and then use that and the amount... color to blend (must work out whether or not to out put an amount map + color blend, or a color map + amount blend... currently using the first on CPU side).
Carlos Lopez a09598
Carlos Lopez a09598
checker_board - same as circle, but a simpler calculation (antialiasing will require a few calculations using the values of the derivatives of the pixel coordinates)
Carlos Lopez a09598
Carlos Lopez a09598
rectangle - same thing as the checker_board, but only need to worry about 2 edges per dimension.
Carlos Lopez a09598
Carlos Lopez a09598
Coverage Map Based: outline,polygon,region,star,text
Carlos Lopez a09598
and Internal Samplers: import, noise
Carlos Lopez a09598
	- would require CPU side computation of the coverage map/color map
Carlos Lopez a09598
	  (tiling would be a little more difficult... we'll see how effective it would be...)
Carlos Lopez a09598
Carlos Lopez a09598
Modifiers (algorithmic w/ direct below sample): clamp,colorcorrect (blend also classifies as this)
Carlos Lopez a09598
	- modification of the colors underneath using math... easy....
Carlos Lopez a09598
Carlos Lopez a09598
Basic Transform: translate,stretch,zoom (should require no sampling),super_sample (simple down sample)
Carlos Lopez a09598
	- simply requires the repositioning (and resizing in the case of the super sample) of the window
Carlos Lopez a09598
Carlos Lopez a09598
Behind Samplers:
Carlos Lopez a09598
	Basic Transform: rotate,twirl,
Carlos Lopez a09598
	In-place: bevel,blur,halftone2,shade
Carlos Lopez a09598
	Warpers: inside_out, spherize, noise_distort (internal and behind sampler)
Carlos Lopez a09598
	- requires access to the background texture (with increased window in order to not find distortions).
Carlos Lopez a09598
Carlos Lopez a09598
Iterated: mandelbrot,julia (used to warp, index into gradient, etc.)
Carlos Lopez a09598
	- requires iterative refinement of the fractal values (with crazy swapping to consider stopping points)
Carlos Lopez a09598
Carlos Lopez a09598
Gradients (complicated... could require a CPU side color map, unless we have dynamic looping):
Carlos Lopez a09598
	conical_gradient, linear_gradient, radial_gradient, spiral_gradient