Hi Shrinivas,

Shrinivas Kulkarni wrote:

Is there any way to display GIMP image in GTK controls?

If by GIMP image you mean an XCF, then I don't know of any such widget. However, the GtkImage widget supports a number of file formats - including png, tiff, xbm, gif and jpeg.

There is one
more question I have is that, can we write a standalone app using GIMP. This question arises, because, I do not want to use all the funcitonality of GIMP, but want to have my own toolbox and still able to use selective functionality from GIMP.

You might be better looking at something which was designed as a graphics toolkit, such as ImageMagick. The GIMP application contains quite a bit of the functionality we use, and plug-ins communicate with it using a wire protocol that I don't understand. You could steal the minimum of code from the GIMP to use the PDB, or you could do as Simon suggested in another thread, and run the GIMP im batch mode.

Hope this helps, Dave.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Shrinivas Kulkarni wrote: | Is there any way to display GIMP image in GTK controls? There is one | more question I have is that, can we write a standalone app using GIMP. | This question arises, because, I do not want to use all the | funcitonality of GIMP, but want to have my own toolbox and still able to | use selective functionality from GIMP.

It depends on what you mean by "using GIMP." You can use gimp as a rendering backend, if you want. There has been some discussion of the portability of our internal widgets and that they might be useful as another library. The code is much more modular than it was, so using our widgets in a seperate app might be a good idea too. You would be the first person to try it though, so I imagine there will be some problems (though not insurmoutable ones).

- -- Daniel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE/2JvRad4P1+ZAZk0RAikPAJ9W44bJKYTgxnZn2TGxEvAq+CxtWwCfdDOt wJIxqqLBsf22bmcILtSR+kY=
=RRtx
-----END PGP SIGNATURE-----

Hi,

Daniel Rogers writes:

It depends on what you mean by "using GIMP." You can use gimp as a rendering backend, if you want. There has been some discussion of the portability of our internal widgets and that they might be useful as another library. The code is much more modular than it was, so using our widgets in a seperate app might be a good idea too. You would be the first person to try it though, so I imagine there will be some problems (though not insurmoutable ones).

Well, since most of the interesting widgets are in the GIMP core and not in libgimpwidegts, there will probably be quite some problems to use these from another application. We will probably continuosly move more widgets to libgimpwidgets and of course if there's interested from other applications to use this code, we can take this into consideration.

Sven

Hi Shrinivas,

Shrinivas Kulkarni wrote:

By "using GIMP" I mean to use GIMP as library. Such facilty may be necessary since we may not want user to have all the functionality that Core GIMP provides. For example, we may want user to draw on the image( lines, curves), but may want user to allow apply rich filters GIMP provides.

Ah... if this is really a typical problem area, then you might have some problems.

The GIMP is organised in 2 parts, the core application, and its plug-ins (and associated infrastructure, libraries, etc). It would be possible to link against the libgimp libraries to create a plug-in, or example, or as someone suggested to replace the core with a "lite" core which understood the PDB, and communicate with plug-ins that way.

But since you don't seem to be too interested in the filters, and seem more interested in the core application, that doesn't seem to be what you want to do.

