GEGL brush core concept idea

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



A concept for brush core structure from events viewpoint.

* Events are recived from X
* Events are evaluated for:
     -  usefulness using tools options for threshold and dynamics need,
     -  adjusted with curves and filled with requested dynamics
       (MISSING: Tool needs to report what it needs.)
     - coordinates are smoothed with per device smooth factor.

Events are handed to paint core(if a paint tool is active).

-----Paint core takes events-----

* Paint tool on use is called to evaluate the received event.
        - Paint tool evaluates the event in what it means to it
          in its own parameters.
        - Paint tool returns a paint tool data packet object.
		Data packet contains:
			1 to SEG_MAX Segments:
					 stroke_id, 
					 Start_point(x, y),
					 End_point(x, y),
					 distance,
					 resource_id,
					 target_resource_id
					 interpolation_points,
					 xy_interpolation_type,
					 1 - MAX_PARAMETERS parameters:
								param_val, interpolation_type
	   - If constant rate tool(ie airbrush or ink tool), (re)set timer for next 
timer event.
 			OnTimer: call re-evaluate in Tool on last segment, 
                  		       Update segment in paint&store. 
   
* Paint Core handles data packet segment by segment:
    - for each segment:
            Interpolate X&Y, all params. 
            (pop last from Paint&store last points if interp.  type requires)
            For each point
		 -- Query tool for stamp fitting params,
		 -- push stamp&packet to paint&store code. (GEGL?)
-- Paint core is  done --

In this context paint&store code is seen as something where events can be 
popped from and pushed to when needed using a stroke_id. I do not know how 
different that is from what GEGL does.


One of the biggest benefits is that one core can handle many very different 
paint tools.

Paint tools can become plug-ins if desired, they only need to provide to core 
3 functions, evaluate-event, re-evaluate-event, render-stamp. This makes 
creating new paint tools extreemly simple and lets people make tools that are 
free in setting their dynamics to whatever they need enabling very 
interactive and lifelike brushes. One tool I see is offspring of current 
vector brush that lets one save all dynamics curves it desires mapping them 
to any stamp parameter.

Support for current brushes can be enabled through always available default 
plug-ins.

This paint core does not handle any interaction with the canvas, only the 
shape and path of the tool. For physical media simulation a canvas that 
supports and can render different "paints" is needed. The canvas interaction 
is something that happens in the different types of canvas.

I currently lack the skills to implement such a core, but perhaps it serves a 
startingpoint for someone who can either refine it or even implement it just 
as my ideas were based on others notions.

Best,
Alexia.
_______________________________________________
Gimp-developer mailing list
Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Index of Archives]     [Video For Linux]     [Photo]     [Yosemite News]     [gtk]     [GIMP for Windows]     [KDE]     [GEGL]     [Gimp's Home]     [Gimp on GUI]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux