nts in the discussion were that some people did not like
the way that the preliminary version of the preview tried to prevent
recursive updates and that the names did not start with GIMP.
As far as I can tell these points have been fixed in
the first official release.
Ernst Lippe
___
On Wed, 18 Feb 2004 10:18:58 +0100
Dave Neary <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Ernst Lippe wrote:
> > Sven Neumann <[EMAIL PROTECTED]> wrote:
> >>http://refocus.sourceforge.net/preview/gimppreview.html
> >
> > The major points in the discussio
On Wed, 18 Feb 2004 13:51:40 +0100
Sven Neumann <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Ernst Lippe <[EMAIL PROTECTED]> writes:
>
> > > http://refocus.sourceforge.net/preview/gimppreview.html
> >
> > The major points in the discussion were that
On Wed, 18 Feb 2004 15:18:49 +0100
Dave Neary <[EMAIL PROTECTED]> wrote:
>
> Hi Ernst,
>
> Ernst Lippe wrote:
> > Dave Neary <[EMAIL PROTECTED]> wrote:
> >>As a matter of interest, do you do any optimisation based on the current
> >>viewport
On Wed, 18 Feb 2004 16:19:06 +0100
Sven Neumann <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Ernst Lippe <[EMAIL PROTECTED]> writes:
>
> > No, the preview itself does not generate any temporary drawables.
> > However there is a utility function for the plug-in to g
On Thu, 19 Feb 2004 16:45:45 +0100
Dave Neary <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Ernst Lippe wrote:
> > Dave Neary <[EMAIL PROTECTED]> wrote:
> >>1) if the original drawable is zoomed out, do a messy scale of the original to
> >>give the new d
On Thu, 19 Feb 2004 16:00:08 +0100
Sven Neumann <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Ernst Lippe <[EMAIL PROTECTED]> writes:
>
> > The decision if the plug-in "needs" the temporary drawable
> > is made by its designer and it is certainly not force
to simply use the outputs from gimptool-2 instead of my hacked
version. I am afraid that I don't have the time right now to suggest a good
solution (anyhow I don't have Gimp-2 installed, so I can't test any
modifications).
Ernst Lippe
_
most current plug-ins are indeed not very
efficient. But especially with slow algorithms you desperately need
a preview. And even with a fast algorithm there will be cases
when the user is probably faster, e.g. while scrolling or
zooming a large preview image. So I certainly believe that
slow algorithms a
ger
distance. The only case where such a larger buffer might
be useful is when the user only scrolls by very small amounts
and in my experience that does not occur often. So having
a larger buffer makes the design of the plug-in more complicated
(how shoul
omputations can be
halted when the image that is being computed has become obsolete.
In my experience this happens very frequently.
Ernst Lippe
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
On Tuesday 25 May 2004 14:57, Sven Neumann wrote:
> Hi,
>
> Ernst Lippe <[EMAIL PROTECTED]> writes:
> > Do you really propose that the plug-in itself handles all the GUI
> > interactions for scrolling, zooming and resizing and that it also is
> > responsible for r
ve some separate "Update preview" button,
but that is just awkward for the user.
Ernst Lippe
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
The installed version of a plug-in can contain other files than just the
executable, e.g. help files and locale files.
When the user has root permissions these files can be installed on the
standard locations for the system, but where should these files be
installed when that is not the case?
The
Marc Lehmann wrote:
> I'd like to remind people that corba is not the only way to go, as there
> is also dco and especially MCOP (which was designed for realtime and
> multimedia applications). While CORBA might indeed be the best choice, it
> mustn't be choosen just because it has more letters ;-
Marc Lehmann wrote:
> I'd like to remind people that corba is not the only way to go, as there
> is also dco and especially MCOP (which was designed for realtime and
> multimedia applications). While CORBA might indeed be the best choice, it
> mustn't be choosen just because it has more letters ;-
Marc Lehmann wrote:
>
> On Sat, Feb 24, 2001 at 01:58:06AM +0100, Ernst Lippe <[EMAIL PROTECTED]> wrote:
> > protocol for communication between plug-ins and Gimp that are all
> > running on the same machine, you are free to choose any non standard
> > protocol you
The speedup that you see is probably mainly caused by better caching.
There is a bug in the tile cache size for the plugin.
The cache is under most circumstances too small and this means that
every requested tile is not in the cache and must be transmitted from
the main gimp process (SLOW).
Effect
I think this is yet another tile-cache problem.
Georg Acher wrote:
>
> On Thu, Apr 05, 2001 at 12:45:52PM -0500, Kelly Martin wrote:
>
> > Hm, it does not. The issue with whirlpinch is that there's only a
> > weak locality relationship between destionation pixels (which are
> > iterated across
Kelly Martin wrote:
>
> If the algorithm is pixel-by-pixel (each output pixel depends only on
> exactly one input pixel from each region being iterated over, and
> those regions are all the same size) there is absolutely no excuse not
> to use the pixel region iterator, which will automagically m
Austin Donnelly wrote:
>
> Actually, the core could do with a tile convolution, since currently
> it copies data into a tempbuf before convolving it. This makes some
> tools more effificient (or incorrect) eg iscissors.
I'd love to see convolution in the Gimp core. I've written some code
that i
Austin Donnelly wrote:
>
> On Sunday, 8 Apr 2001, Ernst Lippe wrote:
>
> > Austin Donnelly wrote:
> > > Actually, the core could do with a tile convolution, since currently
> > > it copies data into a tempbuf before convolving it. This makes some
> > >
tings,
Ernst Lippe <[EMAIL PROTECTED]>
Maurits Rijk <[EMAIL PROTECTED]>
Requirements for a GIMP plug-in preview widget
==
This document gives a possible list of requirements for a preview
widget that can be used by GIMP plug-ins. This i
On 26 Feb 2003 14:24:17 +0100
Sven Neumann <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Ernst Lippe <[EMAIL PROTECTED]> writes:
>
> > There are two possible GUI styles: dragging in the preview and using
> > scrollbars. These could also be combined.
> >
On Wed, 26 Feb 2003 14:17:21 +0100
Øyvind Kolås <[EMAIL PROTECTED]> wrote:
> * Ernst Lippe <[EMAIL PROTECTED]> [030226 14:04]:
>
> > Non-requirement 1. Preview the rendered results in the original image
> > window.
> >
> > The rendered image sh
On Thu, 27 Feb 2003 00:49:50 +0100
"Branko Collin" <[EMAIL PROTECTED]> wrote:
> Sometimes, a rendering algorithm is very slow.
I know this all too well.
> A user should be able
> to switch off the automatic rendering of a preview.
I don't think this is part of the preview widget.
It calls the p
On 26 Feb 2003 17:29:37 +0100
Sven Neumann <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Ernst Lippe <[EMAIL PROTECTED]> writes:
>
> > The point is the following. In the current implementation the preview
> > widget consists of the following components from top to
On 01 Mar 2003 17:39:56 +0100
Sven Neumann <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Ernst Lippe <[EMAIL PROTECTED]> writes:
>
> > A set of previews that you want to synchronize is an example of a
> > constraint based system where you want to solve a set of co
On Sat, 01 Mar 2003 12:46:57 +0100
Michael Natterer <[EMAIL PROTECTED]> wrote:
> Ernst Lippe <[EMAIL PROTECTED]> writes:
>
> > On 26 Feb 2003 17:29:37 +0100
> > Sven Neumann <[EMAIL PROTECTED]> wrote:
> >
> > > Hi,
> > >
> > >
On 03 Mar 2003 11:54:42 +0100
Michael Natterer <[EMAIL PROTECTED]> wrote:
> Again, you should understand how GObject signals work. They operate
> purely synchronously. A signal handler cannot be "too slow" because
> the only thing your program is doing while emitting the signal is
> emitting the s
ll tiles from the image that are
completely obscured by higher layers. After all, like the color
information in transparent pixels, these tiles do not contribute anything
to the final image, so it seems very reasonable delete them. Also I
suggest that a good random number generator is used to d
On Tue, 11 Mar 2003 17:12:14 +0100
Raphaël Quinet <[EMAIL PROTECTED]> wrote:
> On Tue, 11 Mar 2003 16:38:13 +0100, Ernst Lippe <[EMAIL PROTECTED]> wrote:
> > On Tue, 11 Mar 2003 09:46:49 +
> > "Adam D. Moss" <[EMAIL PROTECTED]> wrote:
> > I thi
On Tue, 11 Mar 2003 19:05:03 +0100
Raphaël Quinet <[EMAIL PROTECTED]> wrote:
> On Tue, 11 Mar 2003 18:20:34 +0100, Ernst Lippe <[EMAIL PROTECTED]> wrote:
> So don't do that, then! ;-) Nobody should rely on unspecified
> behavior.
But how should an end-user k
)
As Nick Lamb already noted, there is another good argument
against pre-multiplied alpha: loss of precision.
When you're using a single byte per color that could be
a serious problem.
greetings,
Ernst Lippe
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
ation that supports all
the requirements in the list (writing requirements after
you've implemented a system is a perfect way to satisfy
all system requirements).
At the moment we are still working on it, but we hope
to publish the API real soon now.
greetings,
Ernst Lippe &l
On 19 Mar 2003 18:47:11 +0100
Sven Neumann <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Ernst Lippe <[EMAIL PROTECTED]> writes:
>
> > At the moment we have an implementation that supports all
> > the requirements in the list (writing requirements after
> > yo
On Thu, 20 Mar 2003 10:55:49 +0100
Sven Neumann <[EMAIL PROTECTED]> wrote:
> Ernst Lippe <[EMAIL PROTECTED]> writes:
> > Another point is that the current name of the widget is GimpPreview
> > and for some reason I don't think that you will like that name
> &
left of it
after the discussion) for the final documentation I
also welcome minor comments such as spelling mistakes, grammar
corrections, coding errors and such.
greetings,
Ernst Lippe
<[EMAIL PROTECTED]>
___
Gimp-developer mailing list
[EMAIL PRO
On Mon, 31 Mar 2003 19:58:29 +0200
Sven Neumann <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Ernst Lippe <[EMAIL PROTECTED]> writes:
>
> > As promised here is my API proposal for a plug-in preview widget.
> > You can find it at http://refocus.sourceforge.net
age, and for most plug-ins
I would expect that the preview normally shows a small part of the image
at its real size.
greetings,
Ernst Lippe
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
On Mon, 31 Mar 2003 20:17:51 +0200
Sven Neumann <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Ernst Lippe <[EMAIL PROTECTED]> writes:
>
> > As promised here is my API proposal for a plug-in preview widget.
> > You can find it at http://refocus.sourceforge.net/prev
On Mon, 31 Mar 2003 22:50:00 +0200
Sven Neumann <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Ernst Lippe <[EMAIL PROTECTED]> writes:
>
> > P.S. Of course the most logical solution is to change the name of
> > the core widget. My widget is derived from Shawn Amunds
On Tue, 01 Apr 2003 13:59:21 +0200
Sven Neumann <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Ernst Lippe <[EMAIL PROTECTED]> writes:
>
> > The only way to avoid this overhead is to make interface more
> > complicated, analogous to the GimpPixelRegions, there shoul
according to Google.
I can't find it in my Webster's, but proof does have the
right connotation, after all the preview is a preliminary
version of the final results.
greetings,
Ernst Lippe
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
unds like something tiny. Actually when you zoom in and
use a large preview it can be much bigger than the original
image.
greetings,
Ernst Lippe
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Even though I fully agree that the only serious problem in my API
proposal is the name of the widget, I'd really like to get more input
from more people about my API proposal.
Especially, I would like to hear remarks from other plug-in developers,
because they are after all the intended audience f
My Webster's lists prevue as a synonym for preview (to me this appears
to be the original French root of the word).
Does GimpPrevue sound very weird for native English speakers?
greetings,
Ernst Lippe
___
Gimp-developer mailing list
[EMAIL PROT
On Thu, 03 Apr 2003 02:15:42 +0200
"David Necas (Yeti)" <[EMAIL PROTECTED]> wrote:
> On Thu, Apr 03, 2003 at 01:15:31AM +0200, Ernst Lippe wrote:
> > P.S. I just modified my preview so that the re-entrancy problem has
> > been eliminated.
>
> Excuse me,
On Wed, 02 Apr 2003 16:05:52 -0800
Jeshua Lacock <[EMAIL PROTECTED]> wrote:
>
> On Wednesday, April 2, 2003, at 03:41 PM, Kevin Myers wrote:
>
> > Personally I don't think that it sounds too bad at all, especially
> > considering the lack of other decent alternatives suggested so far...
>
> Hel
On Thu, 03 Apr 2003 02:00:22 +0200
Branko Collin <[EMAIL PROTECTED]> wrote:
> What do the two different GimpPreviews do? If they are so alike, why
> are there two different versions? Please explain it to me as if I did
> not understand programming at all (which I don't, so it will be very
> eas
On Fri, 04 Apr 2003 00:05:47 +0200
Branko Collin <[EMAIL PROTECTED]> wrote:
> Perhaps you two are using different meanings for 'amateur': one being
> 'unpaid', the other 'low-quality'. Of course, in the old days,
> amateur meant 'noble', 'high-quality', because an amateur was
> something who d
y comments, I would like to encourage everyone, especially all
plug-in developers, to examine it critically. At the moment there is
no installed user-base and it should be fairly easy to change things.
greetings,
Ernst Lippe
___
Gimp-developer mailing l
On Wed, 11 Jun 2003 13:45:20 +0100
"Adam D. Moss" <[EMAIL PROTECTED]> wrote:
> Ernst Lippe wrote:
> > After an intolerable long wait, I just released the first official version
> > of the new GimpPreview plug-in widget.
> > You can find it at "http://re
http://refocus.sourceforge.net.
greetings,
Ernst Lippe
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
hey require user intervention
to determine the number of iterative steps.
Perhaps this explanation is a bit too convoluted, but I think
that it contains some important points. Feel free to ask
when you have any problems.
greetings,
Ernst Lippe
___
G
that in general you don't want to use
the true least square solution because it is highly unstable.
greetings,
Ernst Lippe
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
he extensions
that are not supported by the other program. Both programs have
a lot in common. Users will really appreciate it when they can
easily exchange data between the two programs.
(I know this is probably not quite the right moment to suggest
this)
greetings,
Ernst Lippe
(PS. Robin I would ap
may not
give copies of the binaries to other without telling them that it
is GPL-ed and giving them access to the sources. I am not a great
fan of licenses either, but from a legal point it is really important
to inform all users about their license.
greetings,
58 matches
Mail list logo