The core application contains (more or less) tools, internal data structures for images, layers, vectors and so on, a number of widgets for the UI, code for loading and using external data (brushes, patterns and so on), and the PDB core implementation (the protocol we use to talk to plug-ins). Since this seems to be the code you're interested in, that's what you would be looking at. Unfortunately, it's not written to be used as a library - you can't link with the draw tools only, for example, in a 3rd party application. Howeveer, the code is quite modular, and I think you could probably dump most of the filters (except file loaders for formats you're interested in, or else use a GtkImage), dump many of the tools, lose more than half the GUI code, and arrive at something resembling GPaint.

Or, you could write a corba control for GPaint, and embed that in your application?

I do not understand,
why I cannot have image created and displayed without GIMP running.

I understand. However, it was not our goal to provide a reusable graphics framework at this stage. That is a goal of gegl, though. And that should be possible within a few months, if all goes well.

In short, the edit window, right now we have that should converted to widget and developer should be able to use it even without running GIMP. ( This implies that user should be able to call even PDB functions that is calling procs from PDB.)Right now the edit window, seems to be very much tightly coupled with Toolbox. If we provide such facility GIMP will be really extensible.

I'm not clear on how this could be accomplished. Would you like to write a proposal on how you think this might happen? I mean, how you would make the toolbox, for example, optional or modifiable. This is something that we would like to see, and if you have ideas we would love to hear them.

Cheers, Dave.

Hi,

"Shrinivas Kulkarni" writes:

But given the scope of libgimp, where we can draw selections, cut, paste from image without using Toolbox ( by calling functions with prividing drawable id ), I do not understand, why I cannot have image created and displayed without GIMP running.

You misunderstood what libgimp is actually doing. libgimp consists of two parts. First, it implements the plug-in side of the wire protocol that is used to communicate between GIMP and its plug-ins. The communication goes over shared memory and/or pipes and is limited to a certain set of procedures that are registered in the Procedural Database (PDB). The second part of libgimp is a set of wrappers that allow to use the PDB from the C programming language. As you may have noticed already, there isn't any image manipulation functionality in libgimp. It only provides a way to call such functions in the GIMP application.

What you are suggesting is a major redesign and it will not happen the way you proposed it here. But what we are planning to do is to provide a sophisticated image manipulation library called GEGL. GIMP will use this library internally and it will be designed to be useful for other apps as well. This will allow you to link your application against the same powerful image manipulation library that The GIMP is using.

I don't think we want to attempt to export any user interface functionality such as the image window to other applications. This is simply too GIMP-specify to be sanely reused from other apps.

Sven

Hi,

"Shrinivas Kulkarni" writes:

Therefore I got pkg-config-0.15.0 and tried building it first, unfortunately it is giving some compiler errors. Is there any place where I can get precompile binaries for pkg-config.

http://www.gimp.org/~tml/gimp/win32/downloads.html

I would suggest however you don't waste your time trying to build GIMP using mingw. You better install gcc and the GNU toolchain from cygnus.

Sven

Sven Neumann wrote:

"Shrinivas Kulkarni" writes:

Therefore I got pkg-config-0.15.0 and tried building it first, unfortunately it is giving some compiler errors. Is there any place where I can get precompile binaries for pkg-config.

http://www.gimp.org/~tml/gimp/win32/downloads.html

I would suggest however you don't waste your time trying to build GIMP using mingw. You better install gcc and the GNU toolchain from cygnus.

Out of interest, what's wrong with mingw's toolchain? I never have tried (and never will!) to build GIMP with it, but it generally copes adequately with the mildly-unix-centric codebases I throw at it.

Regards, --Adam

Hi,

"Adam D. Moss" writes:

Out of interest, what's wrong with mingw's toolchain? I never have tried (and never will!) to build GIMP with it, but it generally copes adequately with the mildly-unix-centric codebases I throw at it.

I might be wrong since I don't compile on Win32, so perhaps I'm confusing things here. But as far as I can remember the mingw compiler needs it's own set of makefiles. There used to be such makefiles in the GIMP tree but after being unmaintained for a looong time, they have finally been removed.

Sven

Hi,

"Shrinivas Kulkarni" writes:

We can still execute cofigure script, which in turn generates make file for GIMP. :)

These are makefiles for GNU make. If they work for mingw, that's fine then.

Sven

Hi Shrinivas,

Shrinivas Kulkarni wrote:

Therefore I got pkg-config-0.15.0 and tried building it first, unfortunately it is giving some compiler errors. Is there any place where I can get precompile binaries for pkg-config. I am really running short of time, therefore I do not think I should spend more time on this. I am following the instructions from
http://wiki.gimp.org/gimp/HowToCompileGimp/MicrosoftWindows in order to build GIMP.

You can get everything you need to build the GIMP from source at http://www.gimp.org/~tml/gimp/win32/ - this has zips containing DLLs, header files, lib files, etc. There are pointers for binary downloads of everything you need, including build tools from GNUWin. You might also consider using the Dropline builds of GTK+ 2.2.x, these install DLLs "properly" for Win32, and there are instructions on their site for building stuff using them.

Cheers, Dave.

PS: Please note that I've never managed to get a full GIMP build on Win32, although it's almost a year since I last tried. I have always had linker problems.

Hi,

"Adam D. Moss" writes:

Out of interest, what's wrong with mingw's toolchain? I never have tried (and never will!) to build GIMP with it, but it generally copes adequately with the mildly-unix-centric codebases I throw at it.

I might be wrong since I don't compile on Win32, so perhaps I'm confusing things here. But as far as I can remember the mingw compiler needs it's own set of makefiles. There used to be such makefiles in the GIMP tree but after being unmaintained for a looong time, they have finally been removed.

Sven, stop spreading FUD ;)
Cygwin and MinGW are the tools of choice on Win32 for compiling GIMP.

There were separate makefiles for Microsofts Visual C, but building with Cygwin's or MinGW's tools (make, gcc, ld, libtool, ...) isn't supposed to be different from building with the same tools on Unix systems. There may be limitations or bugs, but everything else is the same.

