believe that
slow algorithms are an important use case for the design of
a preview.
Ernst Lippe
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
often. So having
a larger buffer makes the design of the plug-in more complicated
(how should it determine the right size for this buffer),
it will cause a performance hit on many normal preview operations.
Ernst Lippe
___
Gimp-developer mailing list
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 recording the current position and scale
for the user.
Ernst Lippe
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
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
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo
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 forced by
the preview. It is perfectly possible to draw a row
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 drawable (accuracy isn't *hugely* important in general
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 in the preview? Do you generate a viewport-sized (+ margin, say
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 generate
such temporary drawables, when it finds
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 discussion were that some people did not like
the way
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 some people did not like
the way that the preliminary version
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
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http
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,
Ernst Lippe
in the corresponding Fourier
coeficients of the blurred image B. So even very small changes in
B will have a great impact on the least square solution I=D(B).
In practice this means that in general you don't want to use
the true least square solution because it is highly unstable.
greetings,
Ernst Lippe
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
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
, 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 list
[EMAIL
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://refocus.sourceforge.net/preview;.
I've given
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
easy for
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 did
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
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 PROTECTED
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...
Hello Kevin,
is 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 PROTECTED
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/preview.
Please examine it critically, this should
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/preview.
In the section Design in Calling the render
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 [EMAIL PROTECTED]
Requirements
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
you've implemented a system is a perfect way to satisfy
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 constraints
among multiple objects. The naive
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,
Ernst Lippe [EMAIL PROTECTED] writes:
The point is the following. In the current
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 bottom: the image,
the progress bar and the zoom
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 plug-in
,
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 is the version 1.0
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.
Open issue: Scrollbars make the widget visually bigger
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).
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 the
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
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 ;-
39 matches
Mail list logo
