Re: [Gimp-developer] Re: [CinePaint-dev] GIMP GBR format spec
On Thu, Jul 10, 2003 at 04:08:21PM +0200, Sven Neumann [EMAIL PROTECTED] wrote: in such an approach and I am sure that not many XML parsers will like CDATA blocks of several megabytes. _all_ xml parsers cope with cdata blocks of several megabytes. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] MMX in 1.3 tree
On Thu, Jul 10, 2003 at 01:17:49PM +0200, Sven Neumann [EMAIL PROTECTED] wrote: __asm__ __volatile__ () while the new code in The GIMP seems to be using asm() I don't know this stuff good enough to know the difference, but I'd __keyword__-style keywords are always there, even if gcc extensions should be disabled (strict ansi mode etc.. volatile means that there are side effects that are not (or can not) be properly specified. unless you write a kernel or other arcane magic, the need to use volatile indicates a bug in the constraints (i.e. forgetting to tell the compiler properly about the effects of the statement). for example, gcc will happily optimize away an asm() if the output operands aren't used, as it can then assume that the computing isn't necessary. volatile will keep it from doing that, but that might also keep useful optimizations from doing their work. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] MMX in 1.3 tree
On Fri, Jul 11, 2003 at 12:52:08AM +0200, David Neary wrote: asm(movq %0, %%mm1 : : m(rgba8_alpha_mask) : %mm1); breaks on the second %mm1; I don't think there should be a % in the list of clobbered registers. What's worse, I don't even think most versions of gcc know about MMX registers at all (I might be mistaken, though :-) ) and thus you'd need to simply clobber the entire FPU stack (which the MMX registers get aliased upon). /* Steinar */ -- Homepage: http://www.sesse.net/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] MMX in 1.3 tree
On Fri, Jul 11, 2003 at 12:13:29PM +0200, Steinar H. Gunderson [EMAIL PROTECTED] wrote: I don't think there should be a % in the list of clobbered registers. yupp, there is no %mm1 register :) worse, I don't even think most versions of gcc know about MMX registers at versions 2.x (usually) don't know them, versions 3.x generally do know them. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] the user installer
On Wed, Jul 09, 2003 at 06:48:08PM +0200, Sven Neumann [EMAIL PROTECTED] wrote: users. The dialog is great and much better than a html help page for example, but it's presented at a time people will have no clue what it means. Perhaps we should show it on every startup then ? It's setting preferences, so it quite naturally could be accessible from the preferences. I always wondered why I get this nice fancy wizards only on configuration, but when I later want to change these values I need to set them using a totally different interface (while the installer is s much cooler and nicer :) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: [CinePaint-dev] GIMP GBR format spec
At 12:04 PM +0200 7/11/03, Marc wrote: On Thu, Jul 10, 2003 at 04:08:21PM +0200, Sven Neumann [EMAIL PROTECTED] wrote: in such an approach and I am sure that not many XML parsers will like CDATA blocks of several megabytes. _all_ xml parsers cope with cdata blocks of several megabytes. But the fact is that you're going to end up having to Base64 encode all the image data - which will blow the physical file size WAY out of proportion. And if don't do that (ie. attempt to leave in binary data), then you are violating the spirit of XML's design goals. Leonard -- --- Leonard Rosentholmailto:[EMAIL PROTECTED] http://www.lazerware.com ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: [CinePaint-dev] GIMP GBR format spec
Hi, Leonard Rosenthol [EMAIL PROTECTED] writes: But the fact is that you're going to end up having to Base64 encode all the image data - which will blow the physical file size WAY out of proportion. And if don't do that (ie. attempt to leave in binary data), then you are violating the spirit of XML's design goals. That's why we dropped the idea of embedding the image data in XML. XML is very well suited to describe the structure of a multi-layered, multi-framed image/animation and it can be used perfectly to embed meta information as well as vector layers, paths and the like. XML namespaces make it easy to add application-specific extensions later. As you can see, the format I imagine here is not really GIMP specific. It could serve as a general exchange format for complex images. We discussed to bundle one XML file with a set of files that store the image data. These files would preferably be known image formats or perhaps even strict subsets of known image formats. That could be PNG for example but I'm not sure if PNG would suit our needs for higher bitdepths and the like. Most likely we will need a different format for the actual image data. I would suggest that these files are then put together in an ar archive. Such an uncompressed archive has the advantage that the XML metadata can easily be extracted. As you can see all this is very rough and not clearly layed out. It's a vague idea and it will need a lot of work to specify such a format in detail. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] MMX in 1.3 tree
On Fri, 11 Jul 2003, Steinar H. Gunderson wrote: On Fri, Jul 11, 2003 at 12:52:08AM +0200, David Neary wrote: I don't think there should be a % in the list of clobbered registers. What's worse, I don't even think most versions of gcc know about MMX registers at all (I might be mistaken, though :-) ) and thus you'd need to simply clobber the entire FPU stack (which the MMX registers get aliased upon). How hard would it be to write an autoconf test for that? Rockwlrs ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: [CinePaint-dev] GIMP GBR format spec
On Fri, 11 Jul 2003, Leonard Rosenthol wrote: But the fact is that you're going to end up having to Base64 encode all the image data - which will blow the physical file size WAY out of proportion. And if don't do that (ie. attempt to leave in binary data), then you are violating the spirit of XML's design goals. Honestly I can't think of a way to put image data into a file format at all that wouldn't violate SGML's design goals. XML may differ in some aspects from SGML, but the fact is that SGML was designed to be a markup language for documents written in human languages, and the design decisions that created that also make storing binary in *ML cumbersome. GIMP needs a file format that is extensible, and a native representation for tree structures is essential, but there are plenty of ways to do this other than the XML method. Storing images, which ar almost all binary data, in true XML is a lesson in inefficiency. Oh wait, I take it back. I can think of a image format that retains the spirit of XML: gimpimage commentCreated by the GIMP!/commment layers colorspace=rgb bitdepth=8 layer width=6 height=6 row pixel r=127 g=127 b=127 / pixel r=127 g=127 b=127 / pixel r=127 g=127 b=127 / pixel r=127 g=127 b=127 / pixel r=127 g=127 b=127 / pixel r=127 g=127 b=127 / /row row . . . /row /layer /layers /gimpimage Determining whether this is a good format is left as an exercise to the reader. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP GBR format spec
At 02:34 PM 7/11/2003 +0200, Sven Neumann wrote: XML is very well suited to describe the structure of a multi-layered, multi-framed image/animation and it can be used perfectly to embed meta information as well as vector layers, paths and the like. XML namespaces make it easy to add application-specific extensions later. You bet! We discussed to bundle one XML file with a set of files that store the image data. These files would preferably be known image formats or perhaps even strict subsets of known image formats. Agreed. I would suggest that these files are then put together in an ar archive. Such an uncompressed archive has the advantage that the XML metadata can easily be extracted. You just described a JAR file, which is not unlike the OpenOffice file format ;). A JAR is a special type of ZIP archive, which contains one or more data files along with an XML manifest about the contents. I've worked on a number of projects (both commercial and open) that have used such a format - it works quite nicely and is compatible with existing tools and technologies. Always better than reinventing the wheel!! I think the approach of a JAR-like file for the future GIMP (and possibly CinePaint) file format is an excellent choice and allows for many avenues of expansion. Leonard ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: [CinePaint-dev] GIMP GBR format spec
At 06:34 AM 7/11/2003 -0700, Nathan Carl Summers wrote: Oh wait, I take it back. I can think of a image format that retains the spirit of XML: gimpimage commentCreated by the GIMP!/commment layers colorspace=rgb bitdepth=8 layer width=6 height=6 row pixel r=127 g=127 b=127 / pixel r=127 g=127 b=127 / pixel r=127 g=127 b=127 / pixel r=127 g=127 b=127 / pixel r=127 g=127 b=127 / pixel r=127 g=127 b=127 / You know what is really scary about that... About 6 months ago, someone posted to the SVG mailing list a proposal for an XML-based raster image format that pretty much exactly that...And he was SERIOUS about it!!! Leonard ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP GBR format spec
On Fri, Jul 11, 2003 at 10:08:55AM -0400, Leonard Rosenthol [EMAIL PROTECTED] wrote: A JAR is a special type of ZIP archive, which contains one or more data files along with an XML manifest about the contents. I've worked on a number of projects (both commercial and open) that have used such a format - it works quite nicely and is compatible with existing tools and technologies. Always better than reinventing the wheel!! the ar file format is much better established then jar, quick to access (unlike jar), and very very very much simpler. a complex container format like jar is not very helpful, as the added complexity just gets in the way (we just need to bundle files...) I think the approach of a JAR-like file for the future GIMP (and possibly CinePaint) file format is an excellent choice and allows for many avenues of expansion. i think jar-like is backwards. tar-like is much better (but tar itself is unsuitable due to the lack of rigid definitions and a multitude of different formats, the same is true for cpio). -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