HTh, Michael

Hi,

"Michael Schumacher" writes:

Sven, stop spreading FUD ;)
Cygwin and MinGW are the tools of choice on Win32 for compiling GIMP.

Sorry. I drew conclusions on the removal of the mingw makefiles then. So mingw seems to work with the standard set of makefiles nowadays.

Sven

At 15:32 12.12.03 +0100, Michael Schumacher wrote:

Hi,

"Adam D. Moss" writes:

Out of interest, what's wrong with mingw's toolchain? I never have tried (and never will!) to build GIMP with it, but it generally copes adequately with the mildly-unix-centric codebases I throw at it.

I might be wrong since I don't compile on Win32, so perhaps I'm confusing things here. But as far as I can remember the mingw compiler needs it's own set of makefiles. There used to be such makefiles in the GIMP tree but after being unmaintained for a looong time, they have finally been removed.

Sven, stop spreading FUD ;)
Cygwin and MinGW are the tools of choice on Win32 for compiling GIMP.

There were separate makefiles for Microsofts Visual C, but building with

^^^^ [are, FUD again ?]

Cygwin's or MinGW's tools (make, gcc, ld, libtool, ...) isn't supposed to be different from building with the same tools on Unix systems. There may be limitations or bugs, but everything else is the same.

AFAIK this is not completely true. Reagrding MinGW you either need the handwritten makefile.mingw - which were in The Gimp tree until rotten too much - or a capable shell environment (either MSys or Cygwin should do).
Note: I'm trying to build The Gimp (including it's dependencies) on windoze the '*nix style' from time to time, but never managed to get so far as I do with the M$ tool chain. [Sure this is in no way representive cause I have a very strong aversion against 'portable shell scripts' and M4, aka. auto* tools - especially if they stop to work as advertised, or if the configure step takes longer than the actual package compile ;-]

Hans

-------- Hans "at" Breuer "dot" Org ----------- Tell me what you need, and I'll tell you how to get along without it. -- Dilbert

Hans Breuer wrote:

At 15:32 12.12.03 +0100, Michael Schumacher wrote:

Hi,

"Adam D. Moss" writes:

Out of interest, what's wrong with mingw's toolchain? I never have tried (and never will!) to build GIMP with it, but it generally copes adequately with the mildly-unix-centric codebases I throw at it.

I might be wrong since I don't compile on Win32, so perhaps I'm confusing things here. But as far as I can remember the mingw compiler needs it's own set of makefiles. There used to be such makefiles in the GIMP tree but after being unmaintained for a looong time, they have finally been removed.

Sven, stop spreading FUD ;)
Cygwin and MinGW are the tools of choice on Win32 for compiling GIMP.

There were separate makefiles for Microsofts Visual C, but building with

^^^^ [are, FUD again ?]

Maybe I confused the removal of the outdated makefile.mingw with the makefile.msc, or I confused this sentence when rephrasing my mail.

Cygwin's or MinGW's tools (make, gcc, ld, libtool, ...) isn't supposed to

be

different from building with the same tools on Unix systems. There may be limitations or bugs, but everything else is the same.

AFAIK this is not completely true. Reagrding MinGW you either need the handwritten makefile.mingw - which were in The Gimp tree until rotten too much - or a capable shell environment (either MSys or Cygwin should do).
Note: I'm trying to build The Gimp (including it's dependencies) on windoze the '*nix style' from time to time, but never managed to get so far as I do with the M$ tool chain.

Well, as both packages are available from the same site, I think no one will try to use the MinGW package alone.

BTW, http://wiki.gimp.org/gimp/HowToCompileGimp/MicrosoftWindows
The Cygwin user didn't have any problems at all after the dependecies were installed.

[Sure this is in no way representive cause I have a very strong aversion against 'portable shell scripts' and M4, aka. auto* tools - especially if they stop to work as advertised, or if the configure step takes longer than the actual package compile ;-]

So this makes you prefer software from a big & evil company - strange logic ;)

Michael

On Sat, Dec 13, 2003 at 04:19:44PM +0100, Hans Breuer wrote:

- especially if they stop to work as advertised, or if the configure step takes longer than the actual package compile ;-]

which is a severe shortcoming of the build environment (AFAIK, Msys uses cygwin which is awfully slow due to a large number of reasons). On any non-m$ unix, the configure script works reasonably quickly. Maybe some of the commercial unix packages for windows would run them faster, too...

