Re: [Gegl-developer] GEGL and GTK+, a proposal

2011-06-12 Thread Joao S. O. Bueno
On Sun, Jun 12, 2011 at 3:03 PM, Jon Nordby jono...@gmail.com wrote:
(...)
 So I propose to:
 - Create a new gegl-gtk repository, containing the new library
 (alternative is to have it as a toplevel in gegl repo, if anyone can
 present good arguments for that I don't mind)
 - Add gegl-gtk component to bugzilla
 - Move gtk-display and GeglView there, remove it from gegl repo

It makes sense for me.
As you stated, removing GTK+ from GEGL's dependencies should allow
GEGL to be used in more projects as a it should be.

  js
 --
___
Gegl-developer mailing list
Gegl-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer


Re: [Gegl-developer] Area filters

2008-06-27 Thread Joao S. O. Bueno
On Friday 27 June 2008, Øyvind Kolås wrote:
 On Thu, Jun 26, 2008 at 4:33 PM, yahvuu [EMAIL PROTECTED] wrote:
  On Thu, Jun 26, 2008 at 2:31 PM, Øyvind Kolås [EMAIL PROTECTED]
  wrote: Anyhow, implementing these filters as new operations
  solves the problem for now. Having two kinds of gaussian blur
  seems awkward at first, but it is a user choice which edges to
  blur and not GEGL's.
  The filter pairs can be merged later on by implementing
  one as a meta operation of the other or simply by an
  option property like preserve bounding box.
 
  I'll derive the new filters from GeglOperationEdgedAreaFilter if
  no better naming comes up. For the filters probably:
  gaussian-blur-edged,
  box-blur-edged

 It is much better to extend GeglBuffer to have an abyss policy,
 this means that requests for pixels outside
 the define area gets read back as if they were smeared/mirrored (or
 like now all 0). After this the gaussian blur could be changed to
 not expand it's result rectangle beyond the original input, and
 still use the current easily managable code paths for the actual
 filtering.


This looks plainly as the right thing to do.
Just to formalize the behavior. The most natural way of doing it would 
be if  the filter should have a way to tell the buffer what it 
wants from the abyss. Note that this is different than setting the 
behavior as a property in the source buffer - it sounds more like 
a temporary property defined by whoever is consuming the buffer.

If that is too weird, or would make the code too insane, plain object 
properties to set the buffer behavior would be fine.

So, far I think the desired behaviors for the abyss could be:
- solid color (any, including transparent colors)
- stretch (smear)
- wrap (tile)
- mirror
and maybe:
- offset buffer

where offset buffer would be another buffer linked to the source one, 
just like a larger background layer. This would allow one to 
implement any desired behavior by creating the other buffer prior to 
applying the filter - (gradients, scaled mirroring, relief effects, 
etc... )

js
--

 /Øyvind K.


___
Gegl-developer mailing list
Gegl-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer