RSS/Atom feed Twitter
Site is read-only, email is disabled

GEGL brush core concept idea

This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

1 of 1 message available
Toggle history

Please log in to manage your subscriptions.

GEGL brush core concept idea Alexia Death 17 Jan 23:50
Alexia Death
2008-01-17 23:50:07 UTC (almost 17 years ago)

GEGL brush core concept idea

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.