(Or maybe the compilers are so much slower, but I'd disagree with that)

Hi,

writes:

which is a severe shortcoming of the build environment (AFAIK, Msys uses cygwin which is awfully slow due to a large number of reasons).

This sounds like if you had a clue on what is causing the slowliness of running configure on Cygnus. I recently compiled the Blinkenlights software on Windows and noticed this shortcoming as well. I wondered what might be the cause and if there are ways to work around it. Are there any?

Sven

Sven Neumann writes:

Hi,

writes:

which is a severe shortcoming of the build environment (AFAIK, Msys uses cygwin which is awfully slow due to a large number of reasons).

MSYS does not depend on cygwin, BTW. It's entirely standalone. They both have to implement fork() using Windows calls though, which can never be efficient.

This sounds like if you had a clue on what is causing the slowliness of running configure on Cygnus. I recently compiled the Blinkenlights software on Windows and noticed this shortcoming as well. I wondered what might be the cause and if there are ways to work around it. Are there any?

From what I've observed, it's mostly due to a very slow implementation

of fork(). It takes well over a second per fork, so gcc is slow due to forking the compiler, preprocessor, assembler, collect2 etc. configure is even slower (it takes over half an hour to run the gimp-print configure script, c.f. 20 secs on Linux) since it forks over 5000 processes.

Sven Neumann wrote:

which is a severe shortcoming of the build environment (AFAIK, Msys uses cygwin which is awfully slow due to a large number of reasons).

This sounds like if you had a clue on what is causing the slowliness of running configure on Cygnus. I recently compiled the Blinkenlights software on Windows and noticed this shortcoming as well. I wondered what might be the cause and if there are ways to work around it. Are there any?

As a data point, I use a (optimized build) mingw cross-compiler hosted on linux, and the raw compilation itself takes a lot longer (50% longer, or more) than the same compiler version built for a native-compile. I really don't know why that would be. The only thing I can think of would be if the //etc headers that get pulled into just about every file on a win32 build expand into monsterous evil and add measurably to the unit compilation time.

--Adam

On Sun, Dec 14, 2003 at 12:46:54PM +0100, Sven Neumann wrote:

This sounds like if you had a clue on what is causing the slowliness of running configure on Cygnus.

The biggest reason is very slow fork(), followed by extremely slow select(), filehandle operations, pipes and much more.

Basically, windows makes it very difficult to do simple things, for example, there is no way to simply wait for events, every type of object needs a different waiting paradigm. So to use select, cygwin has to start threads per type of filehandle etc... you can imagine how slow that becomes.

And fork is simply not window's model of managing processes (instead you use CreateProcess with 10 arguments...).

Windows isn't based on an efficient process model. If you want to do "IPC", you 'simply' load a dll into your memory area and start some threads (which is being called "ActiveX" in the hipper areas of this world). Real IPC is slow, and not really meant to be used.

Since configure scripts use fork() and IPC a lot, that's why it's slow.

software on Windows and noticed this shortcoming as well. I wondered what might be the cause and if there are ways to work around it. Are there any?

Cygwin tries to be correct first, fast second. I don't think there is any workaround, as it's not really a bug that could be workarounded. One could sacrifice posix compatibility to some degree to get faster, but configure scripts will likely always be slow, even if e.g. the sus spawn facilities are being used.

One "workaround" would be to link in most shell-utilities into your shell, that would certainly help, to some extent, but don't expect wonders.

This is being written by somebody who doesn't think very highly of the windows API, keep that in mind :) I am convinced that the major reason for bad software under windows is the extremely complicated, overloaded and non-orthogonal API.

On Sun, Dec 14, 2003 at 01:08:20PM +0000, "Adam D. Moss" wrote:

As a data point, I use a (optimized build) mingw cross-compiler hosted on linux, and the raw compilation itself takes a lot longer (50% longer, or more) than the same compiler version built

That's interesting, but fortunately way better than the time configure takes.

Preprocessing is indeed a nontrivial compiler phase, but especially with gcc-3, I would not have expected that to make a 50% difference.

It could be that for some reason math emulation is enabled because it's a cross compiler build, but since the architecture is the same I wouldn't expect that. Still, my area of gcc expertise isn't in that area, so I would have to research that :)

Still, 50% is a lot to be explained by mere monstrous include files. Maybe someone should profile it *g*

Adam D. Moss writes:
> The only thing I can think of would be if the > //etc headers that get pulled into just about > every file on a win32 build expand into monsterous evil and add > measurably to the unit compilation time.

Well, that probably is the reason. *is* quite large. But none of the GLib headers, and none of the normal GTK headers include it, so it shouldn't get included by most compilations units in typical GTK software. Software written for Windows from scratch typically tend to include in every file, though.

But I don't think the actual time it takes to run gcc is what annoys people most when building stuff that uses auto*/libtool on Windows. For me, the most annoying part is libtool. This shell-script is mind-bogglingly slow. Running a configure script isn't exactly fast either, but you don't have to to that so often, and you can always catch up on your mail while configure is running, or something. But having to wait for libtool to figure out for the nth time how to invoke gcc is quite infuriating while you are in a test-edit-compile cycle.

(For people used to MSVC, gcc's speed as such might also be an issue. I don't remember any numbers, but I think MSVC compiles several times faster.)

--tml

Roger Leigh writes:
> MSYS does not depend on cygwin, BTW. It's entirely standalone.

MSYS is a *fork* (version) of Cygwin. As the mingw FAQ says, "The POSIX layer used by MSYS is a fork of the 1.3.3 version of Cygwin". (But maybe that was what you meant.)

> They both have to implement fork() using Windows calls though, > which can never be efficient.

(Just rambling here:)

I wonder, could the typical fork() immeditaly followed by exec() (in the child process) be somehow detected by Cygwin/MSYS, avoiding the need for emulating the full fork() semantics in this typical case?

Hmm, the fork() implementation would probably have to peek at the executable code following the fork() call, see if it branches on the return value from fork(), check if the return-value-was-zero branch then immediately calls some of the exec() functions, and in that case bypass some slow stuff? Nah, doesn't sound easy.

--tml

On Sun, Dec 14, 2003 at 05:13:30PM +0000, Tor Lillqvist wrote:

Roger Leigh writes:
> They both have to implement fork() using Windows calls though, > which can never be efficient.

(Just rambling here:)

I wonder, could the typical fork() immeditaly followed by exec() (in the child process) be somehow detected by Cygwin/MSYS, avoiding the need for emulating the full fork() semantics in this typical case?

That's what vfork() is for, though maybe bash can't use it because of subshells, etc.

-Yosh

On Sun, Dec 14, 2003 at 04:57:15PM +0000, Tor Lillqvist wrote:

But I don't think the actual time it takes to run gcc is what annoys people most when building stuff that uses auto*/libtool on Windows. For me, the most annoying part is libtool. This shell-script is mind-bogglingly slow. Running a configure script isn't exactly fast either, but you don't have to to that so often, and you can always catch up on your mail while configure is running, or something. But having to wait for libtool to figure out for the nth time how to invoke gcc is quite infuriating while you are in a test-edit-compile cycle.

Yes, libtool is stupid. There's no reason it needs to be run on every compile command, rather than inserting it precalculated at Makefile build time.

I wished they didn't put in the win32 stuff actually. It really should be a separate script entirely supporting the same interface, so people only have to parse and run half the shell script size.

(For people used to MSVC, gcc's speed as such might also be an issue. I don't remember any numbers, but I think MSVC compiles several times faster.)

Yeah, gcc is quite slow at compile time, and I think in newer versions it's gotten slower, not faster.

-Yosh

On Sun, Dec 14, 2003 at 09:29:07AM -0800, Manish Singh wrote:

Yeah, gcc is quite slow at compile time, and I think in newer versions it's gotten slower, not faster.

From the gcc3.4 changes.html:

* Precompiled headers are now supported. Precompiled headers can dramatically speed up compilation of some projects. There are some restrictions; read the manual for the details.
(...)
* Substantial improvements in compile time have been made, particularly for non-optimizing compilations.

I'm not sure how easy it would be to use pch in The GIMP, but at least the second item should mean that gcc is on the right track again :-)

/* Steinar */

On Sun, Dec 14, 2003 at 12:46:27PM +0000, Roger Leigh wrote:

MSYS does not depend on cygwin, BTW. It's entirely standalone.

Why do you claim this if a few simple checks could have convinced you otherwise? At least the shell, which is just bash, is linked against the cygwin lib.... This makes sense, too, because why would you want to duplicate work for no apperent gain?

Anyways, forking speed is not the full story, as bash and gcc usually take advantage of the spawn functions, which don't incur the overhead of fork.

Of course, what's quite sure is that it's dog-slow, no matter what, and there is no workaround in sight, unless somebody radically changes the design of configure.

On Sun, Dec 14, 2003 at 05:13:30PM +0000, Tor Lillqvist wrote:

I wonder, could the typical fork() immeditaly followed by exec() (in the child process) be somehow detected by Cygwin/MSYS, avoiding the need for emulating the full fork() semantics in this typical case?

No, but common software like bash has been modified to use the posix spawn functions, which _are_ streamlined on cygwin.

Starting processes is still very, very heavyweight under windows. No doubt the large startup overhead of cygwin executables just adds to this.