From cworth at east.isi.edu Thu Jul 3 07:53:38 2003 From: cworth at east.isi.edu (Carl Worth) Date: Mon Aug 15 11:10:43 2005 Subject: [Xr] Anybody there? In-Reply-To: References: <200306280554.h5S5s9DK005594@hermes.d2.com> Message-ID: <16132.17266.672647.133018@scream.east.isi.edu> On Jun 27, Keith Packard wrote: > Around 22 o'clock on Jun 27, Bill Spitzak wrote: > > > > Am I still on this list? Did everybody just stop working on Xr? > > Looks like you're still here. Work on Xr has been sidetracked for a > while; I'm still here. Though Keith is right about my being sidetracked. I've been traveling far too much this summer. On the other hand, I'm starting to feel pretty good about core drawing capability (paths) in Xr right now. For the most part, the API is clean and easy to use and the implementation works, (though it could use some optimization of course). Text is basically not handled yet so that still needs to be done of course. Beyond that, what's really needed to improve Xr is to get some feedback. I'd be very interested to hear from people who have tried using Xr in a non-trivial way, (eg. using it to support drawing within a toolkit or a significant application). Feedback from experience like that is quite useful. (Some feedback has already come in -- thanks for the comments!). > Carl wrote a nifty Ricochet Robots client using Gtk+ and Xsvg/Xr/Xc > which demonstrates how those parts work together. You can see that > in CVS at keithp.com (librr and grrobot). The grr_board_view.c file contains an example of how to make a custom GTK+ widget that draws itself using Xr, (and xsvg), so that may be useful to look at. -Carl From cworth at east.isi.edu Thu Jul 3 08:23:15 2003 From: cworth at east.isi.edu (Carl Worth) Date: Mon Aug 15 11:10:43 2005 Subject: [Xr] XrMatrixGetAffine() function In-Reply-To: <1054832189.3523.25.camel@dolphin.calgary.verano.com> References: <1054832189.3523.25.camel@dolphin.calgary.verano.com> Message-ID: <16132.19043.756527.126007@scream.east.isi.edu> On Jun 5, Soorya Kuloor wrote: > Here is a patch that adds XrMatrixGetAffine() function to Xr. Thanks, I've now applied this (finally). Sorry about the long wait. -Carl From cworth at east.isi.edu Thu Jul 3 08:24:58 2003 From: cworth at east.isi.edu (Carl Worth) Date: Mon Aug 15 11:10:43 2005 Subject: [Xr] API questions In-Reply-To: <1055082741.21800.5.camel@pouirt> References: <1055082741.21800.5.camel@pouirt> Message-ID: <16132.19146.40936.749260@scream.east.isi.edu> On Jun 8, Damien Genet wrote: > I just started to learn Xr, and I'm wondering why doesn't XrSetAlpha, > and XrSetRGBColor have their XrGet* counterpart, like most other XrSet* > functions ? When I added the other XrGet* functions I thought I would be changing the color API functions very quickly to use a new XrColor object. See: http://xwin.org/pipermail/xr/2003-May/000043.html As it turns out, the solution for color support was not so obvious, and I haven't introduced an XrColor object yet. For now, I've gone ahead and added XrGetAlpha and XrGetRGBColor. > Do you also intend to offer non RGB color spaces ? The consensus seems to be to support only the sRGB color space and pushing any other color space manipulation up to higher levels. I'm no expert in dealing with color spaces, but I'm accepting that recommendation from those who know more than me. -Carl From keithp at keithp.com Thu Jul 3 10:25:15 2003 From: keithp at keithp.com (Keith Packard) Date: Mon Aug 15 11:10:43 2005 Subject: [Xr] API questions In-Reply-To: Your message of "Thu, 03 Jul 2003 11:24:58 EDT." <16132.19146.40936.749260@scream.east.isi.edu> Message-ID: Around 11 o'clock on Jul 3, Carl Worth wrote: > The consensus seems to be to support only the sRGB color space and > pushing any other color space manipulation up to higher levels. I'm no > expert in dealing with color spaces, but I'm accepting that > recommendation from those who know more than me. For those concerned about gamut, it's important to note that the Xr APIs accept floating point color values and that these values can be negative. While something of a kludge, this will at least provide a representation for colors outside the gamut of the non-negative sRGB space. Of course, this would require a new representation of the pixels within Xr, but that is less important at this point than getting the API right. -keith From spitzak at d2.com Thu Jul 3 10:44:52 2003 From: spitzak at d2.com (Bill Spitzak) Date: Mon Aug 15 11:10:43 2005 Subject: [Xr] API questions In-Reply-To: References: Message-ID: <200307031741.h63HfADK001329@hermes.d2.com> On Thursday 03 July 2003 10:25 am, Keith Packard wrote: > Around 11 o'clock on Jul 3, Carl Worth wrote: > > The consensus seems to be to support only the sRGB color space and > > pushing any other color space manipulation up to higher levels. I'm no > > expert in dealing with color spaces, but I'm accepting that > > recommendation from those who know more than me. > > For those concerned about gamut, it's important to note that the Xr APIs > accept floating point color values and that these values can be negative. > While something of a kludge, this will at least provide a representation > for colors outside the gamut of the non-negative sRGB space. Of course, > this would require a new representation of the pixels within Xr, but that > is less important at this point than getting the API right. My suggestion is that the exact results for out-of-gamut colors is implementation-dependent. This will allow Xr or Xrender to turn the colors into internal representation without breaking the spec. Also whether "get" returns the exact same value sent to "set" is also implementation dependent, though it should be true that if you "get" a value, use that to "set" the color, and "get" it again, you will get the exact same result. This is to allow implementations to store only the internal representation of color, but not require it. Even though it sounds primitive, I would really like to see an 8-bit/color interface added, like XrSetColor32(u32 color). This would take a number 0xRRGGBBAA to specify the rgba. The reason for such an interface is that is the way the vast majority of applications are storing color for GUI and also how most current devices represent color, and this interface avoids the overhead of converting to float and back. I don't think an equivalent "get" function is needed. -- ,~,~,~,~ ~ ~ ~ ~ /\_ _|_========___ Bill Spitzak ~~~/\/\\~~~~~~\____________/~~~~~~~~ spitzak@d2.com From keithp at keithp.com Thu Jul 3 10:50:11 2003 From: keithp at keithp.com (Keith Packard) Date: Mon Aug 15 11:10:43 2005 Subject: [Xr] API questions In-Reply-To: Your message of "Thu, 03 Jul 2003 10:44:52 PDT." <200307031741.h63HfADK001329@hermes.d2.com> Message-ID: Around 10 o'clock on Jul 3, Bill Spitzak wrote: > Even though it sounds primitive, I would really like to see an 8-bit/color > interface added, like XrSetColor32(u32 color). This would take a number > 0xRRGGBBAA to specify the rgba. Many applications use a format something like that, but the precise representation differs and there is disagreement on whether the RGB values should be premultiplied. Xr sidesteps the whole premultiplied alpha issue by having separate interfaces... -keith From skuloor at verano.com Thu Jul 3 11:03:56 2003 From: skuloor at verano.com (Soorya Kuloor) Date: Mon Aug 15 11:10:43 2005 Subject: [Xr] XrMatrixGetAffine() function In-Reply-To: <16132.19043.756527.126007@scream.east.isi.edu> References: <1054832189.3523.25.camel@dolphin.calgary.verano.com> <16132.19043.756527.126007@scream.east.isi.edu> Message-ID: <1057255436.3968.54.camel@dolphin.calgary.verano.com> Hi Carl, Nice to hear back from you :-)). Thanks for applying the patch. The Xr drawing stuff seems to be holding up well for all the tests that we have done so far. However, here are some observations: * Text handling does not seem to be as good as the rest of the drawing, both API and speed-wise. It seems to be a bit slow, compared to other packages (eg. GDI+ on Windows, 8000 strings/sec vs 1500/sec). Especially, the initial query for a given font-transform combination seems to take long time too (the call into fontconfig). * I am getting to a point where XrClipRectangle() would help a lot. This helps especially for partial fills. Are you planning on implementing XrClipRectangle? If not, I'll have some time to do this in a week or so. I have gone through all the Xr/Xc code and have a vague idea as to how to do this. * We did a speed comparison of Xr against GDI+. For the ellipse drawing test (posted by Owen) with anti-aliasing GDI+ is approx 2-2.5 times faster than Xr. So there is still a lot of room for acceleration in Xr. I am still working on my 'benchmarking' program and to do profiling on it. Once I have some solid results I'll post them here. -- Soorya On Thu, 2003-07-03 at 09:23, Carl Worth wrote: > On Jun 5, Soorya Kuloor wrote: > > Here is a patch that adds XrMatrixGetAffine() function to Xr. > > Thanks, I've now applied this (finally). > > Sorry about the long wait. > > -Carl > > _______________________________________________ > Xr mailing list > Xr@xwin.org > http://xwin.org/cgi-bin/mailman/listinfo/xr From keithp at keithp.com Thu Jul 3 11:16:47 2003 From: keithp at keithp.com (Keith Packard) Date: Mon Aug 15 11:10:43 2005 Subject: [Xr] XrMatrixGetAffine() function In-Reply-To: Your message of "03 Jul 2003 12:03:56 MDT." <1057255436.3968.54.camel@dolphin.calgary.verano.com> Message-ID: Around 12 o'clock on Jul 3, Soorya Kuloor wrote: Thanks very much for your comments: > * Text handling does not seem to be as good as the rest of the drawing, > both API and speed-wise. This is well known -- Xr is attempting to use Xft for text rendering and the result is quite horrible. I'm hoping to get a chance to write down some ideas I've been mulling over to see if we can't start afresh and build something that better matches the Xr style and can be implemented efficiently. > Especially, the initial query for a given font-transform combination > seems to take long time too (the call into fontconfig). Pango caches the results to make future queries faster, but fontconfig itself is not likely to improve dramatically in the near future. Drawing the text will get a lot faster as we get a chance to optimize the underlying compositing routines. > * We did a speed comparison of Xr against GDI+. For the ellipse drawing > test (posted by Owen) with anti-aliasing GDI+ is approx 2-2.5 times > faster than Xr. That's actually very encouraging -- none of the Xr rendering codepaths have seen any optimization at all, and the trapezoid filling code is already scheduled for a complete rewrite which should make it a lot faster. Combine that with optimizations in the compositng code and the tesselation code and getting a factor of 2 in performance should be very easy. -keith From skuloor at verano.com Thu Jul 3 13:19:18 2003 From: skuloor at verano.com (Soorya Kuloor) Date: Mon Aug 15 11:10:43 2005 Subject: [Xr] XrMatrixGetAffine() function In-Reply-To: References: Message-ID: <1057261891.6721.31.camel@dolphin.calgary.verano.com> On Thu, 2003-07-03 at 12:16, Keith Packard wrote: > Around 12 o'clock on Jul 3, Soorya Kuloor wrote: > > Thanks very much for your comments: > > > * Text handling does not seem to be as good as the rest of the drawing, > > both API and speed-wise. > > This is well known -- Xr is attempting to use Xft for text rendering and > the result is quite horrible. I'm hoping to get a chance to write down > some ideas I've been mulling over to see if we can't start afresh and > build something that better matches the Xr style and can be implemented > efficiently. > Great to hear that. In real time SCADA type of displays (we are using Xr for this) text updates are done very frequently and we found that in Xr text drawing takes up a significant portion of the update time. So this slows down things. > > Especially, the initial query for a given font-transform combination > > seems to take long time too (the call into fontconfig). > > Pango caches the results to make future queries faster, but fontconfig > itself is not likely to improve dramatically in the near future. > > Drawing the text will get a lot faster as we get a chance to optimize the > underlying compositing routines. > > > * We did a speed comparison of Xr against GDI+. For the ellipse drawing > > test (posted by Owen) with anti-aliasing GDI+ is approx 2-2.5 times > > faster than Xr. > > That's actually very encouraging -- none of the Xr rendering codepaths > have seen any optimization at all, and the trapezoid filling code is > already scheduled for a complete rewrite which should make it a lot > faster. Combine that with optimizations in the compositng code and the > tesselation code and getting a factor of 2 in performance should be very > easy. > Yes, I was surprised to see this too. I would have guessed GDI+ would be much faster than this with all the hardware acceleration MS might have put into it. However, these timings are just on one machine. I also wrote a test program that strokes and fills 600 ellipses (attached below) and did a runtime profiling using valgrind. Here are the screenshots of the profiling info (obtained using kcachegrind). The first image cpuprof-1.jpg shows runtimes sorted based on self timing and the other based on cumulative timings. I could not make kcachegrind to dump to a file, so I am including screenshots. The test used an X server with Render extension (Redhat 9, NVIDIA accelerated driver with RenderAccel on). Approx. 34.5% time is used by memcpy for sorting edge lists during tesselation. Speeding up some of these parts (as you mentioned above) for sure should sppedup Xr a lot. -- Soorya > > -keith > > > > _______________________________________________ > Xr mailing list > Xr@xwin.org > http://xwin.org/cgi-bin/mailman/listinfo/xr From dforste at arbornet.org Thu Jul 3 14:42:57 2003 From: dforste at arbornet.org (David Forster) Date: Mon Aug 15 11:10:43 2005 Subject: [Xr] API questions In-Reply-To: <200307031741.h63HfADK001329@hermes.d2.com> References: <200307031741.h63HfADK001329@hermes.d2.com> Message-ID: <20030703214257.GA23207@crateria.homeunix.net> On Thu, Jul 03, 2003 at 10:44:52AM -0700, Bill Spitzak wrote: > My suggestion is that the exact results for out-of-gamut colors is > implementation-dependent. This will allow Xr or Xrender to turn the colors > into internal representation without breaking the spec. I think this would be a mistake. If Xr is to be a serious API for rendering to both CRT/LCDs and printers, then Xr is going to have to get color management right. There's no way around it. If it doesn't, then it'll just get replaced by someone who's willing to do it right. The point of abstracting away the hardware is so that developers can write their rendering code _once_. The same code used to render a document (like say a vector/raster image) to the screen can be reused to print that document out. If you don't define what the out-of-bounds sRGB values mean, then the developer is going to have to take over color management, and that means hardware dependence. And with Xr already correcting values for sRGB it will be nothing short of a mess. One might just as well use Xr for screen output and PostScript for printer output.. If I where doing this --- and let me say I'm certainly no expert on this subject, so this is all in my humble opinion --- I would bite the bullet and provide support for both, say, esRGB (or like expanded sRGB color space) and CIEXYZ. Color management would be handled by some unspecified means by Xr. It doesn't have to actually do a good job at this early stage, but the API should get it right. So one would have: void XrSetRenderingIntent(XrState *xrs, XrIntent intent); void XrSetESRGBColor(XrState *xrs, double red, double green, double blue); void XrSetCIEXYZColor(XrState *xrs, double x, double y, double z); and for pixmaps there would be appropraite XrFormatSRGB*, XrFormatESRGB*, and XrFormatCIEXYZ* formats. The user will then be totally isolated from the underlying hardware, and should have enough control for ``pro-sumer'' output if not professional ouput (but again, I'm not an expert). There would be no hardware dependent color formats available. Note that I'm only using esRGB as an example. I haven't really looked into what would be the best OOB sRGB color space... > Even though it sounds primitive, I would really like to see an 8-bit/color > interface added, like XrSetColor32(u32 color). This would take a number > 0xRRGGBBAA to specify the rgba. The reason for such an interface is that is > the way the vast majority of applications are storing color for GUI and also > how most current devices represent color, and this interface avoids the > overhead of converting to float and back. I don't think an equivalent "get" > function is needed. If you're doing color management the value isn't going to get passed straight on anyways. The overhead of INT->FLOAT->INT is negligible for individual colors...even less if you just store things as floats to begin with. For dealing with pixmaps there is already support for INT color formats. I don't see as this would really impact performance in any meaningful way. I think it would just cruft up the API... Just IMHO, though, -Dave From spitzak at d2.com Thu Jul 3 16:21:56 2003 From: spitzak at d2.com (Bill Spitzak) Date: Mon Aug 15 11:10:43 2005 Subject: [Xr] Anybody there? In-Reply-To: <16132.17266.672647.133018@scream.east.isi.edu> References: <200306280554.h5S5s9DK005594@hermes.d2.com> <16132.17266.672647.133018@scream.east.isi.edu> Message-ID: <200307032318.h63NIDDK022065@hermes.d2.com> On Thursday 03 July 2003 07:53 am, Carl Worth wrote: > Beyond that, what's really needed to improve Xr is to get some > feedback. I'd be very interested to hear from people who have tried > using Xr in a non-trivial way, (eg. using it to support drawing within > a toolkit or a significant application). Feedback from experience like > that is quite useful. (Some feedback has already come in -- thanks for > the comments!). I am currently stumped as the better machines I have access to do not have the newest X11 on them and so Xr does not compile. Since this is for testing and debugging I really don't care how slow it is, so I was wondering if it is possible to compile Xr so that it only supports local memory map drawing and does not attempt to use Xrender and does not use Xrender header files. This may also be useful for getting Xr to work on that "other" operating system. -- ,~,~,~,~ ~ ~ ~ ~ /\_ _|_========___ Bill Spitzak ~~~/\/\\~~~~~~\____________/~~~~~~~~ spitzak@d2.com From spitzak at d2.com Thu Jul 3 16:23:29 2003 From: spitzak at d2.com (Bill Spitzak) Date: Mon Aug 15 11:10:43 2005 Subject: [Xr] Anybody there? In-Reply-To: References: Message-ID: <200307032319.h63NJkDK023171@hermes.d2.com> On Friday 27 June 2003 11:15 pm, Keith Packard wrote: > And, the big problem we've got right now is the name -- Xr/Xc are both > cross platform rendering libraries but their names are causing quite a bit > of confusion. If anyone has suggestions for what we might call the > libraries (long names are OK), we should take this opportunity to get the > library function prefixes changed before people start moving them into > real application environments. I think the "Xr" name is very good and everybody is calling it that already. Tell the Windows people it is "like Direct-X for non-games, that is why it is called xr". -- ,~,~,~,~ ~ ~ ~ ~ /\_ _|_========___ Bill Spitzak ~~~/\/\\~~~~~~\____________/~~~~~~~~ spitzak@d2.com From skuloor at verano.com Thu Jul 3 13:21:45 2003 From: skuloor at verano.com (Soorya Kuloor) Date: Mon Aug 15 11:10:43 2005 Subject: [Xr] XrMatrixGetAffine() function In-Reply-To: <1057261891.6721.31.camel@dolphin.calgary.verano.com> References: <1057261891.6721.31.camel@dolphin.calgary.verano.com> Message-ID: <1057263705.3806.1.camel@dolphin.calgary.verano.com> Yikes, forgot to attach files. -- Soorya On Thu, 2003-07-03 at 14:19, Soorya Kuloor wrote: > On Thu, 2003-07-03 at 12:16, Keith Packard wrote: > > Around 12 o'clock on Jul 3, Soorya Kuloor wrote: > > > > Thanks very much for your comments: > > > > > * Text handling does not seem to be as good as the rest of the drawing, > > > both API and speed-wise. > > > > This is well known -- Xr is attempting to use Xft for text rendering and > > the result is quite horrible. I'm hoping to get a chance to write down > > some ideas I've been mulling over to see if we can't start afresh and > > build something that better matches the Xr style and can be implemented > > efficiently. > > > > Great to hear that. In real time SCADA type of displays (we are using Xr > for this) text updates are done very frequently and we found that in Xr > text drawing takes up a significant portion of the update time. So this > slows down things. > > > > Especially, the initial query for a given font-transform combination > > > seems to take long time too (the call into fontconfig). > > > > Pango caches the results to make future queries faster, but fontconfig > > itself is not likely to improve dramatically in the near future. > > > > Drawing the text will get a lot faster as we get a chance to optimize the > > underlying compositing routines. > > > > > * We did a speed comparison of Xr against GDI+. For the ellipse drawing > > > test (posted by Owen) with anti-aliasing GDI+ is approx 2-2.5 times > > > faster than Xr. > > > > That's actually very encouraging -- none of the Xr rendering codepaths > > have seen any optimization at all, and the trapezoid filling code is > > already scheduled for a complete rewrite which should make it a lot > > faster. Combine that with optimizations in the compositng code and the > > tesselation code and getting a factor of 2 in performance should be very > > easy. > > > > Yes, I was surprised to see this too. I would have guessed GDI+ would be > much faster than this with all the hardware acceleration MS might have > put into it. However, these timings are just on one machine. > > I also wrote a test program that strokes and fills 600 ellipses > (attached below) and did a runtime profiling using valgrind. Here are > the screenshots of the profiling info (obtained using kcachegrind). The > first image cpuprof-1.jpg shows runtimes sorted based on self timing and > the other based on cumulative timings. I could not make kcachegrind to > dump to a file, so I am including screenshots. The test used an X server > with Render extension (Redhat 9, NVIDIA accelerated driver with > RenderAccel on). > > Approx. 34.5% time is used by memcpy for sorting edge lists during > tesselation. Speeding up some of these parts (as you mentioned above) > for sure should sppedup Xr a lot. > > -- Soorya > > > > > -keith > > > > > > > > _______________________________________________ > > Xr mailing list > > Xr@xwin.org > > http://xwin.org/cgi-bin/mailman/listinfo/xr -------------- next part -------------- A non-text attachment was scrubbed... Name: xrbench.c Type: text/x-c Size: 8061 bytes Desc: not available Url : http://lists.freedesktop.org/archives/cairo/attachments/20030703/95c65965/xrbench.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: cpuprof-1.jpg Type: image/jpeg Size: 148481 bytes Desc: not available Url : http://lists.freedesktop.org/archives/cairo/attachments/20030703/95c65965/cpuprof-1.jpg -------------- next part -------------- A non-text attachment was scrubbed... Name: cpuprof-2.jpg Type: image/jpeg Size: 146051 bytes Desc: not available Url : http://lists.freedesktop.org/archives/cairo/attachments/20030703/95c65965/cpuprof-2.jpg From spitzak at d2.com Thu Jul 3 18:07:27 2003 From: spitzak at d2.com (Bill Spitzak) Date: Mon Aug 15 11:10:43 2005 Subject: [Xr] API questions In-Reply-To: <20030703214257.GA23207@crateria.homeunix.net> References: <200307031741.h63HfADK001329@hermes.d2.com> <20030703214257.GA23207@crateria.homeunix.net> Message-ID: <200307040103.h6413hDK005742@hermes.d2.com> On Thursday 03 July 2003 02:42 pm, David Forster wrote: > On Thu, Jul 03, 2003 at 10:44:52AM -0700, Bill Spitzak wrote: > > My suggestion is that the exact results for out-of-gamut colors is > > implementation-dependent. This will allow Xr or Xrender to turn the > > colors into internal representation without breaking the spec. > > I think this would be a mistake. > > If Xr is to be a serious API for rendering to both CRT/LCDs and > printers, then Xr is going to have to get color management right. > There's no way around it. If it doesn't, then it'll just get replaced > by someone who's willing to do it right. > > The point of abstracting away the hardware is so that developers can > write their rendering code _once_. The same code used to render a > document (like say a vector/raster image) to the screen can be reused > to print that document out. I fully understand that, but since the device cannot display out-of-gamut colors then it is impossible to produce the same output on two different devices anyway, so it really does not matter what it does with such colors (though I recommend that the device choose reasonable values). What I meant is that a compositing operation of two out-of-gamut colors could mathematically produce in-gamut colors. However I recommend that this not be supported, even though it makes in-gamut output different on different devices. I hope everybody can see that unless this is defined this way, Xr cannot use hardware for compositing, and must store full-floating point for every pixel in it's display. > If you don't define what the out-of-bounds sRGB values mean, then the > developer is going to have to take over color management, and that > means hardware dependence. And with Xr already correcting values for > sRGB it will be nothing short of a mess. One might just as well use > Xr for screen output and PostScript for printer output.. I do define exactly what out-of-bounds sRGB means: sRGB defines the exact luminosities of all values in the range 0-1, and I recommend this be extended with a straight line less than zero and a continued gamma curve above 1: if X is the sRGB value, luminosity = (x < .04045) ? x*1/12.92 : pow((x+.055)/1.055, 2.4) sRGB also defines the exact CIE XYZ coordinates of 1,0,0 and 0,1,0 and 0,0,1. From cworth at east.isi.edu Thu Jul 3 18:08:53 2003 From: cworth at east.isi.edu (Carl Worth) Date: Mon Aug 15 11:10:43 2005 Subject: [Xr] Anybody there? In-Reply-To: <200307032318.h63NIDDK022065@hermes.d2.com> References: <200306280554.h5S5s9DK005594@hermes.d2.com> <16132.17266.672647.133018@scream.east.isi.edu> <200307032318.h63NIDDK022065@hermes.d2.com> Message-ID: <16132.54181.5125.914554@scream.east.isi.edu> On Jul 3, Bill Spitzak wrote: > Since this is for testing and debugging I really don't care how slow it is, > so I was wondering if it is possible to compile Xr so that it only supports > local memory map drawing and does not attempt to use Xrender and does not use > Xrender header files. This may also be useful for getting Xr to work on that > "other" operating system. Currently there's no direct option for compiling without at least the latest Xrender header files. But, yes, this needs to be fixed. Xr should actually be fine, depending only on Xc, (minus the current bogus dependency on Xft). So Xc just needs to be reworked to allow separate compilation of each backend. -Carl PS. If you want a quick hack, I would think it wouldn't be too hard to run through Xc and comment out all the Xrender-related pieces. From spitzak at d2.com Thu Jul 3 18:13:16 2003 From: spitzak at d2.com (Bill Spitzak) Date: Mon Aug 15 11:10:43 2005 Subject: [Xr] API questions In-Reply-To: References: Message-ID: <200307040109.h6419WDK007806@hermes.d2.com> On Thursday 03 July 2003 10:50 am, Keith Packard wrote: > Around 10 o'clock on Jul 3, Bill Spitzak wrote: > > Even though it sounds primitive, I would really like to see an > > 8-bit/color interface added, like XrSetColor32(u32 color). This would > > take a number 0xRRGGBBAA to specify the rgba. > > Many applications use a format something like that, but the precise > representation differs and there is disagreement on whether the RGB values > should be premultiplied. Xr sidesteps the whole premultiplied alpha issue > by having separate interfaces... Yes it is likely that there is not much desire to specify the alpha this way. Perhaps XrSetColor24(u32 color) which takes 0xRRGGBB. The main reason for the 32-bit one is not because of the alpha, but because this is how rgb colors are stored in a pixmap that has alpha. It might make sense to ignore the alpha byte (this wont break the application I am thinking of using this for, as it would have had to force the alpha to 0xff every time anyway). If there is a call with both color and alpha it should be exactly as though you called XrSetRGBColor() and then XrSetAlpha(). Do whatever that does, there are no premultiplying questions that Xr have not already answered. -- ,~,~,~,~ ~ ~ ~ ~ /\_ _|_========___ Bill Spitzak ~~~/\/\\~~~~~~\____________/~~~~~~~~ spitzak@d2.com From cworth at east.isi.edu Thu Jul 3 18:15:23 2003 From: cworth at east.isi.edu (Carl Worth) Date: Mon Aug 15 11:10:43 2005 Subject: [Xr] Xr naming (was: Anybody there?) In-Reply-To: <200307032319.h63NJkDK023171@hermes.d2.com> References: <200307032319.h63NJkDK023171@hermes.d2.com> Message-ID: <16132.54571.995601.455274@scream.east.isi.edu> On Jul 3, Bill Spitzak wrote: > I think the "Xr" name is very good and everybody is calling it that already. > Tell the Windows people it is "like Direct-X for non-games, that is why it is > called xr". The solution we came up with for the OLS paper, (for which we submitted a title long before Xr could even draw to in-memory images), was to define Xr as "Cross-device Rendering". Would it help to keep the same pronunciation, but de-emphasize the X, (eg. name it xr or XR)? I'm also not a big fan of studly caps, but went with it originally to match the X libraries. How about: xr_save (xrs); xr_move_to (xrs, x, y); xr_curve_to (xrs, x1, y1, x2, y2, x3, y3); xr_stroke (xrs); xr_restore (xrs); -Carl From lars.segerlund at comsys.se Fri Jul 4 01:23:40 2003 From: lars.segerlund at comsys.se (Lars Segerlund) Date: Mon Aug 15 11:10:43 2005 Subject: [Xr] Anybody there? In-Reply-To: <200307032318.h63NIDDK022065@hermes.d2.com> References: <200306280554.h5S5s9DK005594@hermes.d2.com> <16132.17266.672647.133018@scream.east.isi.edu> <200307032318.h63NIDDK022065@hermes.d2.com> Message-ID: <3F05398C.3000106@comsys.se> I also have this problem, I can't update my X11 but would really like to run Xr/xsvg ... this is entirely due to the fact that I'm on a developement machine and have some restrictions. Perhaps autoconf can find something ? / Lars Segerlund. Bill Spitzak wrote: > On Thursday 03 July 2003 07:53 am, Carl Worth wrote: > > >>Beyond that, what's really needed to improve Xr is to get some >>feedback. I'd be very interested to hear from people who have tried >>using Xr in a non-trivial way, (eg. using it to support drawing within >>a toolkit or a significant application). Feedback from experience like >>that is quite useful. (Some feedback has already come in -- thanks for >>the comments!). > > > I am currently stumped as the better machines I have access to do not have > the newest X11 on them and so Xr does not compile. > > Since this is for testing and debugging I really don't care how slow it is, > so I was wondering if it is possible to compile Xr so that it only supports > local memory map drawing and does not attempt to use Xrender and does not use > Xrender header files. This may also be useful for getting Xr to work on that > "other" operating system. > From otaylor at redhat.com Fri Jul 4 08:06:27 2003 From: otaylor at redhat.com (Owen Taylor) Date: Mon Aug 15 11:10:43 2005 Subject: [Xr] API questions In-Reply-To: <200307040109.h6419WDK007806@hermes.d2.com> References: <200307040109.h6419WDK007806@hermes.d2.com> Message-ID: <1057331187.26133.42.camel@localhost.localdomain> On Thu, 2003-07-03 at 21:13, Bill Spitzak wrote: > On Thursday 03 July 2003 10:50 am, Keith Packard wrote: > > Around 10 o'clock on Jul 3, Bill Spitzak wrote: > > > Even though it sounds primitive, I would really like to see an > > > 8-bit/color interface added, like XrSetColor32(u32 color). This would > > > take a number 0xRRGGBBAA to specify the rgba. > > > > Many applications use a format something like that, but the precise > > representation differs and there is disagreement on whether the RGB values > > should be premultiplied. Xr sidesteps the whole premultiplied alpha issue > > by having separate interfaces... > > Yes it is likely that there is not much desire to specify the alpha this way. > Perhaps XrSetColor24(u32 color) which takes 0xRRGGBB. > > The main reason for the 32-bit one is not because of the alpha, but because > this is how rgb colors are stored in a pixmap that has alpha. It might make > sense to ignore the alpha byte (this wont break the application I am thinking > of using this for, as it would have had to force the alpha to 0xff every time > anyway). What's the application you are thinking of using this for? I really don't see where setting the color for a primitive to be a color from a pixmap is a common operation. > If there is a call with both color and alpha it should be exactly as though > you called XrSetRGBColor() and then XrSetAlpha(). Do whatever that does, > there are no premultiplying questions that Xr have not already answered. That would be "non-premultiplied" and is not compatible with "this is how rgb colors are stored in a pixmap that has alpha". Regards, Owen From xwin641 at vtnet.ca Sun Jul 6 22:12:13 2003 From: xwin641 at vtnet.ca (Trevor Woerner) Date: Mon Aug 15 11:10:43 2005 Subject: [Xr] small adjustments Message-ID: <200307070112.13056.xwin641@vtnet.ca> Hi, I grabbed the code via CVS as detailed on the xr.xwin.org site. There were a few small adjustments that were required in order to get it to work on my machine. I scanned the mailing list and didn't see anything posted to this effect. I guess there's a chance this only affects me. Starting with a Red Hat 9 install, in order to get the xrtest applications to compile and run: 1) i have upgraded my autotools to the latest available, therefore i had to also upgrade pkgconfig to version 0.15.0. the ./configure script failed for me with version 0.14.0. 2) i put all the stuff i built into $HOME/local (i.e. i did a './autogen.sh --prefix=$HOME/local' for each directory) therefore i needed to do an 'export PKG_CONFIG_PATH=$HOME/local/lib/pkgconfig' 3) i also needed my own LD_LIBRARY_PATH (i.e. 'export LD_LIBRARY_PATH=$HOME/local/lib') 4) i had to upgrade fontconfig (to 2.2.90) and Xft (to 2.1.2) which can be found at http://fontconfig.org/release 5) the order for installing the libraries is: a) libpixregion b) libic c) Xc d) fontconfig e) Xft f) Xr 6) then i could build the test programs. the xr.xwin.org website's last section is "Example Programs" and has the following CVS command: cvs -d :pserver:anoncvs@keithp.com:/local/src/CVS login which isn't correct (of course), you need: cvs -d :pserver:anoncvs@keithp.com:/local/src/CVS co xrtest i also needed the following diff: Index: xrtest/Makefile =================================================================== RCS file: /local/src/CVS/xrtest/Makefile,v retrieving revision 1.2 diff -u -r1.2 Makefile --- xrtest/Makefile 25 Apr 2003 20:31:20 -0000 1.2 +++ xrtest/Makefile 7 Jul 2003 04:54:49 -0000 @@ -1,5 +1,5 @@ -CFLAGS=-g -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls `pkg-config --cflags Xr` -LDFLAGS=`pkg-config --libs Xr` +CFLAGS=-g -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls `pkg-config --cflags xr` +LDFLAGS=`pkg-config --libs xr` PROGS=xrtest xrspline xrknockout xrfreq Index: xrtest/xrknockout.c =================================================================== RCS file: /local/src/CVS/xrtest/xrknockout.c,v retrieving revision 1.8 diff -u -r1.8 xrknockout.c --- xrtest/xrknockout.c 12 May 2003 16:50:04 -0000 1.8 +++ xrtest/xrknockout.c 7 Jul 2003 04:54:49 -0000 @@ -209,7 +209,7 @@ XrRestore (r); XrSetOperator (r, XrOperatorOutReverse); - XrShowSurface (r, punch, 0, 0, width, height); + XrShowSurface (r, punch, width, height); /* Now draw the 3 circles in a subgroup again * at half intensity, and use OperatorAdd to join up @@ -225,11 +225,11 @@ XrRestore (r); XrSetOperator (r, XrOperatorAdd); - XrShowSurface (r, circles, 0, 0, width, height); + XrShowSurface (r, circles, width, height); XrRestore (r); - XrShowSurface (r, overlay, 0, 0, width, height); + XrShowSurface (r, overlay, width, height); XrSurfaceDestroy (overlay); XrSurfaceDestroy (punch); Hope this helps, Trevor From dforste at arbornet.org Mon Jul 7 01:07:31 2003 From: dforste at arbornet.org (David Forster) Date: Mon Aug 15 11:10:43 2005 Subject: [Xr] API questions In-Reply-To: <200307040103.h6413hDK005742@hermes.d2.com> References: <200307031741.h63HfADK001329@hermes.d2.com> <20030703214257.GA23207@crateria.homeunix.net> <200307040103.h6413hDK005742@hermes.d2.com> Message-ID: <20030707080731.GA33179@crateria.homeunix.net> On Thu, Jul 03, 2003 at 06:07:27PM -0700, Bill Spitzak wrote: > I fully understand that, but since the device cannot display > out-of-gamut colors then it is impossible to produce the same output > on two different devices anyway, so it really does not matter what > it does with such colors (though I recommend that the device choose > reasonable values). OK, you're right...I totally misunderstood what you where talking about and wasn't thinking clearly. Right, while RGB values specify well-defined colors, the color gets clipped in the frame buffer...The only `correct' solution is to store pixels in some high precision format... > I hope everybody can see that unless this is defined this way, Xr > cannot use hardware for compositing, and must store full-floating > point for every pixel in it's display. Yes, hard to see how to get around it. Floating point, however, is not necessary. HP's e-sRGB color space defines values in the range -0.53 to 1.68, which is then mapped to a 10, 12 or 16-bit integer. This gamut is large enough for printers...The frame buffer could be in this format. This of course could not be accelerated with today's hardware, but if 48/64-bit buffers ever materialize, then it could be. Simply render in e-sRGB and then shift/expand the color values... One could also do the same thing today by stretching 8-bits over e-sRGB, at the expense of precision...But I doubt it would look good. OK, I'll try again: Support both e-sRGB and sRGB. The user specifies which when the surface is created. Most folks (like toolkit authors) will specify sRGB, but users doing higher quality work can specify an e-sRGB buffer. e-sRGB won't be accelerated for the time being, but will be correct. I don't know, though, how slow 48-bit rendering is in software. If it isn't doable, then Xr could just refuse to create an e-sRGB surface. All values still accepted by XrSetRGBColor() no matter what color space, but clamped to appropriate values. To prevent color flashing for accelerated 48-bit output, however, double-buffering would have to be integrated into Xr. This may not be so horrible, however. If Xr is also going to support rendering to PDF like Quartz, then it will also need a `new page' operator. Also, client side rendering needs to know when to send the buffer anyways. Now, it's true that having two color spaces like this complicates things a bit, but if you can't trust the implementation to do e-sRGB correctly, then users might be inclined not to use it all, or hack there rendering code up to expect either e-sRGB or sRGB anyways. You can end up with some very strange output doing e-sRGB to sRGB blindly. > > If you're doing color management the value isn't going to get passed > > straight on anyways. > > Well actually for almost all current-day hardware, if the values are > sRGB*255 then they are going to be passed unchanged to the hardware. Ack ;). Of course, the whole point of sRGB...I wasn't thinking. -Dave (e-sRGB, btw, can be found at www.srgb.com) From cworth at east.isi.edu Mon Jul 7 04:13:54 2003 From: cworth at east.isi.edu (Carl Worth) Date: Mon Aug 15 11:10:43 2005 Subject: [Xr] small adjustments In-Reply-To: <200307070112.13056.xwin641@vtnet.ca> References: <200307070112.13056.xwin641@vtnet.ca> Message-ID: <16137.22002.417504.900097@scream.east.isi.edu> On Jul 7, Trevor Woerner wrote: > 1) i have upgraded my autotools to the latest available autotools version skew is always painful for me. Would it be helpful if I referenced explicit versioned instances of autoconf (eg. autoconf2.50) and friends in autogen.sh? > 2) i put all the stuff i built into $HOME/local (i.e. i did a > './autogen.sh --prefix=$HOME/local' for each directory) therefore i > needed to do an 'export PKG_CONFIG_PATH=$HOME/local/lib/pkgconfig' > > 3) i also needed my own LD_LIBRARY_PATH (i.e. 'export > LD_LIBRARY_PATH=$HOME/local/lib') Steps such as these are standard anytime one installs libraries into a custom location. > 4) i had to upgrade fontconfig (to 2.2.90) and Xft (to 2.1.2) which can > be found at http://fontconfig.org/release The Xft dependency will be going away (hopefully soon). Meanwhile, Xr will probably pick up explicit fontconfig and freetype dependencies. > 5) the order for installing the libraries is: It would be nice to find a good way to simplify the task of downloading, configuring, compiling, and installing the whole family of libraries. GAR has been suggested as one approach. I have no experience with it yet. Perhaps someone on the list does and could investigate setting something up? > 6) then i could build the test programs. the xr.xwin.org website's last > section is "Example Programs" and has the following CVS command: > > cvs -d :pserver:anoncvs@keithp.com:/local/src/CVS login Fixed. > i also needed the following diff: Looks like xrtest had suffered a little bit rot. Also fixed. Thanks for your input Trevor. -Carl From blizzard at redhat.com Mon Jul 7 09:18:46 2003 From: blizzard at redhat.com (Christopher Blizzard) Date: Mon Aug 15 11:10:43 2005 Subject: [Xr] small adjustments In-Reply-To: <16137.22002.417504.900097@scream.east.isi.edu> References: <200307070112.13056.xwin641@vtnet.ca> <16137.22002.417504.900097@scream.east.isi.edu> Message-ID: <3F099D66.4030106@redhat.com> Carl Worth wrote: >On Jul 7, Trevor Woerner wrote: > > 1) i have upgraded my autotools to the latest available > >autotools version skew is always painful for me. Would it be helpful >if I referenced explicit versioned instances of autoconf >(eg. autoconf2.50) and friends in autogen.sh? > > > We (Red Hat) usually ship a few different auto* tools with the prefixes. If you want, why don't you check for them first? i.e.: if [ -x /usr/bin/autoconf-2.13 ]; then /usr/bin/autoconf-2.13 fi etc. I have quite a few on my system at the moment: [blizzard@dead blizzard]$ rpm -qa|grep ^auto automake-1.7.5-1 autofs-3.1.7-38 automake14-1.4p6-7 autoconf-2.57-3 autoconf213-2.13-6 autorun-3.10-2 automake15-1.5-9 --Chris From spitzak at d2.com Mon Jul 7 12:04:41 2003 From: spitzak at d2.com (Bill Spitzak) Date: Mon Aug 15 11:10:43 2005 Subject: [Xr] API questions In-Reply-To: <20030707080731.GA33179@crateria.homeunix.net> References: <200307040103.h6413hDK005742@hermes.d2.com> <20030707080731.GA33179@crateria.homeunix.net> Message-ID: <200307071900.h67J0ODK003323@hermes.d2.com> On Monday 07 July 2003 01:07 am, David Forster wrote: > Yes, hard to see how to get around it. Floating point, however, is > not necessary. HP's e-sRGB color space defines values in the range > -0.53 to 1.68, which is then mapped to a 10, 12 or 16-bit integer. > This gamut is large enough for printers...The frame buffer could be in > this format. You should also look at ILM's "half" format, which is very likely to be a standard supported by shading hardware. It is basically a 16-bit IEEE float. Information and source is at http://www.openexr.com and it seems to be BSD licensed. Current hardware seems to be designed to assumme any 16-bit color values are stored as sRGB, there is no built-in conversion to the 8-bit display buffer other than multiplying by 255. We were able to do a linear->sRGB conversion by using a texture map and using the color to index it, but I don't think this was the intended use of the hardware design. So anyway this would indicate that any floating-point interface will probably need to be sRGB and not linear. From spitzak at d2.com Mon Jul 7 12:09:07 2003 From: spitzak at d2.com (Bill Spitzak) Date: Mon Aug 15 11:10:43 2005 Subject: [Xr] API questions In-Reply-To: <1057331187.26133.42.camel@localhost.localdomain> References: <200307040109.h6419WDK007806@hermes.d2.com> <1057331187.26133.42.camel@localhost.localdomain> Message-ID: <200307071904.h67J4nDK006365@hermes.d2.com> On Friday 04 July 2003 08:06 am, Owen Taylor wrote: > What's the application you are thinking of using this for? I really > don't see where setting the color for a primitive to be a color from a > pixmap is a common operation. No, maybe not, but lots of applications store a color in a 32-bit integer. This has the advantage that such data can be stored easily in databases or interpreted languages where structures are not possible or too expensive. Also the Windows RGB(r,g,b), though in theory returing a device-dependent result, is known to return 0xRRGGBB and vast amounts of software rely on this. > > If there is a call with both color and alpha it should be exactly as > > though you called XrSetRGBColor() and then XrSetAlpha(). Do whatever that > > does, there are no premultiplying questions that Xr have not already > > answered. > > That would be "non-premultiplied" and is not compatible with "this is > how rgb colors are stored in a pixmap that has alpha". I agree with this assessment. Perhaps it would be better to just make a call that takes an 24-bit rgb color. This would match the windows version and is probably the more common pixel format. -- ,~,~,~,~ ~ ~ ~ ~ /\_ _|_========___ Bill Spitzak ~~~/\/\\~~~~~~\____________/~~~~~~~~ spitzak@d2.com From spitzak at d2.com Mon Jul 7 21:19:56 2003 From: spitzak at d2.com (Bill Spitzak) Date: Mon Aug 15 11:10:43 2005 Subject: [Xr] small adjustments In-Reply-To: <200307070112.13056.xwin641@vtnet.ca> References: <200307070112.13056.xwin641@vtnet.ca> Message-ID: <200307080415.h684FZDK028675@hermes.d2.com> I have not been sucessful in getting Xr to compile without Xrender. First it uses a lot of symbols from Xrender and new Xlib.h header files: XFixed XDouble XTransform XPointFixed XPointDouble XLineFixed XTriangle XTrapezoid PictStandard* PictOp* I was able to get most things to compile by copying the definitions and pasting the above from a new Xrender, and by using the old Xrender.h header file. However the programs don't link because they want many functions from Xft. I was unable to compile Xft because it wanted the new version of fontconfig. I was unable to compile fontconfig because it barfed on the target "confdir.sgml.in" and after messing with it to get around that I was unable to get it to produce a pkgconfig file that was acceptable to the xft make script. All in all a rather frustrating experience. This is exactly the sort of stuff people complain about with Linux. There is no reason for this mess. To the average programmer there should be ONE library to draw things. Thoug to be charitable I can see an excuse to put Freetype into it's own library. Would it be possible to gather fontconfig, Xrender, Xr, Xft, libpiximage, and all this other stuff and make ONE library? -- ,~,~,~,~ ~ ~ ~ ~ /\_ _|_========___ Bill Spitzak ~~~/\/\\~~~~~~\____________/~~~~~~~~ spitzak@d2.com From cworth at east.isi.edu Tue Jul 8 06:55:13 2003 From: cworth at east.isi.edu (Carl Worth) Date: Mon Aug 15 11:10:43 2005 Subject: [Xr] small adjustments In-Reply-To: <200307080415.h684FZDK028675@hermes.d2.com> References: <200307070112.13056.xwin641@vtnet.ca> <200307080415.h684FZDK028675@hermes.d2.com> Message-ID: <16138.52545.407627.412564@scream.east.isi.edu> On Jul 7, Bill Spitzak wrote: > I have not been sucessful in getting Xr to compile without Xrender. The work has not yet been done to make this possible. That work is near the top of my list of tasks to do for Xr. Of course, contributions would be welcome. > However the programs don't link because they want many functions > from Xft. The dependency on Xft is really just a temporary hack to draw some text on the screen. Work is in progress to have real text support in Xr, and when that is complete the dependency on Xft will go away. > All in all a rather frustrating experience. I can appreciate your frustration. As I said in a previous email, it would be beneficial to have a system such as GAR to aid in the process of compiling the many libraries that make up this system. > This is exactly the sort of stuff people complain about with Linux. There is > no reason for this mess. To the average programmer there should be ONE > library to draw things. Thoug to be charitable I can see an excuse to put > Freetype into it's own library. Would it be possible to gather fontconfig, > Xrender, Xr, Xft, libpiximage, and all this other stuff and make > ONE library? There are actually good reasons for the separation of each library mentioned above. It would not be feasible nor beneficial to combine them. As for your "average programmer" that considers this a mess, such a programmer should wait patiently until Xr appears pre-compiled with all of its dependent libraries within his/her favorite distribution. At that point, it will be as simple as installing a "single" Xr package in order to draw things. -Carl From spitzak at d2.com Tue Jul 8 10:14:11 2003 From: spitzak at d2.com (Bill Spitzak) Date: Mon Aug 15 11:10:43 2005 Subject: [Xr] small adjustments In-Reply-To: <16138.52545.407627.412564@scream.east.isi.edu> References: <200307070112.13056.xwin641@vtnet.ca> <200307080415.h684FZDK028675@hermes.d2.com> <16138.52545.407627.412564@scream.east.isi.edu> Message-ID: <200307081709.h68H9kDK011691@hermes.d2.com> On Tuesday 08 July 2003 06:55 am, Carl Worth wrote: > On Jul 7, Bill Spitzak wrote: > > I have not been sucessful in getting Xr to compile without Xrender. > > The work has not yet been done to make this possible. That work is > near the top of my list of tasks to do for Xr. Of course, > contributions would be welcome. Sorry about the complaints. I was trying to be constructive but eventually got frustrated. I was really hoping to get it to compile and link. In any case the biggest impediment I see is that the Xr and Xc headers themselves depend on symbols defined by Xrender header files. Some of this is a problem with Xrender itself: Primarily the fact that it uses things like "XFixed" and "XDouble" rather than built-in types. This means it is impossible to write an efficient implementation, unless you assumme these are the same as int/double (thus defeating the purpose of the typedef), or include the Xrender header file (thus pushing the whole problem of conversion up to the program calling Xr and solving nothing, and also making Xr non-portable). I strongly recommend that such typedefs be removed from all new interfaces to X or other system services, they are actually counter-productive. The other bad part about Xrender is that it uses the "typedef struct _Foo {...} Foo;" convention. This makes it impossible to declare functions that take pointers to these structures without including Xrender.h. All modern C compilers accept "struct Foo {...};" and thus another header file can just say "struct Foo;" and make functions that take pointers. However in almost all cases I would replace the use of such structures with either individual x,y arguments or with arrays of the correct size of built-in types. Although not "type safe" such interfaces are much more convienent for efficient glue to another drawing library. Fortunately Xrender has learned not to typedef-hide pointers. I am grateful for that. -- ,~,~,~,~ ~ ~ ~ ~ /\_ _|_========___ Bill Spitzak ~~~/\/\\~~~~~~\____________/~~~~~~~~ spitzak@d2.com From cworth at east.isi.edu Tue Jul 8 11:41:31 2003 From: cworth at east.isi.edu (Carl Worth) Date: Mon Aug 15 11:10:43 2005 Subject: [Xr] small adjustments In-Reply-To: <200307081709.h68H9kDK011691@hermes.d2.com> References: <200307070112.13056.xwin641@vtnet.ca> <200307080415.h684FZDK028675@hermes.d2.com> <16138.52545.407627.412564@scream.east.isi.edu> <200307081709.h68H9kDK011691@hermes.d2.com> Message-ID: <16139.4187.365068.531311@scream.east.isi.edu> On Jul 8, Bill Spitzak wrote: > On Tuesday 08 July 2003 06:55 am, Carl Worth wrote: > > On Jul 7, Bill Spitzak wrote: > > > I have not been sucessful in getting Xr to compile without Xrender. > > > > The work has not yet been done to make this possible. > > Sorry about the complaints. I was trying to be constructive but eventually > got frustrated. I was really hoping to get it to compile and link. No worries. > In any case the biggest impediment I see is that the Xr and Xc headers > themselves depend on symbols defined by Xrender header files. The "work" described above must address this, of course. -Carl From danmorg at comcast.net Fri Jul 11 15:00:39 2003 From: danmorg at comcast.net (Daniel Morgan) Date: Mon Aug 15 11:10:43 2005 Subject: [Xr] xr on Microsoft Windows Message-ID: Does xr build or run on Microsoft Windows? If not, is there any plans to do so? From cworth at east.isi.edu Fri Jul 11 14:21:53 2003 From: cworth at east.isi.edu (Carl Worth) Date: Mon Aug 15 11:10:43 2005 Subject: [Xr] xr on Microsoft Windows In-Reply-To: References: Message-ID: <16143.10865.69408.62017@scream.east.isi.edu> On Jul 11, Daniel Morgan wrote: > Does xr build or run on Microsoft Windows? Not currently. > If not, is there any plans to do so? There are people that have expressed interest in having this work, and I know of at least one person that has started looking into this. Since Xr is intended to support a variety of different backends, (in-memory images, graphics display devices, page devices such as PDF, etc.), this mailing list would be an appropriate forum for discussing problems/progress with Xr portability. -Carl -- Carl Worth USC Information Sciences Institute cworth@isi.edu From keithp at keithp.com Fri Jul 11 19:16:08 2003 From: keithp at keithp.com (Keith Packard) Date: Mon Aug 15 11:10:43 2005 Subject: [Xr] xr on Microsoft Windows In-Reply-To: Your message of "Fri, 11 Jul 2003 18:00:39 EDT." Message-ID: Around 18 o'clock on Jul 11, "Daniel Morgan" wrote: > Does xr build or run on Microsoft Windows? If not, is there any plans to > do so? Xr doesn't yet build on anything other than X at this point, but it has no intrinsic X dependencies and the plan is to see it ported as widely as people are interested in supporting. Projects like Squeak, Mono and Mozilla are strongly cross platform and people have expressed an interest in using Xr on all of their target platforms; I hope people with expertise on non-X platforms will be able to help out with this porting effort. Of course, the first job is to figure out what to call this library -- once the X dependency has been removed, we'll have to call the library 'r' which seems more than a little silly... -keith From xwin641 at vtnet.ca Fri Jul 11 20:43:56 2003 From: xwin641 at vtnet.ca (Trevor Woerner) Date: Mon Aug 15 11:10:43 2005 Subject: [Xr] xr on Microsoft Windows In-Reply-To: References: Message-ID: <200307112343.56925.xwin641@vtnet.ca> On July 11, 2003 10:16 pm, Keith Packard wrote: > Of course, the first job is to figure out what to call this library > -- once the X dependency has been removed, we'll have to call the > library 'r' which seems more than a little silly... postxr ('post' as in "postscript" and post as in "the library formally know as"). Then in grand unix tradition we'll say: "it's spelt 'postxr' but it's really pronounced 'poster'", or something to that effect. :-) Trevor From otaylor at redhat.com Sat Jul 12 08:28:40 2003 From: otaylor at redhat.com (Owen Taylor) Date: Mon Aug 15 11:10:43 2005 Subject: [Xr] xr on Microsoft Windows In-Reply-To: <200307112343.56925.xwin641@vtnet.ca> References: <200307112343.56925.xwin641@vtnet.ca> Message-ID: <1058023720.8475.55.camel@localhost.localdomain> On Fri, 2003-07-11 at 23:43, Trevor Woerner wrote: > On July 11, 2003 10:16 pm, Keith Packard wrote: > > Of course, the first job is to figure out what to call this library > > -- once the X dependency has been removed, we'll have to call the > > library 'r' which seems more than a little silly... > > postxr ('post' as in "postscript" and post as in "the library formally > know as"). > > Then in grand unix tradition we'll say: "it's spelt 'postxr' but it's > really pronounced 'poster'", or something to that effect. :-) As someone with much experience with speaking about GTK+ I'd really, really advise avoiding this. (*) I don't see a problem with keeping the name Xr even not on X. It's not like the X Window System managed a monopoly on the letter X. Perhaps a more obvious-what-it-is name would be better anyways - but I wouldn't change it just because of the X. And the big problem with nice obvious names is that they are all taken. Regards, owen (*) for those not in the know, the + in GTK+ is silent From keithp at keithp.com Sat Jul 12 09:28:31 2003 From: keithp at keithp.com (Keith Packard) Date: Mon Aug 15 11:10:43 2005 Subject: [Xr] xr on Microsoft Windows In-Reply-To: Your message of "12 Jul 2003 11:28:40 EDT." <1058023720.8475.55.camel@localhost.localdomain> Message-ID: Around 11 o'clock on Jul 12, Owen Taylor wrote: > I don't see a problem with keeping the name Xr even not on X. It's > not like the X Window System managed a monopoly on the letter X. Well, we've already had several people say that they skipped right on by Xr because of the name, even though the library is addressed at their applications (squeak in particular). > Perhaps a more obvious-what-it-is name would be better anyways - > but I wouldn't change it just because of the X. And the big problem > with nice obvious names is that they are all taken. Yes, the obvious names are all taken, but a reasonably unique name can be used to form a brand that people will learn about given suitable advertisement. Confusing names are harder to generate brand identity for, and short names seem likely to be harder to defend from trademark infringement. I'd rather find a word that we can build some kind of brand around; something that has relatively a obvious pictorial representation so we can create logos, design graphics around and provide some kind of thematic identity to the project. Think 'Gnome' vs 'Gtk+' -- Gnome is *way* easier to sell because you've got all kinds of cultural context to build upon. Carl and I have been tossing 'cairo' back and forth -- there's an inside joke that can be explained -- Xr looks very much like the greek letters chi and rho, and the italian word 'chiaros' means 'light, clear', which certainly provides some useful associations with alpha compositing and an easy to use interface with short function calls. Anglicise 'chiaros' and you get something very close to 'cairo'. Mixing Italian, Greek and Egyptian seems like it should offer plenty of opportunities for thematic brand development. -keith (who should clearly avoid any plans for a future in marketing) From rakko at charter.net Sat Jul 12 09:58:10 2003 From: rakko at charter.net (Eric Christopherson) Date: Mon Aug 15 11:10:43 2005 Subject: [Xr] xr on Microsoft Windows In-Reply-To: References: <1058023720.8475.55.camel@localhost.localdomain> Message-ID: <20030712165810.GB1480@localhost> Warning: linguistic nitpicking ahead! On Sat, Jul 12, 2003 at 09:28:31AM -0700, Keith Packard wrote: [snip] > Carl and I have been tossing 'cairo' back and forth -- there's an inside > joke that can be explained -- Xr looks very much like the greek letters > chi and rho, While I really like the name Cairo, there are a few troublesome issues. One, the Greek rho really looks like a Latin letter P, not R. That would make it Xp ;) Also on a Microsoft note, there was years ago some version of Windows with the codename Cairo. I'm not sure if that association would hinder things, though... > and the italian word 'chiaros' means 'light, clear', which > certainly provides some useful associations with alpha compositing and an > easy to use interface with short function calls. Anglicise 'chiaros' and > you get something very close to 'cairo'. I think that's chiaro, no s. Also, it's pronounced kyah-ro, not ky-ro, but that's still fairly similar. -- Furrfu! r a k k o at c h a r t e r dot n e t From cworth at east.isi.edu Sat Jul 12 09:46:13 2003 From: cworth at east.isi.edu (Carl Worth) Date: Mon Aug 15 11:10:44 2005 Subject: [Xr] Naming Xr (and linguistic nitpicking) In-Reply-To: <20030712165810.GB1480@localhost> References: <1058023720.8475.55.camel@localhost.localdomain> <20030712165810.GB1480@localhost> Message-ID: <16144.15189.579762.333437@scream.east.isi.edu> On Jul 12, Eric Christopherson wrote: > On Sat, Jul 12, 2003 at 09:28:31AM -0700, Keith Packard wrote: > Warning: linguistic nitpicking ahead! Fine by me. > While I really like the name Cairo, there are a few troublesome issues. One, > the Greek rho really looks like a Latin letter P, not R. That would make it > Xp ;) Yes. In order to get to R from rho one has to consider the Greek pronunciation or rho with the pronunciation of R in several Romance languages. Alas, X from chi relies on the shape of the glyph, (where pronunciation would more likely yield K or CH). Another possibility for transliterating XR to Greek letters would be ksi rho, but that doesn't have good possibilities for a name that would sound natural to English speakers. > > and the italian word 'chiaros' means 'light, clear', > > I think that's chiaro, no s. Ah, but as long as we're nitpicking we can recall that Italian adjectives also appear in plural form, so Keith's statement is technically correct; there is an Italian word chiaros. ;-) > Also, it's pronounced kyah-ro, not ky-ro, but that's still fairly > similar. True. I thought of chiaro after looking at the names of chi and rho spelled out. I had been trying to thing of words suggesting light or terms used in art, and I think chiaro pulls these concepts together nicely. On the other hand, I think Cairo makes a much better sounding name than Chiaro. -Carl From francois.robert at it.unisys.com Sat Jul 12 11:48:19 2003 From: francois.robert at it.unisys.com (Robert, Francois) Date: Mon Aug 15 11:10:44 2005 Subject: [Xr] Naming Xr (and linguistic nitpicking) Message-ID: ... > Ah, but as long as we're nitpicking we can recall that Italian > adjectives also appear in plural form, so Keith's statement is > technically correct; there is an Italian word chiaros. ;-) Wrong again. "s" is not a universal plural marker. In italian, plural are indicated (most of the time...) by a terminal "i" or "e". The plural form is "chiari" (masculine plural) or "chiare" (feminine plural). What about Wr for windows, Mr for mac, Lr for Linux/Unix/X, and Xr in general where "X" stands for a wildcard ? ("X" has a long traditionnal use as a "don't care" indicator for instance when describing bitwise flags in bytes or words, in electronic component datasheets for instance) ? ______________________________________________ Fran?ois Robert From cworth at east.isi.edu Sat Jul 12 11:07:11 2003 From: cworth at east.isi.edu (Carl Worth) Date: Mon Aug 15 11:10:44 2005 Subject: [Xr] Naming Xr (and linguistic nitpicking) In-Reply-To: References: Message-ID: <16144.20047.323683.311801@scream.east.isi.edu> On Jul 12, Robert, Francois wrote: > Wrong again. "s" is not a universal plural marker. In italian, plural are > indicated (most of the time...) by a terminal "i" or "e". The plural form is > "chiari" (masculine plural) or "chiare" (feminine plural). I lose. I'm out. -Carl From spitzak at d2.com Sun Jul 13 19:30:19 2003 From: spitzak at d2.com (Bill Spitzak) Date: Mon Aug 15 11:10:44 2005 Subject: [Xr] Naming Xr (and linguistic nitpicking) In-Reply-To: References: Message-ID: <200307140225.h6E2P2DK003405@hermes.d2.com> On Saturday 12 July 2003 11:48 am, Robert, Francois wrote: > What about Wr for windows, Mr for mac, Lr for Linux/Unix/X, and Xr in > general where "X" stands for a wildcard ? ("X" has a long traditionnal use > as a "don't care" indicator for instance when describing bitwise flags in > bytes or words, in electronic component datasheets for instance) ? I like this idea. Xr would be the definition of the portable interface. Various implementations would all end in 'r'. This would not only indicate what system it was for but may identify competing implementations. It would be like all the file systems ending in "fs". -- ,~,~,~,~ ~ ~ ~ ~ /\_ _|_========___ Bill Spitzak ~~~/\/\\~~~~~~\____________/~~~~~~~~ spitzak@d2.com From spitzak at d2.com Sun Jul 13 19:32:46 2003 From: spitzak at d2.com (Bill Spitzak) Date: Mon Aug 15 11:10:44 2005 Subject: [Xr] xr on Microsoft Windows In-Reply-To: References: Message-ID: <200307140227.h6E2RUDK003533@hermes.d2.com> On Saturday 12 July 2003 09:28 am, Keith Packard wrote: > Around 11 o'clock on Jul 12, Owen Taylor wrote: > > I don't see a problem with keeping the name Xr even not on X. It's > > not like the X Window System managed a monopoly on the letter X. > > Well, we've already had several people say that they skipped right on by > Xr because of the name, even though the library is addressed at their > applications (squeak in particular). Well personally I became interested in Xr *because* of the name, it promised an actual server level implementation, rather than yet another local image map graphics library. I ignored libart and all the others because they did not sound commited to doing anything about fixing X itself. Xr sounds like it will. -- ,~,~,~,~ ~ ~ ~ ~ /\_ _|_========___ Bill Spitzak ~~~/\/\\~~~~~~\____________/~~~~~~~~ spitzak@d2.com From spitzak at d2.com Mon Jul 14 09:52:20 2003 From: spitzak at d2.com (Bill Spitzak) Date: Mon Aug 15 11:10:44 2005 Subject: [Xr] Naming Xr (and linguistic nitpicking) In-Reply-To: <200307140225.h6E2P2DK003405@hermes.d2.com> References: <200307140225.h6E2P2DK003405@hermes.d2.com> Message-ID: <200307141646.h6EGkxDK007151@hermes.d2.com> On Sunday 13 July 2003 07:30 pm, Bill Spitzak wrote: > On Saturday 12 July 2003 11:48 am, Robert, Francois wrote: > > What about Wr for windows, Mr for mac, Lr for Linux/Unix/X, and Xr in > > general where "X" stands for a wildcard ? ("X" has a long traditionnal > > use as a "don't care" indicator for instance when describing bitwise > > flags in bytes or words, in electronic component datasheets for instance) > > ? > > I like this idea. Xr would be the definition of the portable interface. > Various implementations would all end in 'r'. This would not only indicate > what system it was for but may identify competing implementations. It would > be like all the file systems ending in "fs". I typed that late at night, what I mostly thought was that the various implementations could have more than one letter in front of the 'r'. Maybe the portable interface should be called "*r". The main implementation is Xr which uses X and Xrender. There might also be X11r to run on old X systems, imager to write to a local image, win32r for current Windows (on the assumption that they will make a new graphics interface), pdfr for the interface to write a pdf file, etc. -- ,~,~,~,~ ~ ~ ~ ~ /\_ _|_========___ Bill Spitzak ~~~/\/\\~~~~~~\____________/~~~~~~~~ spitzak@d2.com From cworth at east.isi.edu Tue Jul 15 11:49:53 2003 From: cworth at east.isi.edu (Carl Worth) Date: Mon Aug 15 11:10:44 2005 Subject: [Xr] Naming Xr (and linguistic nitpicking) In-Reply-To: References: Message-ID: <16148.19665.982719.977047@scream.east.isi.edu> On Jul 12, Robert, Francois wrote: > What about Wr for windows, Mr for mac, Lr for Linux/Unix/X, and Xr in > general where "X" stands for a wildcard ? ("X" has a long traditionnal use > as a "don't care" indicator for instance when describing bitwise flags in > bytes or words, in electronic component datasheets for instance) ? The problem with this approach is that we want to emphasize the fact that there is a single drawing library independent of any particular target platform. Naming each backend uniquely divides rather than unifies. Already, there has been some problem caused by the fact that the backend-abstraction layer has a name, (Xc). The solution there is to merge Xr/Xc into a single library, (whose name we are trying to resolve). -Carl From cworth at east.isi.edu Tue Jul 15 12:12:28 2003 From: cworth at east.isi.edu (Carl Worth) Date: Mon Aug 15 11:10:44 2005 Subject: [Xr] Cairo Message-ID: <16148.21020.223661.160004@scream.east.isi.edu> After pestering everyone we know, and exhausting every interesting word list, (art terms, colors, pigments, flowers, Latin flower names), we could fine, Keith and I have decided on a new name for Xr that we can live with: Cairo And if there aren't any major objections from this group, we'll go forward with that name. The name has lots of interesting thematic possibilities for branding. The connection with Egypt, the birthplace of writing, seems appropriate for a 2D graphics library with an emphasis on high-quality print output. We've decided against pursuing the Greek chi/rho pun and will instead change the "Xr" library prefix. We'll also take advantage of the name change to switch away from StuDlyCapS to a style that is easier_to_read. The plan for library function names is: cairo_move_to cairo_curve_to cairo_stroke cairo_fill etc. None of the code has changed yet, but when it does, I'll also provide some scripts to simplify the effort to shift existing code from the old names to the new. We have already setup a new domain: cairographics.org None of the web page has been updated at all. Since we are lousy artists/web page designers, we would invite anyone interested to contribute content/ideas for the site. Finally, I've done my best effort at setting up a new mailing list with the existing subscriptions: cairo@cairographics.org This will be the last message I send to xr@xwin.org. I'll followup now with a message to cairo@cairographics.org so that everyone can verify their subscription is working. Thanks for all the feedback on the naming question! -Carl -- Carl Worth USC Information Sciences Institute cworth@isi.edu From torgeir at pobox.com Tue Jul 15 16:04:05 2003 From: torgeir at pobox.com (Torgeir Veimo) Date: Mon Aug 15 11:10:44 2005 Subject: [Xr] Cairo In-Reply-To: <16148.21020.223661.160004@scream.east.isi.edu> References: <16148.21020.223661.160004@scream.east.isi.edu> Message-ID: <1058310245.4055.35.camel@africa.netenviron.com> On Tue, 2003-07-15 at 20:12, Carl Worth wrote: > After pestering everyone we know, and exhausting every interesting > word list, (art terms, colors, pigments, flowers, Latin flower names), > we could fine, Keith and I have decided on a new name for Xr that we > can live with: > > Cairo > > And if there aren't any major objections from this group, we'll go > forward with that name. > > The name has lots of interesting thematic possibilities for > branding. The connection with Egypt, the birthplace of writing, seems > appropriate for a 2D graphics library with an emphasis on high-quality > print output. > > We've decided against pursuing the Greek chi/rho pun and will instead > change the "Xr" library prefix. We'll also take advantage of the name > change to switch away from StuDlyCapS to a style that is > easier_to_read. The plan for library function names is: > > cairo_move_to > cairo_curve_to > cairo_stroke > cairo_fill > etc. Ohh, this will feel a bit strange to code with. Can't it be cr_move_to etc instead? -- Torgeir Veimo From torgeir at pobox.com Tue Jul 15 16:31:38 2003 From: torgeir at pobox.com (Torgeir Veimo) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] Re: [Xr] Cairo In-Reply-To: References: Message-ID: <1058311898.4055.37.camel@africa.netenviron.com> On Wed, 2003-07-16 at 00:19, Keith Packard wrote: > Around 0 o'clock on Jul 16, Torgeir Veimo wrote: > > > Ohh, this will feel a bit strange to code with. Can't it be cr_move_to > > etc instead? > > It could be, but I'm concerned that this short prefix will collide with > some existing facility in some operating system. The longer prefix seems > less likely to cause problems. Remember that cairo is intended to be a > cross-platform library, and so it will come in contact with a lot of > other libraries; keeping the namespace easily separated should reduce > future troubles. > > Also, given the short argument lists and brief function names, I was > thinking that a longer prefix wouldn't be too bad. > > What do you think? It probably just takes a while to get used to. -- Torgeir Veimo From cworth at east.isi.edu Tue Jul 15 12:23:08 2003 From: cworth at east.isi.edu (Carl Worth) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] Welcome to Cairo Message-ID: <16148.21660.959484.532846@scream.east.isi.edu> Welcome to the new mailing list for discussion/development of the Cairo graphics library. -Carl From keithp at keithp.com Tue Jul 15 16:19:00 2003 From: keithp at keithp.com (Keith Packard) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] Re: [Xr] Cairo In-Reply-To: Your message of "16 Jul 2003 00:04:05 BST." <1058310245.4055.35.camel@africa.netenviron.com> Message-ID: Around 0 o'clock on Jul 16, Torgeir Veimo wrote: > Ohh, this will feel a bit strange to code with. Can't it be cr_move_to > etc instead? It could be, but I'm concerned that this short prefix will collide with some existing facility in some operating system. The longer prefix seems less likely to cause problems. Remember that cairo is intended to be a cross-platform library, and so it will come in contact with a lot of other libraries; keeping the namespace easily separated should reduce future troubles. Also, given the short argument lists and brief function names, I was thinking that a longer prefix wouldn't be too bad. What do you think? -keith From xwin641 at vtnet.ca Tue Jul 15 18:50:37 2003 From: xwin641 at vtnet.ca (Trevor Woerner) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] Re: [Xr] Cairo In-Reply-To: References: Message-ID: <200307152150.37559.xwin641@vtnet.ca> On July 15, 2003 07:19 pm, Keith Packard wrote: [cairo_move_to() instead of cr_move_to()] > Also, given the short argument lists and brief function names, I was > thinking that a longer prefix wouldn't be too bad. > > What do you think? Personally I'm not opposed to the longer names. I'm not fond of code that prefers short, cryptic "appendages". From xwin641 at vtnet.ca Tue Jul 15 18:52:30 2003 From: xwin641 at vtnet.ca (Trevor Woerner) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] Re: [Xr] Cairo In-Reply-To: <16148.21020.223661.160004@scream.east.isi.edu> References: <16148.21020.223661.160004@scream.east.isi.edu> Message-ID: <200307152152.30992.xwin641@vtnet.ca> On July 15, 2003 03:12 pm, Carl Worth wrote: > Finally, I've done my best effort at setting up a new mailing list > with the existing subscriptions: > > cairo@cairographics.org Could the mailing list options be set such that replies are by default sent back to the list, instead of by default sent to the sender? Trevor From keithp at keithp.com Tue Jul 15 19:01:15 2003 From: keithp at keithp.com (Keith Packard) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] Re: [Xr] Cairo In-Reply-To: Your message of "Tue, 15 Jul 2003 21:52:30 EDT." <200307152152.30992.xwin641@vtnet.ca> Message-ID: Around 21 o'clock on Jul 15, Trevor Woerner wrote: > Could the mailing list options be set such that replies are by default > sent back to the list, instead of by default sent to the sender? Yes.. I know "reply-to considered harmful" and all that, but I've never found it to be a problem... -keith From cworth at east.isi.edu Tue Jul 15 19:14:08 2003 From: cworth at east.isi.edu (Carl Worth) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] Reply-to considerations. In-Reply-To: <200307152152.30992.xwin641@vtnet.ca> References: <16148.21020.223661.160004@scream.east.isi.edu> <200307152152.30992.xwin641@vtnet.ca> Message-ID: <16148.46320.937388.448822@scream.east.isi.edu> On Jul 15, Trevor Woerner wrote: > Could the mailing list options be set such that replies are by default > sent back to the list, instead of by default sent to the sender? It is possible, yes. The question of whether it's recommended or not leads into a large existing debate. Google for "reply-to munging considered harmful" and "reply-to munging considered useful" for the standard treatise from each camp. Personally, I fall in the "considered harmful" camp. Primarily because without a specific reply-to, I know how to easily get my mailer to reply to either the original sender or to the whole list, (and I occasionally want to do one or the other). But when reply-to is set to the list, I haven't found a way to tell my mailer to reply to just the sender. So, I've reverted this list back to not add any reply-to headers. If anyone has any compelling reason to switch, please let me know via private mail, (hint, this is easier to do since the reply-to has not been set), and we can discuss it off of the list. Now back to your previously scheduled program. Thanks, -Carl -- Carl Worth USC Information Sciences Institute cworth@isi.edu From dforste at arbornet.org Wed Jul 16 02:05:42 2003 From: dforste at arbornet.org (David Forster) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] Color transforms Message-ID: <20030716090542.GA36387@crateria.homeunix.net> I'm working on some code that builds up a 2D scene graph similar to how Macromedia's Flash works (but not Flash). Each graphic on the screen (shape, text, image) can have applied to it a coordinate transform and, optionally, a color transform. It seems Flash just allows a multiply and add transform, but I'd like to do more like a color->b&w transform. So while I can apply this color transform to my own graphics, external libraries like libsvg are troublesome, since they just communicate with Cairo directly. I know libsvg exports a vtable, but not all libraries may be as nice. I'd like to be able to interrupt API calls. I know that Cairo at some point needs to be cleaned up to remove Xlib-isms and to allow new external rendering devices to be defined (I assume?). So here's a proposal that should solve all problems: Make libcairo.so just be a thin framework for defining data types and passing calls of to a vtable, cairo_engine_t: cairo.h: #define CAIRO_NULL_ENGINE_ID 0x0000 typedef struct cairo_engine_s cairo_engine_t; struct cairo_engine_s { cairo_engine_t *previous; void *state; int api; /* See later... */ int version; /* Standard packed 0xMMmmpp */ cairo_state_t *cairo_state; /* Necessary? */ void (*move_to)(void *state, cairo_engine_t *engine, double x, double y); ... all functions ... }; cairo_state_t *cairo_create(cairo_engine_t *engine); /* ... */ void cairo_move_to(cairo_state_t *state, double x, double y); Real work will be handled by device-specific libraries. These will export a cairo_engine_t and a device-specific API: cairo-xlib.h: /* Top level engines like xlib always have ->previous = NULL */ cairo_engine_t *cairo_xlib_get_engine(Display *dpy, Window win); cairo_state_t *cairo_xlib_create(Display *dpy, Window win); Note the `previous,' `state,' and `api' fields. The `state' pointer is for device specific rendering state, while `previous' is for stacking engines. So, for me to interrupt set_color(): my_engine = malloc(sizeof(cairo_engine_t)); memset(my_engine, 0, sizeof(cairo_engine_t)); my_engine->previous = cairo_get_engine(state); my_engine->state = (my_state_t*)my_state; my_engine->id = CAIRO_NULL_ENGINE_ID; my_engine->version = 0; my_engine->cairo_state = state; /* ? */ my_engine->set_color = (void*)my_set_color; cairo_set_engine(state, my_engine); Note that I really should define my own CAIRO_MY_ENGINE_ID. Is it worth allowing such laziness? Engine IDs must be unique...hmm... Anyways, now whenever a library calls cairo_set_color() they get my function instead: void my_set_color(my_state_t *state, cairo_engine_t *engine, float r, float g, float b) { float rt, gt, bt; /* In reality support more complex transforms and no transform (pass-thru)... We could get state from engine->state, but this seems more convenient (no casting). */ rt = r * state->colorTransform.r; gt = g * state->colorTransform.g; bt = b * state->colorTransform.b; /* This is not good from a performance stand point, I know...Suggestions welcome. cairo_engine_active() searches for an engine with a non-NULL pointer at the given address, found by a macro for readability. This involves searching linearly through ->previous. I don't think this is AS bad as it seems. A macro/inline function may further reduce the effects. The first engine must define every function and those functions will of course not chain call. */ engine = cairo_engine_next(engine, CAIRO_ENGINE_OFFSET(set_color)); engine->set_color(engine->state, engine, rt, gt, bt); return; } void my_set_ctransform(my_state_t *state, my_color_t color); typedef struct my_state_s my_state_t; struct my_state_s { cairo_state_t *state; my_color_t colorTransform; }; Now in my code when ever I want to set a transform, I use my_set_ctransform() with my_state_t. It might be a little messy to now carry around both cairo_state_t and my_state_t, but I don't see a way around this. This way of things might seem a little tedious, but I don't expect interrupting functions will be common (but very useful when needed). This will also allow device-specific functions: cairo_pdf_embed_font(cairo_pdf_state_t *state, void *buffer, size_t size); /* NOTE: I know very little about PDF...But I know you can embed fonts in there somewhere...;) */ Some further APIs to tie up loose ends: cairo.h: int cairo_engine_major(cairo_state_t *state, int engine_api); int cairo_engine_minor(cairo_state_t *state, int engine_api); int cairo_engine_patch(cairo_state_t *state, int engine_api); /* CAIRO_NULL_ENGINE_ID never matches... */ int cairo_engine_supports(cairo_state_t *state, int engine_api); void *cairo_engine_state(cairo_state_t *state, int engine_api); cairo-pdf.h: #define CAIRO_PDF_ENGINE_ID 0x0010 cairo-opengl.h #define CAIRO_OPENGL_ENGINE_ID 0x0011 cairo-xcb.h #define CAIRO_XCB_ENGINE_ID 0x0012 Then the developer: if (cairo_engine_supports(state, CAIRO_PDF_ENGINE_ID)) { void *pdf_state = cairo_engine_state(state, CAIRO_PDF_ENGINE_ID); /* ... find the right font and put in buffer ... */ cairo_pdf_embed_font(pdf_state, font, font_size); /* Or would cairo_pdf_* know how to fish for it's own state from cairo_state_t*? If the user does it, only have to find it once. */ } Each CAIRO_*_ENGINE_ID would have to be unique, but that should be somewhat easy to keep straight. Problems might arise if multiple engines get stacked on top of each other without some coordination. Each engine should only accept and produce valid input/output and not expect to be the first one to see the arguments. As a further advantage, libcario.so could define a standard debug engine which may do some argument checking and provide verbose output, and/or a first engine that just produces trace output. Sorry for such a long post but I thought I'd be thorough...What do people think? I think this would add a lot of flexibility to Cairo. Thanks, -Dave From xr at paul.sladen.org Wed Jul 16 02:10:02 2003 From: xr at paul.sladen.org (Paul Sladen) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] Reply-to considerations. In-Reply-To: <16148.46320.937388.448822@scream.east.isi.edu> Message-ID: On Tue, 15 Jul 2003, Carl Worth wrote: > On Jul 15, Trevor Woerner wrote: > > Could the mailing list options be set such [...Reply-to:] > [...] when reply-to is set to the list, I haven't found a way to tell my > mailer to reply to just the sender. I think this is an issue that you need to take up with your mail client-- preferably without inconveniencing everyone else subscribed at the same time. I am exceeding surprised that VM would be unable to cope with the usual way in which mailing lists work; --Perhaps a little RTFM effort is required... > If anyone has any compelling reason to switch, please let me know via > private mail, (hint, this is easier to do since the reply-to has not > been set), No. It is now about 10 keystrokes to reply *just* to you; it is about 15 keystrokes to reply to the list only. Before it was 2 keystrokes to reply to the list and 2 keystrokes to reply privately. How can that be harder? There is a *reason* why Reply-to is used on mailing lists; it is called meta-data. You have just removed that useful meta-data, for everyone. Apologies for the flaming nature of this LART, -Paul -- War is inconsistent with Truth. Nottingham, GB From dforste at arbornet.org Wed Jul 16 03:34:06 2003 From: dforste at arbornet.org (David Forster) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] Color transforms In-Reply-To: <20030716090542.GA36387@crateria.homeunix.net> References: <20030716090542.GA36387@crateria.homeunix.net> Message-ID: <20030716103406.GA38349@crateria.homeunix.net> Opps, talked past myself a bit...Now it's very late. Hope I make sense. ;) It would be great if color transforms are implemented directly by Cairo. I got the impression, however, that the decision is to keep color simple...Extensions would allow developers to implement there own crazy ideas even when support libraries are oblivious to them. -Dave On Wed, Jul 16, 2003 at 03:05:42AM -0600, David Forster wrote: > I'm working on some code that builds up a 2D scene graph similar to > how Macromedia's Flash works (but not Flash). Each graphic on the > screen (shape, text, image) can have applied to it a coordinate > transform and, optionally, a color transform. It seems Flash just > allows a multiply and add transform, but I'd like to do more like a > color->b&w transform. From cworth at east.isi.edu Wed Jul 16 08:56:15 2003 From: cworth at east.isi.edu (Carl Worth) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] Color transforms In-Reply-To: <20030716090542.GA36387@crateria.homeunix.net> References: <20030716090542.GA36387@crateria.homeunix.net> Message-ID: <16149.30111.499742.961905@scream.east.isi.edu> On Jul 16, David Forster wrote: > I know that Cairo at some point needs to be cleaned up to remove > Xlib-isms and to allow new external rendering devices to be defined (I > assume?). Yes, Cairo does need some new architecting with respect to how the backends work. One result from the current Xr/Xc experiments is that we actually don't want to expose the backend interface as a separate library, (at least not until we've had more experience with different backends). The problem is that it's too hard to keep the split at the right place, especially as different backends have such widely different needs, (eg. the current Xr/Xc split aligns with the RENDER interface, but this is quite different than what you might want for PDF). It sounds like one thing that might satisfy your needs would be a sort of programmable "loopback" backend with the ability to call into Cairo again with a different actual backend. That's an interesting capability to keep in mind as the new architecture comes together. Thanks, -Carl -- Carl Worth USC Information Sciences Institute cworth@isi.edu From spitzak at d2.com Wed Jul 16 11:25:40 2003 From: spitzak at d2.com (Bill Spitzak) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] Color transforms In-Reply-To: <20030716090542.GA36387@crateria.homeunix.net> References: <20030716090542.GA36387@crateria.homeunix.net> Message-ID: <200307161820.h6GIK1DK029640@hermes.d2.com> On Wednesday 16 July 2003 02:05 am, David Forster wrote: > I know that Cairo at some point needs to be cleaned up to remove > Xlib-isms and to allow new external rendering devices to be defined (I > assume?). So here's a proposal that should solve all problems: > > Make libcairo.so just be a thin framework for defining data types and > passing calls of to a vtable, cairo_engine_t: This is probably necessary, not just for the purpose you want, but so that Cairo can be used as a redirectable graphics interface for printing. This will also provide an obvious way to change the implementation (between xlib images, simulation with Xlib, and Xrender and OpenGL, and between various levels of accuracy, such as an all-floating-point-color version. I have been designing something like this for fltk, based on an outside contribution called Fl_Device. Your recommendation looks a lot like Fl_Device, but I think some rearrangement can make it easier to implement new backends that are compatable with each other, and avoid the overhead of the "virtual function call" on many of the Cairo interfaces. First I would design your structures much like a C++ object, so that several instances can share the "vtable", yet have local "instance variables". Secondly I would place some (maybe a lot) of Cairo's logic in the device-independent portion: struct Cairo_Xlib_Engine { struct Cairo_Vtable* vtable; /* device-specific goes here, this is for an example only: */ XDisplay display; XWindow window; XColormap colormap; XGC gc; }; struct Cairo_Vtable { void (*identity)(Cairo_State*); void (*fill)(Cairo_State*); void (*stroke)(Caire_State*); ... }; struct Cairo_State { Cairo_Engine* engine; Cairo_State* previous; /* portable state information (again for example, not a recommendation) */ float A,B,C,D,X,Y; /* CTM */ float (*path)[2]; /* maybe the path is done here? */ int numpoints; }; An implementation of a typical cairo function: void cairo_fill(Cairo_State* state) { engine->vtable->fill(state); } void cairo_newpath(Cairo_State* state) { numpoints = 0; /* notice that the engine is NOT called */ /* Now the above is an example only, I am unsure where the division should be and whether there really should be any non-device-specific code. The above example is probably extreme, the path is likely to be put into the device. */ } "Which device" is considered part of the state: void cairo_push(Cairo_State* state) { Cairo_State* previous = new Cairo_State; *previous = *state; state->previous = previous; } void cairo_setdevice(Cairo_State* state, Cairo_Engine* device) { state->engine = device; /* It is required that changing the device resets everything. For many devices an implementation the preserves state while not being used is impossible or tremendously inefficient. */ state->vtable->reset(state); } Notice that all Xlib or other device-specific arguments are passed to the constructor for the engine, not Cairo. This means that machine-specific header files are not needed in order to call Cairo, which gets rid of 90% of my problems with the previous design. I can in fact make fltk support Cairo portably by adding a single "cairo_device(fltk::Window)" call which does not require any compromises in the design of Cairo or fltk at all. The interface does not have to be very complex. One good idea from Fl_Device is that almost all device-specific stuff is not considered part of the core interface. It provides, for instance, a constructor for a postscript pipe (to lpr for printing) that takes a lot of arguments to determine how to scale and center the image on a sheet of paper, but all this is in the postscript pipe part and has nothing to do with Cairo. In addition the "newpage" command is part of the device-specific interface. The other thing I think should be done is make all the transformations, and all path construction that is more complex than lineto be device-independent. This will avoid the need to reimplement these for every device, and to design the interface to allow the addition of new curve types easily. The way to do this is to provide a "transformed" interface for adding to the path. Probably should take a packed array of points, rather than one call per point. Also an interface for transforming a given x,y. Curveto is then implemented portably by transforming the points, figuring out the subdivisions so the error is less than 1/4 transformed pixel, and then calling the transformed interface with the resulting line segments. I am unsure if this "transformed" interface should be part of the engine, or should be itself part of the portable cairo state. Making it portable will also allow the portable part to do clipping (but clip paths will still need to be sent to the device so it can clip text and images). It will also allow push/pop of state to be done entirely portably. -- ,~,~,~,~ ~ ~ ~ ~ /\_ _|_========___ Bill Spitzak ~~~/\/\\~~~~~~\____________/~~~~~~~~ spitzak@d2.com From cworth at east.isi.edu Wed Jul 16 11:20:35 2003 From: cworth at east.isi.edu (Carl Worth) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] Color transforms In-Reply-To: <200307161820.h6GIK1DK029640@hermes.d2.com> References: <20030716090542.GA36387@crateria.homeunix.net> <200307161820.h6GIK1DK029640@hermes.d2.com> Message-ID: <16149.38771.791980.430311@scream.east.isi.edu> David and Bill, Thanks for starting some ideas about virtualizing the backend. I hope to be able to take a closer look at this soon and make some concrete comments/proposals. In the meantime, one nitpicky response to a comment not actually part of the main thread: On Jul 16, Bill Spitzak wrote: > Curveto is then implemented portably by transforming the points, > figuring out the subdivisions so the error is less than 1/4 > transformed pixel, and then calling the transformed interface with > the resulting line segments. Actually, it's important to keep the curve as a curve, (rather than an approximation by line segments), until the stroke operation [*]. Approximating the curve to within an error value is a very different thing than approximating the stroked outline to within the same error value. Many graphics systems get this wrong and the resulting errors can be visible with large line width and sharp curvature. -Carl [*] Warning, the following paragraph is for pedants only: Someone familiar with the algorithm within Cairo might point out that the curve stroking algorithm actually does operate on a piecewise linear approximation of the curve. So the approximation could happen earlier. But the path data structure would have to maintain the distinction between linear segments belonging to curves vs. those belonging to true linear path segments so the joins could be handled differently. Come to think of it, for round joins no distinction is actually needed --- sounds like there's room for a minor optimization of round joins here. From dforste at arbornet.org Wed Jul 16 17:44:35 2003 From: dforste at arbornet.org (David Forster) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] Color transforms In-Reply-To: <16149.30111.499742.961905@scream.east.isi.edu> References: <20030716090542.GA36387@crateria.homeunix.net> <16149.30111.499742.961905@scream.east.isi.edu> Message-ID: <20030717004435.GA42226@crateria.homeunix.net> On Wed, Jul 16, 2003 at 11:56:15AM -0400, Carl Worth wrote: > One result from the current Xr/Xc experiments is that we actually > don't want to expose the backend interface as a separate library, (at > least not until we've had more experience with different > backends). The problem is that it's too hard to keep the split at the > right place, especially as different backends have such widely > different needs, (eg. the current Xr/Xc split aligns with the RENDER > interface, but this is quite different than what you might want for > PDF). I assumed the `split' would be right at Cairo's API level. What would Cairo do that could apply to all backends? There seems to be a `dual' nature in Cairo between being a generic frontend to Postscript-like systems and actually being a Postscript-like system for accelerated framebuffer displays (Xc). Perhaps there could be a generic libcairo-fb.so backend which in turn had it's own function table for diffrent framebuffer-like displays. This backend could then be monolithic until it's API settles down. My motivation for spliting things up is to avoid having to have a bunch of diffrent libcairo.so's that get swapped out based on what set of targets the end user wants. I.e., supporting an SDL target would require SDL be installed, supporting PDF might require a libpdf, etc. What if I don't want SDL? This is no problem while Cairo is small, but if a lot of backends become available it would be a mess. > It sounds like one thing that might satisfy your needs would be a sort > of programmable "loopback" backend with the ability to call into Cairo > again with a different actual backend. That's an interesting > capability to keep in mind as the new architecture comes together. That's essentially what I proposed but I looked at it a little differently. I assume you mean you'd have a backend with a list of `dummy/pass-thru' functions which just pass their arguments on to the real backend, and then I'd just override the functions I want to change. At any rate, all I care about being able to do is modify colors as they pass through...What ever works. ;) Thanks, -Dave From spitzak at d2.com Wed Jul 16 17:50:51 2003 From: spitzak at d2.com (Bill Spitzak) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] Color transforms In-Reply-To: <16149.38771.791980.430311@scream.east.isi.edu> References: <20030716090542.GA36387@crateria.homeunix.net> <200307161820.h6GIK1DK029640@hermes.d2.com> <16149.38771.791980.430311@scream.east.isi.edu> Message-ID: <200307170045.h6H0j9DK006077@hermes.d2.com> On Wednesday 16 July 2003 11:20 am, Carl Worth wrote: > On Jul 16, Bill Spitzak wrote: > > Curveto is then implemented portably by transforming the points, > > figuring out the subdivisions so the error is less than 1/4 > > transformed pixel, and then calling the transformed interface with > > the resulting line segments. > > Actually, it's important to keep the curve as a curve, (rather than an > approximation by line segments), until the stroke operation [*]. > Approximating the curve to within an error value is a very different > thing than approximating the stroked outline to within the same error > value. Many graphics systems get this wrong and the resulting errors > can be visible with large line width and sharp curvature. I had not thought about that (my library did not bother with drawing lines on paths other than to use the graphics system's pen). Converting a path to a stroke outline is actually really complex and maybe should be in the device-independent portion. The device-dependent portion would only have a method to fill a fully-constructed and transformed path, and perhaps a "fast" line drawing for any line thicknesses less than 1. However this may have problems in that it may make it impossible to use some acceleration that the hardware may have. > Someone familiar with the algorithm within Cairo might point out that > the curve stroking algorithm actually does operate on a piecewise > linear approximation of the curve. So the approximation could happen > earlier. But the path data structure would have to maintain the > distinction between linear segments belonging to curves vs. those > belonging to true linear path segments so the joins could be handled > differently. Come to think of it, for round joins no distinction is > actually needed --- sounds like there's room for a minor optimization > of round joins here. This sounds like the problem can be solved by being able to indicate at each point what type of line-join is wanted. Perhaps this could be added to the interface instead? Then curveto could produce straight line segments with round joins. It also seems that would be useful for producing some shapes that GUI's want, for instance a rectangle with some square and some rounded corners. PostScript seems to join the segments with whatever join type the user has selected. But it also has several other bugs, for instance round joins seem to be done by splatting a circle atop the intersection, which is visible if the lines are shorter than they are wide. -- ,~,~,~,~ ~ ~ ~ ~ /\_ _|_========___ Bill Spitzak ~~~/\/\\~~~~~~\____________/~~~~~~~~ spitzak@d2.com From cworth at east.isi.edu Wed Jul 16 17:26:14 2003 From: cworth at east.isi.edu (Carl Worth) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] Color transforms In-Reply-To: <200307170045.h6H0j9DK006077@hermes.d2.com> References: <20030716090542.GA36387@crateria.homeunix.net> <200307161820.h6GIK1DK029640@hermes.d2.com> <16149.38771.791980.430311@scream.east.isi.edu> <200307170045.h6H0j9DK006077@hermes.d2.com> Message-ID: <16149.60710.619741.874601@scream.east.isi.edu> On Jul 16, Bill Spitzak wrote: > Converting a path to a stroke outline is actually really complex and maybe > should be in the device-independent portion. Yes, it is complex. One nice thing about taking care of tasks like this in the device-independent piece is that we can have better guarantees of matching output on different devices, (especially when some backend devices have shortcomings in their own implementations of similar algorithms). The balancing act is to maintain good performance while generating high-quality matching output. > PostScript seems to join the segments with whatever join type the user has > selected. Yes, this is the behavior we've seen from every implementation we've been able to test. And from reading the description of the flattenpath operator, this behavior may be mandated by the specification. It's not hard to construct a test case that exposes the problem with this approach. The attached file has a single spline stroked with both a narrow and wide linewidth. The flatness is set to 0.5 which is defined to make the result correct within 1/2 device pixels. But on every interpreter I've tried the cusp of the wide spline is incorrect by several pixels, (4 long straight line segments are noticeable on the contour). > This sounds like the problem can be solved by being able to indicate at each > point what type of line-join is wanted. The effect is similar to stroking line segments with round joins, but Cairo currently has a much more efficient algorithm for stroking splines than for doing round joins. What occurred to me today is that the efficient algorithm for spline stroking could probably also be applied to the case of straight lines with round joins. > But it also has several other bugs, for instance round joins seem > to be done by splatting a circle atop the intersection, which is > visible if the lines are shorter than they are wide. This one is definitely a bug in the specification. It explicitly states that the "wrong side" of the circle will show through in these cases. The algorithm in Cairo avoids both of these bugs, so it shouldn't be hard to generate correct results on any output device. -Carl -------------- next part -------------- A non-text attachment was scrubbed... Name: badspline.eps Type: application/postscript Size: 427 bytes Desc: not available Url : http://lists.freedesktop.org/archives/cairo/attachments/20030716/2b9fadb5/badspline.eps From dforste at arbornet.org Wed Jul 16 19:12:45 2003 From: dforste at arbornet.org (David Forster) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] Color transforms In-Reply-To: <200307161820.h6GIK1DK029640@hermes.d2.com> References: <20030716090542.GA36387@crateria.homeunix.net> <200307161820.h6GIK1DK029640@hermes.d2.com> Message-ID: <20030717021245.GB42226@crateria.homeunix.net> On Wed, Jul 16, 2003 at 11:25:40AM -0700, Bill Spitzak wrote: > backends that are compatable with each other, and avoid the overhead > of the "virtual function call" on many of the Cairo interfaces. You mean my find-the-non-NULL loop...You still do virtual calls. Neither, I think, are that expensive. > First I would design your structures much like a C++ object, so that several > instances can share the "vtable", yet have local "instance variables". Yeah, totally right. Opps. ;) > Secondly I would place some (maybe a lot) of Cairo's logic in the > device-independent portion: PostScript/PDF are very capable targets. I don't think there's going to be much that's device-independent... > > struct Cairo_Xlib_Engine { [...] > }; > > struct Cairo_Vtable { [...] > }; > > struct Cairo_State { > Cairo_Engine* engine; > Cairo_State* previous; [...] > }; I don't see how this works. Where does Cairo_Xlib_Engine fit into this? How do I override functions? How do you efficiently get each engine's state to it without doing C++ subclassing, which requires prior knowledge of what you are subclassing? > void cairo_setdevice(Cairo_State* state, Cairo_Engine* device) { > state->engine = device; ... > state->vtable->reset(state); > } I assumed just new `mini-engines' would be added at appropriate times. There's no reason to reset the primary engine unless you're changing it, which doesn't seem useful. > The other thing I think should be done is make all the > transformations, and all path construction that is more complex than > lineto be device-independent. This will avoid the need to > reimplement these for every device, and to design the interface to > allow the addition of new curve types easily. PostScript/PDF already do a good job of doing curves, though. You want those backends to handle this. If there's anything you don't like about a particular PostScript implementation, fixing that is better left to the backend. -Dave From spitzak at d2.com Wed Jul 16 19:43:49 2003 From: spitzak at d2.com (Bill Spitzak) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] Color transforms In-Reply-To: <16149.60710.619741.874601@scream.east.isi.edu> References: <20030716090542.GA36387@crateria.homeunix.net> <200307170045.h6H0j9DK006077@hermes.d2.com> <16149.60710.619741.874601@scream.east.isi.edu> Message-ID: <200307170238.h6H2c7DK024794@hermes.d2.com> On Wednesday 16 July 2003 05:26 pm, Carl Worth wrote: > The effect is similar to stroking line segments with round joins, but > Cairo currently has a much more efficient algorithm for stroking > splines than for doing round joins. What occurred to me today is that > the efficient algorithm for spline stroking could probably also be > applied to the case of straight lines with round joins. So is it possible to decompose the curve into line segments without having to know if it is going to be stroked or filled or knowing the line thickness, as long as the resulting line joins can be marked whether they are this new type or not? -- ,~,~,~,~ ~ ~ ~ ~ /\_ _|_========___ Bill Spitzak ~~~/\/\\~~~~~~\____________/~~~~~~~~ spitzak@d2.com From dforste at arbornet.org Wed Jul 16 19:51:47 2003 From: dforste at arbornet.org (David Forster) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] Color transforms In-Reply-To: <16149.60710.619741.874601@scream.east.isi.edu> References: <20030716090542.GA36387@crateria.homeunix.net> <200307161820.h6GIK1DK029640@hermes.d2.com> <16149.38771.791980.430311@scream.east.isi.edu> <200307170045.h6H0j9DK006077@hermes.d2.com> <16149.60710.619741.874601@scream.east.isi.edu> Message-ID: <20030717025147.GA44205@crateria.homeunix.net> On Wed, Jul 16, 2003 at 08:26:14PM -0400, Carl Worth wrote: > On Jul 16, Bill Spitzak wrote: > > Converting a path to a stroke outline is actually really complex and > > maybe should be in the device-independent portion. > Yes, it is complex. One nice thing about taking care of tasks like > this in the device-independent piece is that we can have better > guarantees of matching output on different devices, (especially when > some backend devices have shortcomings in their own implementations > of similar algorithms). (I'm getting into an argument I don't want to be in..But since I've opened my mouth on the subject... ;) But what's the best way to fix PostScript? Emit a stream of lineto's or define a fixed `cairo_curveto' operator? Defining the operator would keep things compact. The problem with implementing curves as device-independent is the backend might have a better way of fixing things (if they need to be fixed at all). Now, I'm taking ``in the device-independent piece'' to mean in the pipeline and before the backend ever sees things. Cairo could just pass things along to the backend, and then provide a curves-on-lines function for broken/incomplete renders. Oh well...It's been sometime since I've looked at PostScript. All I'm saying though, is it'd be a shame to through a renderer's perfectly good optimized curves implementation out because most renderers got it wrong. Cairo should leave it up to the backend to decide what's broken, how to fix it, and what's the best way to provide `consistent Cairo' output. -Dave From spitzak at d2.com Wed Jul 16 20:13:09 2003 From: spitzak at d2.com (Bill Spitzak) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] Color transforms In-Reply-To: <20030717021245.GB42226@crateria.homeunix.net> References: <20030716090542.GA36387@crateria.homeunix.net> <200307161820.h6GIK1DK029640@hermes.d2.com> <20030717021245.GB42226@crateria.homeunix.net> Message-ID: <200307170307.h6H37RDK009463@hermes.d2.com> On Wednesday 16 July 2003 07:12 pm, David Forster wrote: > > Secondly I would place some (maybe a lot) of Cairo's logic in the > > device-independent portion: > > PostScript/PDF are very capable targets. I don't think there's going > to be much that's device-independent... Yes I am thinking now that almost everything should be in the device-dependent part. If it is in the device-independent part then it indicates that perhaps Cairo is too high-level. The main thing that definately must be device-independent is some portion of the save/restore state, because I think the "current device" should be part of the Cairo state. However the devices themselves must have state that has to be saved/restored as well so they must do part of it. The only other thing I am considering (because in a similar library I am desiging this turned out to be vastly easier) is to make the device-dependent part only accept paths made of straight lines. curveto would not be a virtual function. This requires that transformations be done device-independent so the curveto implementation can determine how many straight lines to break the line into. And apparently it will require special line join types so stroke can be done correctly, unless stroke itself is device-independent... The main advantage is that other curve types (ie cubic sections and splines of other orders) can be added without modifying Cairo or doing complex math to convert them to the closest Bezier. There are obvious disadvantages to this as well, primarily that any faster solution by the device itself is impossible. > Where does Cairo_Xlib_Engine fit into > this? How do I override functions? How do you efficiently get each > engine's state to it without doing C++ subclassing, which requires > prior knowledge of what you are subclassing? I would recommend that functions be overridden by writing an entire wrapper engine for another Cairo engine. It has to implement all the calls and call the other one for each of them, modifying the color or whatever before doing so. The only public interface and the only thing you can subclass is the generic engine. The existence and implementation of Cairo_Xlib_Engine is totally hidden in the xlib version, the only public call is something like: Cairo_Engine* cairo_create_xlib_engine(XDisplay, XWindow, XColormap); > There's no reason to reset the primary engine unless you're changing > it, which doesn't seem useful. That wasn't too clear. What I meant is that when you change devices in Cairo, you should always get the identity transformation and everything including the clip set to default values. They are *never* inherited from the previous engine or the previous state of the new device. This I think is necessary for efficiency and to make implementing devices easier. -- ,~,~,~,~ ~ ~ ~ ~ /\_ _|_========___ Bill Spitzak ~~~/\/\\~~~~~~\____________/~~~~~~~~ spitzak@d2.com From keithp at keithp.com Wed Jul 16 20:33:11 2003 From: keithp at keithp.com (Keith Packard) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] Color transforms In-Reply-To: Your message of "Wed, 16 Jul 2003 20:51:47 MDT." <20030717025147.GA44205@crateria.homeunix.net> Message-ID: Around 20 o'clock on Jul 16, David Forster wrote: > But what's the best way to fix PostScript? My plan was to have cairo emit trapezoids instead of higher-level primitives. This will avoid the bugs in PostScript and provide figures which exactly match the screen. The alternative would be to accept some device-dependent variation in the results, and I'm not willing to live with that. -keith From xwin641 at vtnet.ca Wed Jul 16 21:06:06 2003 From: xwin641 at vtnet.ca (Trevor Woerner) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] Color transforms In-Reply-To: <20030716090542.GA36387@crateria.homeunix.net> References: <20030716090542.GA36387@crateria.homeunix.net> Message-ID: <200307170006.06270.xwin641@vtnet.ca> On July 16, 2003 05:05 am, David Forster wrote: > if (cairo_engine_supports(state, CAIRO_PDF_ENGINE_ID)) This kinda stuff reminds me of PEX. :-( What a pain, from the application writer's point of view, to have to spend so much time figuring out what functionality is supported and what isn't. IMHO, if multi-platform is what everyone wants, it would be slightly better to have less functionality but be consistent with the API and capabilities, than to have the potential of some capabilities on some systems but not on others. Just my opinion, of course :-) Trevor From keithp at keithp.com Wed Jul 16 21:35:18 2003 From: keithp at keithp.com (Keith Packard) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] Color transforms In-Reply-To: Your message of "Thu, 17 Jul 2003 00:06:06 EDT." <200307170006.06270.xwin641@vtnet.ca> Message-ID: Around 0 o'clock on Jul 17, Trevor Woerner wrote: > IMHO, if multi-platform is what everyone wants, it would be slightly > better to have less functionality but be consistent with the API and > capabilities, than to have the potential of some capabilities on some > systems but not on others. Every system can support raster images, so there's no reason to consider limited functionality anywhere; we can always dump images. That's going to be necessary for PostScript in any case as it doesn't support translucency. Other systems recognize when the output cannot be generated with higher level primitives and fall back to rasterization automatically, I think we can manage the same in cairo. Device-independent should mean that the API have no limitations caused by the rasterization engine for a particular device, but we will still need some media-specific functionality (like 'showpage'). Getting a PS driver running is a high priority mostly to make sure the API works for printing, not to make sure we can generate postscript (that's the easy part). -keith From cworth at east.isi.edu Thu Jul 17 01:14:55 2003 From: cworth at east.isi.edu (Carl Worth) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] Color transforms In-Reply-To: <200307170238.h6H2c7DK024794@hermes.d2.com> References: <20030716090542.GA36387@crateria.homeunix.net> <200307170045.h6H0j9DK006077@hermes.d2.com> <16149.60710.619741.874601@scream.east.isi.edu> <200307170238.h6H2c7DK024794@hermes.d2.com> Message-ID: <16150.23295.459165.371232@scream.east.isi.edu> On Jul 16, Bill Spitzak wrote: > So is it possible to decompose the curve into line segments without having to > know if it is going to be stroked or filled or knowing the line thickness, as > long as the resulting line joins can be marked whether they are this new type > or not? Not having tried it yet, I think so. But there may be a hidden issue or two lurking here. -Carl From cworth at east.isi.edu Thu Jul 17 01:28:18 2003 From: cworth at east.isi.edu (Carl Worth) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] Color transforms In-Reply-To: <200307170307.h6H37RDK009463@hermes.d2.com> References: <20030716090542.GA36387@crateria.homeunix.net> <200307161820.h6GIK1DK029640@hermes.d2.com> <20030717021245.GB42226@crateria.homeunix.net> <200307170307.h6H37RDK009463@hermes.d2.com> Message-ID: <16150.24098.454090.401385@scream.east.isi.edu> On Jul 16, Bill Spitzak wrote: > The existence and implementation of Cairo_Xlib_Engine is totally > hidden in the xlib version, the only public call is something like: > > Cairo_Engine* cairo_create_xlib_engine(XDisplay, XWindow, > XColormap); The idea I've started developing in the current API is that the device is specified by creating a device-specific cairo_surface. Then, one can set this as the active surface using cairo_set_target_surface. That way, the device is definitely part of the state as you propose. Also, there are convenience functions cairo_set_target_* that both create the device-specific surface and set it as the target. One idea that should be possible with this approach is graphics operations using surfaces from separate devices, (think compositing images from two different X servers for example). That could be a lot of fun if we can get it to work. > That wasn't too clear. What I meant is that when you change devices in Cairo, > you should always get the identity transformation and everything including > the clip set to default values. They are *never* inherited from the previous > engine or the previous state of the new device. This I think is necessary for > efficiency and to make implementing devices easier. I'm not sure this is necessary. I think the semantics would get pretty muddled if there were an implicit reset of the graphics state when changing devices. The worst part I can think of is that the frontend will have to keep some state, (like the clipping path), that may also be stored in the backend. That doesn't sound fatal to me. And if there are efficiency problems, the user can always do the reset manually, (or use a separate cairo_state object), or whatever. -Carl From cworth at east.isi.edu Thu Jul 17 01:31:29 2003 From: cworth at east.isi.edu (Carl Worth) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] Color transforms In-Reply-To: References: <20030717025147.GA44205@crateria.homeunix.net> Message-ID: <16150.24289.366347.322457@scream.east.isi.edu> On Jul 16, Keith Packard wrote: > > But what's the best way to fix PostScript? > > My plan was to have cairo emit trapezoids instead of higher-level > primitives. This will avoid the bugs in PostScript and provide figures > which exactly match the screen. The alternative would be to accept some > device-dependent variation in the results, and I'm not willing to live > with that. One other alternative is to characterize the bugs well and use higher-level primitives in those cases where we trust the PostScript implementation to draw things correctly. -Carl From otaylor at redhat.com Thu Jul 17 07:27:06 2003 From: otaylor at redhat.com (Owen Taylor) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] Color transforms In-Reply-To: References: Message-ID: <1058452026.9827.17.camel@poincare.devel.redhat.com> On Wed, 2003-07-16 at 23:33, Keith Packard wrote: > Around 20 o'clock on Jul 16, David Forster wrote: > > > But what's the best way to fix PostScript? > > My plan was to have cairo emit trapezoids instead of higher-level > primitives. This will avoid the bugs in PostScript and provide figures > which exactly match the screen. The alternative would be to accept some > device-dependent variation in the results, and I'm not willing to live > with that. Well, I would strongly suggest against emitting text as trapezoids :-) I think you'll have to accept some device dependent variation of text; downloading client side fonts is the right way to do text, so you have a guaranteed font, but you don't have any real guarantees about how the rasterizer will rasterize it in detail. I don't know if that has implcations for what variation to accept elsewhere. Regards, Owen From otaylor at redhat.com Thu Jul 17 07:32:03 2003 From: otaylor at redhat.com (Owen Taylor) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] Color transforms In-Reply-To: References: Message-ID: <1058452323.9827.23.camel@poincare.devel.redhat.com> On Thu, 2003-07-17 at 00:35, Keith Packard wrote: > Around 0 o'clock on Jul 17, Trevor Woerner wrote: > > > IMHO, if multi-platform is what everyone wants, it would be slightly > > better to have less functionality but be consistent with the API and > > capabilities, than to have the potential of some capabilities on some > > systems but not on others. > > Every system can support raster images, so there's no reason to consider > limited functionality anywhere; we can always dump images. That's going > to be necessary for PostScript in any case as it doesn't support > translucency. Other systems recognize when the output cannot be generated > with higher level primitives and fall back to rasterization automatically, > I think we can manage the same in cairo. > > Device-independent should mean that the API have no limitations caused by > the rasterization engine for a particular device, but we will still need > some media-specific functionality (like 'showpage'). Getting a PS driver > running is a high priority mostly to make sure the API works for printing, > not to make sure we can generate postscript (that's the easy part). I would suggest that you should try to work the API so that the printing API isn't glommed into the rendering API, but forms a separate layer; that is, instead of cairo_showpage (context), have something more along the lines of: print_job = cairo_print_job_new_file (filename); cairo_print_job_set_context (print_job, context); /* draw a page onto context */ cairo_print_job_next_page (print_job); Or whatever. If it's set up this way, then you don't have to worry about having lots of methods that only apply for some output devices. Regards, Owen From cworth at east.isi.edu Thu Jul 17 06:43:41 2003 From: cworth at east.isi.edu (Carl Worth) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] Color transforms In-Reply-To: <1058452323.9827.23.camel@poincare.devel.redhat.com> References: <1058452323.9827.23.camel@poincare.devel.redhat.com> Message-ID: <16150.43021.652375.273170@scream.east.isi.edu> On Jul 17, Owen Taylor wrote: > I would suggest that you should try to work the API so that the printing > API isn't glommed into the rendering API, but forms a separate layer; > that is, instead of cairo_showpage (context), have something more along > the lines of: > > print_job = cairo_print_job_new_file (filename); I might take a contrary view that "printing" shouldn't be any harder than any other kind of graphics creation. For example, I'd like to be able to take a chunk of code that generates a PNG and just flip a switch at one point in the code and generate a PDF instead. > Or whatever. If it's set up this way, then you don't have to worry about > having lots of methods that only apply for some output devices. Hopefully there won't be lots of functions. I think most of the device-specific stuff can be handled at that time of device-specific surface creation. show_page is certainly one one truly unique capability. Are there many others that people can think of? -Carl From michael at ximian.com Thu Jul 17 08:29:49 2003 From: michael at ximian.com (Michael Meeks) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] Color transforms In-Reply-To: <16150.43021.652375.273170@scream.east.isi.edu> References: <1058452323.9827.23.camel@poincare.devel.redhat.com> <16150.43021.652375.273170@scream.east.isi.edu> Message-ID: <1058455788.10243.588.camel@michael.home> Hi Carl, On Thu, 2003-07-17 at 14:43, Carl Worth wrote: > > Or whatever. If it's set up this way, then you don't have to worry about > > having lots of methods that only apply for some output devices. > > Hopefully there won't be lots of functions. I think most of the > device-specific stuff can be handled at that time of device-specific > surface creation. > > show_page is certainly one one truly unique capability. Are there many > others that people can think of? Presumably for .png there are a load of strange compression options which would work well at device surface creation, but for .pdf are there not all manner of web-linking / even more exotic bits that people may want emitted ? It's not at all obvious to me how to support that sort of thing short of exposing the internals of the backend rendering method somehow. But perhaps I missed the point, Regards, Michael. -- michael@ximian.com <><, Pseudo Engineer, itinerant idiot From cworth at east.isi.edu Thu Jul 17 08:04:57 2003 From: cworth at east.isi.edu (Carl Worth) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] Color transforms In-Reply-To: <1058455788.10243.588.camel@michael.home> References: <1058452323.9827.23.camel@poincare.devel.redhat.com> <16150.43021.652375.273170@scream.east.isi.edu> <1058455788.10243.588.camel@michael.home> Message-ID: <16150.47897.889.308194@scream.east.isi.edu> On Jul 17, Michael Meeks wrote: > Presumably for .png there are a load of strange compression options > which would work well at device surface creation, but for .pdf are there > not all manner of web-linking / even more exotic bits that people may > want emitted ? PDF does have lots of exotic things. But Cairo does not intend to be the be-all and end-all of PDF creation libraries. Cairo intends to be a 2D graphics library capable of drawing to displays or images, (whether raster images or PDF/PostScript). So I don't see it as a problem that Cairo won't expose an API for generating all of that. -Carl From spitzak at d2.com Thu Jul 17 12:05:56 2003 From: spitzak at d2.com (Bill Spitzak) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] Color transforms In-Reply-To: <16150.24098.454090.401385@scream.east.isi.edu> References: <20030716090542.GA36387@crateria.homeunix.net> <200307170307.h6H37RDK009463@hermes.d2.com> <16150.24098.454090.401385@scream.east.isi.edu> Message-ID: <200307171900.h6HJ08DK003531@hermes.d2.com> On Thursday 17 July 2003 01:28 am, Carl Worth wrote: > The idea I've started developing in the current API is that the device > is specified by creating a device-specific cairo_surface. Then, one > can set this as the active surface using cairo_set_target_surface. > That way, the device is definitely part of the state as you propose. > > Also, there are convenience functions cairo_set_target_* that both > create the device-specific surface and set it as the target. Sorry my terminology was getting muddled. What you are describing is exactly what I was thinking. The "surface" specifies the device. There is no real difference between switching windows on the same X display, and switching to a window on another X display or to a printer. > One idea that should be possible with this approach is graphics > operations using surfaces from separate devices, (think compositing > images from two different X servers for example). That could be a lot > of fun if we can get it to work. That would be a really good idea. It seems this would require Cairo to have a "return this area as an image" call. The "composite from A to B" call would actually call B's device. It can then detect if A is something it can talk to directly, and if not it calls the portable "return this image" call and then uses the result as the source. > > That wasn't too clear. What I meant is that when you change devices in > > Cairo, you should always get the identity transformation and everything > > including the clip set to default values. > I'm not sure this is necessary. I think the semantics would get pretty > muddled if there were an implicit reset of the graphics state when > changing devices. The worst part I can think of is that the frontend > will have to keep some state, (like the clipping path), that may also > be stored in the backend. That doesn't sound fatal to me. > > And if there are efficiency problems, the user can always do the reset > manually, (or use a separate cairo_state object), or whatever. The main reason I wanted this is that we can avoid any calls that expand the clip region. Changing surfaces and the restore command would be the only ways to make the clip region larger. If the clip region is copied from the current state then you would have to have a reset-clip call, which will also mean that Cairo clipping must be seperated from window-system clipping so you cannot draw outside the window by doing the reset call. The other concern is that this would require all the state to be accessible so it can be copied to the new surface. It could also be wasteful if when switching surfaces all the state is copied, just to be wiped out by changes the program makes immediately after switching to the surface. If surfaces themselves contain a state (and thus you get this state when you switch to the surface) then some of these problems are avoided, but you still need a reset-clip call, because restore cannot be used (it would switch you back to the previous surface). It also requires all surfaces that exist to keep a complete state, which might be a lot more difficult than keeping the state for only the "active" surfaces. -- ,~,~,~,~ ~ ~ ~ ~ /\_ _|_========___ Bill Spitzak ~~~/\/\\~~~~~~\____________/~~~~~~~~ spitzak@d2.com From dforste at arbornet.org Thu Jul 17 12:18:52 2003 From: dforste at arbornet.org (David Forster) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] Color transforms In-Reply-To: <1058455788.10243.588.camel@michael.home> References: <1058452323.9827.23.camel@poincare.devel.redhat.com> <16150.43021.652375.273170@scream.east.isi.edu> <1058455788.10243.588.camel@michael.home> Message-ID: <20030717191852.GA50092@crateria.homeunix.net> On Thu, Jul 17, 2003 at 04:29:49PM +0100, Michael Meeks wrote: > Presumably for .png there are a load of strange compression options > which would work well at device surface creation, but for .pdf are there > not all manner of web-linking / even more exotic bits that people may > want emitted ? > > It's not at all obvious to me how to support that sort of thing short > of exposing the internals of the backend rendering method somehow. Think of Xlib; Cairo doesn't replace it, it just sits over it's drawing functionality. Likewise, you would have a libpdf that the Cairo backend sits over. When you crate a `PDF surface' you just hand over what ever data types libpdf made, just as you do with Xlib (or you could have a convenience surface creator that handles everything). Ditto with PNG. A backend, of course, could do everything but that design will be understandably limited. -Dave From spitzak at d2.com Thu Jul 17 12:40:25 2003 From: spitzak at d2.com (Bill Spitzak) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] Color transforms In-Reply-To: <20030717191852.GA50092@crateria.homeunix.net> References: <1058455788.10243.588.camel@michael.home> <20030717191852.GA50092@crateria.homeunix.net> Message-ID: <200307171934.h6HJYbDK027857@hermes.d2.com> On Thursday 17 July 2003 12:18 pm, David Forster wrote: > On Thu, Jul 17, 2003 at 04:29:49PM +0100, Michael Meeks wrote: > > Presumably for .png there are a load of strange compression options > > which would work well at device surface creation, but for .pdf are there > > not all manner of web-linking / even more exotic bits that people may > > want emitted ? > > > > It's not at all obvious to me how to support that sort of thing short > > of exposing the internals of the backend rendering method somehow. > > Think of Xlib; Cairo doesn't replace it, it just sits over it's > drawing functionality. Likewise, you would have a libpdf that the > Cairo backend sits over. When you crate a `PDF surface' you just hand > over what ever data types libpdf made, just as you do with Xlib (or > you could have a convenience surface creator that handles everything). > Ditto with PNG. > > A backend, of course, could do everything but that design will be > understandably limited. Even without exposing the pdf implementation, you could still provide a lot of pdf-specific functionality: cairo_surface* surface = cairo_pdf_create( pdf-specific-arguments ); cairo_set_surface(cairo_state, surface); cairo_lineto(cairo_state, x,y); // device-independent call // here is an example of a pdf-specific call: cairo_pdf_start_link(cairo_state, "http://www.foo.bar"); If written this way, only the existence of special functions, in the same header file as the one that creates the pdf surface, need to be revealed. The actual implmentation of the pdf driver does not have to be public, and can easily be changed. The pdf-specific calls should just ignore stuff if the surface is not of the type known about. This could be checked by seeing if one of the virtual functions in the surface points at the expected function: void cairo_pdf_start_link(cairo_state* s, ...) { if (s->surface->moveto != my_moveto) return; do_pdf_stuff... } This would avoid having to put "if" statements in the calling code if you want to reuse it for drawing on different devices. -- ,~,~,~,~ ~ ~ ~ ~ /\_ _|_========___ Bill Spitzak ~~~/\/\\~~~~~~\____________/~~~~~~~~ spitzak@d2.com From dforste at arbornet.org Thu Jul 17 12:45:16 2003 From: dforste at arbornet.org (David Forster) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] Color transforms In-Reply-To: <200307171900.h6HJ08DK003531@hermes.d2.com> References: <20030716090542.GA36387@crateria.homeunix.net> <200307170307.h6H37RDK009463@hermes.d2.com> <16150.24098.454090.401385@scream.east.isi.edu> <200307171900.h6HJ08DK003531@hermes.d2.com> Message-ID: <20030717194516.GB50092@crateria.homeunix.net> On Thu, Jul 17, 2003 at 12:05:56PM -0700, Bill Spitzak wrote: > > One idea that should be possible with this approach is graphics > > operations using surfaces from separate devices, (think compositing > > images from two different X servers for example). That could be a lot > > of fun if we can get it to work. > > That would be a really good idea. It seems this would require Cairo > to have a "return this area as an image" call. The "composite from A > to B" call would actually call B's device. It can then detect if A > is something it can talk to directly, and if not it calls the > portable "return this image" call and then uses the result as the > source. Perhaps instead of returning an image, B could be given a surface A' that is compatiable with A and render itself to A' using Cairo. For example: A = Xlib surface (Drawable) A' = Xlib surface (Pixmap) B = SVG buffer (just to take a break from PostScript ;) No need to upload a bulky image to the X server, it'll be rendered efficiently through Xlib and compositing A and A' can happen through RENDER. Now, if B where actually an SVG stream that could not be rewound, there could be trouble... -Dave From xwin641 at vtnet.ca Thu Jul 17 20:10:50 2003 From: xwin641 at vtnet.ca (Trevor Woerner) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] Re: [Xr] Cairo In-Reply-To: <16148.21020.223661.160004@scream.east.isi.edu> References: <16148.21020.223661.160004@scream.east.isi.edu> Message-ID: <200307172310.50726.xwin641@vtnet.ca> On July 15, 2003 03:12 pm, Carl Worth wrote: > None of the code has changed yet, but when it does, I'll also provide > some scripts to simplify the effort to shift existing code from the > old names to the new. I humbly submit the attached python script to perform the above-mentioned conversion. It's not perfect (see what it does with identifiers that have "RGB" in them! :-) but it's a start. I've also included a diff of Xr.h after running the script on it so you can see for yourself. I hope you find it useful. Trevor --- Xr.h 2003-07-17 02:49:52.000000000 -0400 +++ out.h 2003-07-17 23:03:24.000000000 -0400 @@ -28,356 +28,356 @@ #include -typedef struct _XrState XrState; -typedef struct _XrSurface XrSurface; -typedef struct _XrMatrix XrMatrix; +typedef struct _cairo_state cairo_state; +typedef struct _cairo_surface cairo_surface; +typedef struct _cairo_matrix cairo_matrix; _XFUNCPROTOBEGIN /* Functions for manipulating state objects */ -XrState * -XrCreate(void); +cairo_state * +cairo_create(void); void -XrDestroy(XrState *xrs); +cairo_destroy(cairo_state *xrs); void -XrSave(XrState *xrs); +cairo_save(cairo_state *xrs); void -XrRestore(XrState *xrs); +cairo_restore(cairo_state *xrs); /* XXX: I want to rethink this API void -XrPushGroup(XrState *xrs); +cairo_push_group(cairo_state *xrs); void -XrPopGroup(XrState *xrs); +cairo_pop_group(cairo_state *xrs); */ /* Modify state */ void -XrSetTargetSurface (XrState *xrs, XrSurface *surface); +cairo_set_target_surface (cairo_state *xrs, cairo_surface *surface); -typedef enum _XrFormat { - XrFormatARGB32 = PictStandardARGB32, - XrFormatRGB24 = PictStandardRGB24, - XrFormatA8 = PictStandardA8, - XrFormatA1 = PictStandardA1 -} XrFormat; +typedef enum _cairo_format { + cairo_format_a_r_g_b32 = PictStandardARGB32, + cairo_format_r_g_b24 = PictStandardRGB24, + cairo_format_a8 = PictStandardA8, + cairo_format_a1 = PictStandardA1 +} cairo_format; void -XrSetTargetDrawable (XrState *xrs, +cairo_set_target_drawable (cairo_state *xrs, Display *dpy, Drawable drawable); void -XrSetTargetImage (XrState *xrs, +cairo_set_target_image (cairo_state *xrs, char *data, - XrFormat format, + cairo_format format, int width, int height, int stride); -typedef enum _XrOperator { - XrOperatorClear = PictOpClear, - XrOperatorSrc = PictOpSrc, - XrOperatorDst = PictOpDst, - XrOperatorOver = PictOpOver, - XrOperatorOverReverse = PictOpOverReverse, - XrOperatorIn = PictOpIn, - XrOperatorInReverse = PictOpInReverse, - XrOperatorOut = PictOpOut, - XrOperatorOutReverse = PictOpOutReverse, - XrOperatorAtop = PictOpAtop, - XrOperatorAtopReverse = PictOpAtopReverse, - XrOperatorXor = PictOpXor, - XrOperatorAdd = PictOpAdd, - XrOperatorSaturate = PictOpSaturate, - - XrOperatorDisjointClear = PictOpDisjointClear, - XrOperatorDisjointSrc = PictOpDisjointSrc, - XrOperatorDisjointDst = PictOpDisjointDst, - XrOperatorDisjointOver = PictOpDisjointOver, - XrOperatorDisjointOverReverse = PictOpDisjointOverReverse, - XrOperatorDisjointIn = PictOpDisjointIn, - XrOperatorDisjointInReverse = PictOpDisjointInReverse, - XrOperatorDisjointOut = PictOpDisjointOut, - XrOperatorDisjointOutReverse = PictOpDisjointOutReverse, - XrOperatorDisjointAtop = PictOpDisjointAtop, - XrOperatorDisjointAtopReverse = PictOpDisjointAtopReverse, - XrOperatorDisjointXor = PictOpDisjointXor, - - XrOperatorConjointClear = PictOpConjointClear, - XrOperatorConjointSrc = PictOpConjointSrc, - XrOperatorConjointDst = PictOpConjointDst, - XrOperatorConjointOver = PictOpConjointOver, - XrOperatorConjointOverReverse = PictOpConjointOverReverse, - XrOperatorConjointIn = PictOpConjointIn, - XrOperatorConjointInReverse = PictOpConjointInReverse, - XrOperatorConjointOut = PictOpConjointOut, - XrOperatorConjointOutReverse = PictOpConjointOutReverse, - XrOperatorConjointAtop = PictOpConjointAtop, - XrOperatorConjointAtopReverse = PictOpConjointAtopReverse, - XrOperatorConjointXor = PictOpConjointXor -} XrOperator; - -void -XrSetOperator(XrState *xrs, XrOperator op); - -/* XXX: Probably want to bite the bullet and expose an XrColor object */ - -void -XrSetRGBColor(XrState *xrs, double red, double green, double blue); - -void -XrGetRGBColor(XrState *xrs, double *red, double *green, double *blue); - -/* XXX: Do we want XrGetPattern as well? */ +typedef enum _cairo_operator { + cairo_operator_clear = PictOpClear, + cairo_operator_src = PictOpSrc, + cairo_operator_dst = PictOpDst, + cairo_operator_over = PictOpOver, + cairo_operator_over_reverse = PictOpOverReverse, + cairo_operator_in = PictOpIn, + cairo_operator_in_reverse = PictOpInReverse, + cairo_operator_out = PictOpOut, + cairo_operator_out_reverse = PictOpOutReverse, + cairo_operator_atop = PictOpAtop, + cairo_operator_atop_reverse = PictOpAtopReverse, + cairo_operator_xor = PictOpXor, + cairo_operator_add = PictOpAdd, + cairo_operator_saturate = PictOpSaturate, + + cairo_operator_disjoint_clear = PictOpDisjointClear, + cairo_operator_disjoint_src = PictOpDisjointSrc, + cairo_operator_disjoint_dst = PictOpDisjointDst, + cairo_operator_disjoint_over = PictOpDisjointOver, + cairo_operator_disjoint_over_reverse = PictOpDisjointOverReverse, + cairo_operator_disjoint_in = PictOpDisjointIn, + cairo_operator_disjoint_in_reverse = PictOpDisjointInReverse, + cairo_operator_disjoint_out = PictOpDisjointOut, + cairo_operator_disjoint_out_reverse = PictOpDisjointOutReverse, + cairo_operator_disjoint_atop = PictOpDisjointAtop, + cairo_operator_disjoint_atop_reverse = PictOpDisjointAtopReverse, + cairo_operator_disjoint_xor = PictOpDisjointXor, + + cairo_operator_conjoint_clear = PictOpConjointClear, + cairo_operator_conjoint_src = PictOpConjointSrc, + cairo_operator_conjoint_dst = PictOpConjointDst, + cairo_operator_conjoint_over = PictOpConjointOver, + cairo_operator_conjoint_over_reverse = PictOpConjointOverReverse, + cairo_operator_conjoint_in = PictOpConjointIn, + cairo_operator_conjoint_in_reverse = PictOpConjointInReverse, + cairo_operator_conjoint_out = PictOpConjointOut, + cairo_operator_conjoint_out_reverse = PictOpConjointOutReverse, + cairo_operator_conjoint_atop = PictOpConjointAtop, + cairo_operator_conjoint_atop_reverse = PictOpConjointAtopReverse, + cairo_operator_conjoint_xor = PictOpConjointXor +} cairo_operator; + +void +cairo_set_operator(cairo_state *xrs, cairo_operator op); + +/* XXX: Probably want to bite the bullet and expose an cairo_color object */ + +void +cairo_set_r_g_b_color(cairo_state *xrs, double red, double green, double blue); + +void +cairo_get_r_g_b_color(cairo_state *xrs, double *red, double *green, double *blue); + +/* XXX: Do we want cairo_get_pattern as well? */ void -XrSetPattern(XrState *xrs, XrSurface *pattern); +cairo_set_pattern(cairo_state *xrs, cairo_surface *pattern); void -XrSetTolerance(XrState *xrs, double tolerance); +cairo_set_tolerance(cairo_state *xrs, double tolerance); void -XrSetAlpha(XrState *xrs, double alpha); +cairo_set_alpha(cairo_state *xrs, double alpha); double -XrGetAlpha(XrState *xrs); +cairo_get_alpha(cairo_state *xrs); -typedef enum _XrFillRule { XrFillRuleWinding, XrFillRuleEvenOdd } XrFillRule; +typedef enum _cairo_fill_rule { cairo_fill_rule_winding, cairo_fill_rule_even_odd } cairo_fill_rule; void -XrSetFillRule(XrState *xrs, XrFillRule fill_rule); +cairo_set_fill_rule(cairo_state *xrs, cairo_fill_rule fill_rule); void -XrSetLineWidth(XrState *xrs, double width); +cairo_set_line_width(cairo_state *xrs, double width); -typedef enum _XrLineCap { XrLineCapButt, XrLineCapRound, XrLineCapSquare } XrLineCap; +typedef enum _cairo_line_cap { cairo_line_cap_butt, cairo_line_cap_round, cairo_line_cap_square } cairo_line_cap; void -XrSetLineCap(XrState *xrs, XrLineCap line_cap); +cairo_set_line_cap(cairo_state *xrs, cairo_line_cap line_cap); -typedef enum _XrLineJoin { XrLineJoinMiter, XrLineJoinRound, XrLineJoinBevel } XrLineJoin; +typedef enum _cairo_line_join { cairo_line_join_miter, cairo_line_join_round, cairo_line_join_bevel } cairo_line_join; void -XrSetLineJoin(XrState *xrs, XrLineJoin line_join); +cairo_set_line_join(cairo_state *xrs, cairo_line_join line_join); void -XrSetDash(XrState *xrs, double *dashes, int ndash, double offset); +cairo_set_dash(cairo_state *xrs, double *dashes, int ndash, double offset); void -XrSetMiterLimit(XrState *xrs, double limit); +cairo_set_miter_limit(cairo_state *xrs, double limit); void -XrTranslate(XrState *xrs, double tx, double ty); +cairo_translate(cairo_state *xrs, double tx, double ty); void -XrScale(XrState *xrs, double sx, double sy); +cairo_scale(cairo_state *xrs, double sx, double sy); void -XrRotate(XrState *xrs, double angle); +cairo_rotate(cairo_state *xrs, double angle); void -XrConcatMatrix(XrState *xrs, - XrMatrix *matrix); +cairo_concat_matrix(cairo_state *xrs, + cairo_matrix *matrix); void -XrSetMatrix(XrState *xrs, - XrMatrix *matrix); +cairo_set_matrix(cairo_state *xrs, + cairo_matrix *matrix); void -XrDefaultMatrix(XrState *xrs); +cairo_default_matrix(cairo_state *xrs); -/* XXX: There's been a proposal to add XrDefaultMatrixExact */ +/* XXX: There's been a proposal to add cairo_default_matrix_exact */ void -XrIdentityMatrix(XrState *xrs); +cairo_identity_matrix(cairo_state *xrs); void -XrTransformPoint (XrState *xrs, double *x, double *y); +cairo_transform_point (cairo_state *xrs, double *x, double *y); void -XrTransformDistance (XrState *xrs, double *dx, double *dy); +cairo_transform_distance (cairo_state *xrs, double *dx, double *dy); void -XrInverseTransformPoint (XrState *xrs, double *x, double *y); +cairo_inverse_transform_point (cairo_state *xrs, double *x, double *y); void -XrInverseTransformDistance (XrState *xrs, double *dx, double *dy); +cairo_inverse_transform_distance (cairo_state *xrs, double *dx, double *dy); /* Path creation functions */ void -XrNewPath(XrState *xrs); +cairo_new_path(cairo_state *xrs); void -XrMoveTo(XrState *xrs, double x, double y); +cairo_move_to(cairo_state *xrs, double x, double y); void -XrLineTo(XrState *xrs, double x, double y); +cairo_line_to(cairo_state *xrs, double x, double y); void -XrCurveTo(XrState *xrs, +cairo_curve_to(cairo_state *xrs, double x1, double y1, double x2, double y2, double x3, double y3); void -XrRelMoveTo(XrState *xrs, double dx, double dy); +cairo_rel_move_to(cairo_state *xrs, double dx, double dy); void -XrRelLineTo(XrState *xrs, double dx, double dy); +cairo_rel_line_to(cairo_state *xrs, double dx, double dy); void -XrRelCurveTo(XrState *xrs, +cairo_rel_curve_to(cairo_state *xrs, double dx1, double dy1, double dx2, double dy2, double dx3, double dy3); void -XrRectangle (XrState *xrs, +cairo_rectangle (cairo_state *xrs, double x, double y, double width, double height); void -XrClosePath(XrState *xrs); +cairo_close_path(cairo_state *xrs); /* Painting functions */ void -XrStroke(XrState *xrs); +cairo_stroke(cairo_state *xrs); void -XrFill(XrState *xrs); +cairo_fill(cairo_state *xrs); /* Clipping */ void -XrClip(XrState *xrs); +cairo_clip(cairo_state *xrs); /* Font/Text functions */ -/* XXX: The font support should probably expose an XrFont object with - several functions, (XrFontTransform, etc.) in a parallel manner as - XrMatrix and (eventually) XrColor */ +/* XXX: The font support should probably expose an cairo_font object with + several functions, (cairo_font_transform, etc.) in a parallel manner as + cairo_matrix and (eventually) cairo_color */ void -XrSelectFont(XrState *xrs, const char *key); +cairo_select_font(cairo_state *xrs, const char *key); void -XrScaleFont(XrState *xrs, double scale); +cairo_scale_font(cairo_state *xrs, double scale); -/* XXX: Probably want to use an XrMatrix here, (to fix as part of the +/* XXX: Probably want to use an cairo_matrix here, (to fix as part of the big text support rewrite) */ void -XrTransformFont(XrState *xrs, +cairo_transform_font(cairo_state *xrs, double a, double b, double c, double d); void -XrTextExtents(XrState *xrs, +cairo_text_extents(cairo_state *xrs, const unsigned char *utf8, double *x, double *y, double *width, double *height, double *dx, double *dy); void -XrShowText(XrState *xrs, const unsigned char *utf8); +cairo_show_text(cairo_state *xrs, const unsigned char *utf8); /* Image functions */ void -XrShowSurface (XrState *xrs, - XrSurface *surface, +cairo_show_surface (cairo_state *xrs, + cairo_surface *surface, int width, int height); /* Query functions */ -XrOperator -XrGetOperator(XrState *xrs); +cairo_operator +cairo_get_operator(cairo_state *xrs); double -XrGetTolerance(XrState *xrs); +cairo_get_tolerance(cairo_state *xrs); void -XrGetCurrentPoint(XrState *, double *x, double *y); +cairo_get_current_point(cairo_state *, double *x, double *y); -XrFillRule -XrGetFillRule(XrState *xrs); +cairo_fill_rule +cairo_get_fill_rule(cairo_state *xrs); double -XrGetLineWidth(XrState *xrs); +cairo_get_line_width(cairo_state *xrs); -XrLineCap -XrGetLineCap(XrState *xrs); +cairo_line_cap +cairo_get_line_cap(cairo_state *xrs); -XrLineJoin -XrGetLineJoin(XrState *xrs); +cairo_line_join +cairo_get_line_join(cairo_state *xrs); double -XrGetMiterLimit(XrState *xrs); +cairo_get_miter_limit(cairo_state *xrs); -/* XXX: How to do XrGetDash??? Do we want to switch to an XrDash object? */ +/* XXX: How to do cairo_get_dash??? Do we want to switch to an cairo_dash object? */ void -XrGetMatrix(XrState *xrs, +cairo_get_matrix(cairo_state *xrs, double *a, double *b, double *c, double *d, double *tx, double *ty); -XrSurface * -XrGetTargetSurface (XrState *xrs); +cairo_surface * +cairo_get_target_surface (cairo_state *xrs); /* Error status queries */ -typedef enum _XrStatus { - XrStatusSuccess = 0, - XrStatusNoMemory, - XrStatusInvalidRestore, - XrStatusInvalidPopGroup, - XrStatusNoCurrentPoint, - XrStatusInvalidMatrix -} XrStatus; +typedef enum _cairo_status { + cairo_status_success = 0, + cairo_status_no_memory, + cairo_status_invalid_restore, + cairo_status_invalid_pop_group, + cairo_status_no_current_point, + cairo_status_invalid_matrix +} cairo_status; -XrStatus -XrGetStatus(XrState *xrs); +cairo_status +cairo_get_status(cairo_state *xrs); const char * -XrGetStatusString(XrState *xrs); +cairo_get_status_string(cairo_state *xrs); /* Surface mainpulation */ /* XXX: This is a mess from the user's POV. Should the Visual or the - XrFormat control what render format is used? Maybe I can have - XrSurfaceCreateForWindow with a visual, and - XrSurfaceCreateForPixmap with an XrFormat. Would that work? + cairo_format control what render format is used? Maybe I can have + cairo_surface_create_for_window with a visual, and + cairo_surface_create_for_pixmap with an cairo_format. Would that work? */ -XrSurface * -XrSurfaceCreateForDrawable (Display *dpy, +cairo_surface * +cairo_surface_create_for_drawable (Display *dpy, Drawable drawable, Visual *visual, - XrFormat format, + cairo_format format, Colormap colormap); -XrSurface * -XrSurfaceCreateForImage (char *data, - XrFormat format, +cairo_surface * +cairo_surface_create_for_image (char *data, + cairo_format format, int width, int height, int stride); -XrSurface * -XrSurfaceCreateNextTo (XrSurface *neighbor, - XrFormat format, +cairo_surface * +cairo_surface_create_next_to (cairo_surface *neighbor, + cairo_format format, int width, int height); /* XXX: One problem with having RGB and A here in one function is that it introduces the question of pre-multiplied vs. non-pre-multiplied - alpha. Do I want to export an XrColor structure instead? So far, no + alpha. Do I want to export an cairo_color structure instead? So far, no other public functions need it. */ -XrSurface * -XrSurfaceCreateNextToSolid (XrSurface *neighbor, - XrFormat format, +cairo_surface * +cairo_surface_create_next_to_solid (cairo_surface *neighbor, + cairo_format format, int width, int height, double red, @@ -386,89 +386,89 @@ double alpha); void -XrSurfaceDestroy(XrSurface *surface); +cairo_surface_destroy(cairo_surface *surface); /* XXX: Should this take an X/Y offset as well? (Probably) */ -XrStatus -XrSurfacePutImage (XrSurface *surface, +cairo_status +cairo_surface_put_image (cairo_surface *surface, char *data, int width, int height, int stride); /* XXX: The Xc version of this function isn't quite working yet -XrStatus -XrSurfaceSetClipRegion (XrSurface *surface, Region region); +cairo_status +cairo_surface_set_clip_region (cairo_surface *surface, Region region); */ /* XXX: Note: The current Render/Ic implementations don't do the right thing with repeat when the surface has a non-identity matrix. */ -XrStatus -XrSurfaceSetRepeat (XrSurface *surface, int repeat); +cairo_status +cairo_surface_set_repeat (cairo_surface *surface, int repeat); -XrStatus -XrSurfaceSetMatrix(XrSurface *surface, XrMatrix *matrix); +cairo_status +cairo_surface_set_matrix(cairo_surface *surface, cairo_matrix *matrix); -XrStatus -XrSurfaceGetMatrix (XrSurface *surface, XrMatrix *matrix); +cairo_status +cairo_surface_get_matrix (cairo_surface *surface, cairo_matrix *matrix); typedef enum { - XrFilterFast = XcFilterFast, - XrFilterGood = XcFilterGood, - XrFilterBest = XcFilterBest, - XrFilterNearest = XcFilterNearest, - XrFilterBilinear = XcFilterBilinear -} XrFilter; + cairo_filter_fast = XcFilterFast, + cairo_filter_good = XcFilterGood, + cairo_filter_best = XcFilterBest, + cairo_filter_nearest = XcFilterNearest, + cairo_filter_bilinear = XcFilterBilinear +} cairo_filter; -XrStatus -XrSurfaceSetFilter(XrSurface *surface, XrFilter filter); +cairo_status +cairo_surface_set_filter(cairo_surface *surface, cairo_filter filter); /* Matrix functions */ -XrMatrix * -XrMatrixCreate (void); +cairo_matrix * +cairo_matrix_create (void); void -XrMatrixDestroy (XrMatrix *matrix); +cairo_matrix_destroy (cairo_matrix *matrix); -XrStatus -XrMatrixCopy(XrMatrix *matrix, const XrMatrix *other); +cairo_status +cairo_matrix_copy(cairo_matrix *matrix, const cairo_matrix *other); -XrStatus -XrMatrixSetIdentity (XrMatrix *matrix); +cairo_status +cairo_matrix_set_identity (cairo_matrix *matrix); -XrStatus -XrMatrixSetAffine (XrMatrix *xrs, +cairo_status +cairo_matrix_set_affine (cairo_matrix *xrs, double a, double b, double c, double d, double tx, double ty); -XrStatus -XrMatrixGetAffine (XrMatrix *matrix, +cairo_status +cairo_matrix_get_affine (cairo_matrix *matrix, double *a, double *b, double *c, double *d, double *tx, double *ty); -XrStatus -XrMatrixTranslate (XrMatrix *matrix, double tx, double ty); +cairo_status +cairo_matrix_translate (cairo_matrix *matrix, double tx, double ty); -XrStatus -XrMatrixScale (XrMatrix *matrix, double sx, double sy); +cairo_status +cairo_matrix_scale (cairo_matrix *matrix, double sx, double sy); -XrStatus -XrMatrixRotate (XrMatrix *matrix, double radians); +cairo_status +cairo_matrix_rotate (cairo_matrix *matrix, double radians); -XrStatus -XrMatrixInvert(XrMatrix *matrix); +cairo_status +cairo_matrix_invert(cairo_matrix *matrix); -XrStatus -XrMatrixMultiply (XrMatrix *result, const XrMatrix *a, const XrMatrix *b); +cairo_status +cairo_matrix_multiply (cairo_matrix *result, const cairo_matrix *a, const cairo_matrix *b); -XrStatus -XrMatrixTransformDistance (XrMatrix *xr, double *dx, double *dy); +cairo_status +cairo_matrix_transform_distance (cairo_matrix *xr, double *dx, double *dy); -XrStatus -XrMatrixTransformPoint (XrMatrix *xr, double *x, double *y); +cairo_status +cairo_matrix_transform_point (cairo_matrix *xr, double *x, double *y); _XFUNCPROTOEND -------------- next part -------------- A non-text attachment was scrubbed... Name: xr_conv.py Type: text/x-python Size: 4007 bytes Desc: not available Url : http://lists.freedesktop.org/archives/cairo/attachments/20030717/b7ec5634/xr_conv.py From xwin641 at vtnet.ca Thu Jul 17 20:19:31 2003 From: xwin641 at vtnet.ca (Trevor Woerner) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] Re: [Xr] Cairo In-Reply-To: <200307172310.50726.xwin641@vtnet.ca> References: <16148.21020.223661.160004@scream.east.isi.edu> <200307172310.50726.xwin641@vtnet.ca> Message-ID: <200307172319.31778.xwin641@vtnet.ca> On July 17, 2003 11:10 pm, Trevor Woerner wrote: > On July 15, 2003 03:12 pm, Carl Worth wrote: > > None of the code has changed yet, but when it does, I'll also > > provide some scripts to simplify the effort to shift existing code > > from the old names to the new. > > I humbly submit the attached python script to perform the > above-mentioned conversion. Just for the record... I prefer the older naming convention since it mirrors the X libraries better. But I guess the goal of cairo is to become more than just an X library. Trevor From Thorsten.Behrens at Sun.COM Fri Jul 18 02:15:15 2003 From: Thorsten.Behrens at Sun.COM (Thorsten.Behrens@Sun.COM) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] Color transforms In-Reply-To: <16150.43021.652375.273170@scream.east.isi.edu> Message-ID: On Jul 17, Carl wrote: > I might take a contrary view that "printing" shouldn't be any harder > than any other kind of graphics creation. For example, I'd like to be > able to take a chunk of code that generates a PNG and just flip a > switch at one point in the code and generate a PDF instead. > I don't see the point here. By definition, your PNG rendering code does not care about printing, and does not have to. So in neither scenario will it contain anything specific to printing. The 'new_page' and 'use_this_printer' calls are typically at other, isolated code places, which, again by definition, have to know about printing. > show_page is certainly one one truly unique capability. Are there many > others that people can think of? > As others said, PDF has loads of specialities. I don't think it's wise to provide all that in cairo. Maybe an opaque pipe-through could cater for all the people who want to play tricks with hyperlinks, scripts, and the like. I'm currently asking myself whether font embedding is necessary at the interface, but probably one can also handle that transparently within the device-specific driver. -- Thorsten Word Perfect isn't, Excel doesn't, Works won't. From xwin641 at vtnet.ca Fri Jul 18 04:53:47 2003 From: xwin641 at vtnet.ca (Trevor Woerner) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] Xc too? In-Reply-To: <200307172319.31778.xwin641@vtnet.ca> References: <16148.21020.223661.160004@scream.east.isi.edu> <200307172310.50726.xwin641@vtnet.ca> <200307172319.31778.xwin641@vtnet.ca> Message-ID: <200307180753.47948.xwin641@vtnet.ca> Do we want to handle Xc... words the same way as the Xr words? If so the attached newer script will help (I hope). Trevor -------------- next part -------------- A non-text attachment was scrubbed... Name: xr_conv.py Type: text/x-python Size: 5550 bytes Desc: not available Url : http://lists.freedesktop.org/archives/cairo/attachments/20030718/93fd7e07/xr_conv.py From dforste at arbornet.org Fri Jul 18 12:05:49 2003 From: dforste at arbornet.org (David Forster) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] Software rendering In-Reply-To: <16150.43021.652375.273170@scream.east.isi.edu> References: <1058452323.9827.23.camel@poincare.devel.redhat.com> <16150.43021.652375.273170@scream.east.isi.edu> Message-ID: <20030718190549.GA58679@crateria.homeunix.net> On Thu, Jul 17, 2003 at 09:43:41AM -0400, Carl Worth wrote: > show_page is certainly one one truly unique capability. Are there many > others that people can think of? I'm curious that if you don't have a showpage operator, then how are you going to support client side rendering? That is, Cairo has no idea when to upload all it's changes so it's going to have to do it for each operation. That seems overly expensive. With a showpage, Cairo could upload everything in one batch. Not to mention double-buffering is useful enough for normal RENDER rendering, OpenGL, GIF, MNG[*], PDF, and PS. If double-buffering isn't enabled, or it makes no sense for a particular backend, it's harmless enough to make showpage and newpage no-ops. IMHO, -Dave [*] I don't know much about MNG. I assume it can do a `pixmap flip-book' like GIF, at the very least. From cworth at east.isi.edu Fri Jul 18 12:08:25 2003 From: cworth at east.isi.edu (Carl Worth) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] Re: [Xr] Cairo In-Reply-To: <200307172310.50726.xwin641@vtnet.ca> References: <16148.21020.223661.160004@scream.east.isi.edu> <200307172310.50726.xwin641@vtnet.ca> Message-ID: <16152.17833.296605.812393@scream.east.isi.edu> On Jul 17, Trevor Woerner wrote: > I humbly submit the attached python script to perform the > above-mentioned conversion. It's not perfect (see what it does with > identifiers that have "RGB" in them! :-) but it's a start. Thanks for your effort Trevor. I had already started with some sed code and it seems to be able to handle every program I've been able to send at it so far. -Carl From cworth at east.isi.edu Fri Jul 18 12:09:40 2003 From: cworth at east.isi.edu (Carl Worth) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] Re: [Xr] Cairo In-Reply-To: <200307172319.31778.xwin641@vtnet.ca> References: <16148.21020.223661.160004@scream.east.isi.edu> <200307172310.50726.xwin641@vtnet.ca> <200307172319.31778.xwin641@vtnet.ca> Message-ID: <16152.17908.734221.649024@scream.east.isi.edu> On Jul 17, Trevor Woerner wrote: > Just for the record... I prefer the older naming convention since it > mirrors the X libraries better. But I guess the goal of cairo is to > become more than just an X library. The original names were chosen exactly for the reason of matching the X libraries. I'm happy now that I can use my preferred style. :) -Carl From cworth at east.isi.edu Fri Jul 18 12:11:26 2003 From: cworth at east.isi.edu (Carl Worth) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] Xc too? In-Reply-To: <200307180753.47948.xwin641@vtnet.ca> References: <16148.21020.223661.160004@scream.east.isi.edu> <200307172310.50726.xwin641@vtnet.ca> <200307172319.31778.xwin641@vtnet.ca> <200307180753.47948.xwin641@vtnet.ca> Message-ID: <16152.18014.784647.106468@scream.east.isi.edu> On Jul 18, Trevor Woerner wrote: > Do we want to handle Xc... words the same way as the Xr words? No, there's no real reason to. We've decided not to try to maintain a separate external interface for the layer that Xc is handling. So the functionality of Xc will soon be folding into Xr. When that happens, the names can change, (but they will only be internal anyway --- so only one person will have to worry about it). -Carl From cworth at east.isi.edu Fri Jul 18 12:13:40 2003 From: cworth at east.isi.edu (Carl Worth) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] Software rendering In-Reply-To: <20030718190549.GA58679@crateria.homeunix.net> References: <1058452323.9827.23.camel@poincare.devel.redhat.com> <16150.43021.652375.273170@scream.east.isi.edu> <20030718190549.GA58679@crateria.homeunix.net> Message-ID: <16152.18148.617147.543161@scream.east.isi.edu> On Jul 18, David Forster wrote: > I'm curious that if you don't have a showpage operator, then how are > you going to support client side rendering? Cairo does indeed need a show_page operator. > Not to mention double-buffering is useful enough for normal RENDER > rendering, OpenGL, GIF, MNG[*], PDF, and PS. Yes, this might be a semantic attached to show_page at some point. -Carl From cworth at east.isi.edu Fri Jul 18 12:53:15 2003 From: cworth at east.isi.edu (Carl Worth) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] The great renaming Message-ID: <16152.20523.138027.866496@scream.east.isi.edu> There seems to be no complaint about the name Cairo. I've just committed the first version of the source code to use the new Cairo names. You may now checkout the "cairo" module from CVS, (I've also tried to make sure that old checkouts will still work and point to the new code, but do tell me if I missed something). Here is the breakdown of changes: Function names go from XrStudlyStyle to cairo_underscore_style: XrSetLineJoin -> cairo_set_line_join Symbolic values, (ie. enum values), go from StUdlY to ALL_CAPS: XrLineJoinRound -> CAIRO_LINE_JOIN_ROUND The convention for distinguising an enum/structure tag from a typedef name changes from an '_' prefix on the tag to a "_t" suffix on the typedef name: typedef enum _XrLineJoin { ... } XrLineJoin; -> typedef enum cairo_line_join { ... } cairo_line_join_t; And just for good measure, I took advantage of the chance to change a couple of the names as well: XrState -> cairo_t XrCreateSurfaceNextTo -> cairo_create_surface_similar The cairo/util directory contains a shell script, xr2cairo, which makes it easy to convert any code using Xr to use the new Cairo naming conventions. I've attached a copy of the script as well. The xr2cairo script handles all of the changes mentioned above. I've run the script on Xr itself, as well as most of the code I've written that uses Xr, (libxsvg, xsvg, xrtest, grrobot). But, just in case the script really screws up, it first saves a backup with a .xr extension. A very few tasks are left as exercises for the reader. Obviously one will need to fix the build to link against libcairo rather than libXr. Also, on a cosmetic note, it may be desired to change the name of the "xrs", (or whatever), identifier and fix whitespace issues caused by the fact that the new names are almost all longer than the old ones. Oh, and the script does require GNU sed, so go and get that if you don't already have it, (but you really should have it already). -Carl -------------- next part -------------- #!/bin/sh set -e if [ $# -lt 1 ]; then argv0=`basename $0` echo "$argv0: Convert source code written for Xr to use Cairo instead." >&2 echo "" >&2 echo "Usage: $argv0 file [...]" >&2 exit 1 fi xr2cairo() { file=$1 backup=$file.xr if [ -e $backup ]; then echo "Warning: Backup file $backup already exists --- not backing up this time." >&2 else cp $file $backup fi sed -e ' s/\(Xr[a-zA-Z]*\)RGB/\1Rgb/g s/\(Xr[a-zA-Z]*\)NextTo/\1Similar/g s/Xr\([A-Z]\+[a-z]\+\)\([A-Z]\+[a-z]\+\)\([A-Z]\+[a-z]\+\)\([A-Z]\+[a-z]\+\)\([A-Z]\+[a-z]\+\)/\Lcairo_\1_\2_\3_\4_\5\E/g s/Xr\([A-Z]\+[a-z]\+\)\([A-Z]\+[a-z]\+\)\([A-Z]\+[a-z]\+\)\([A-Z]\+[a-z]\+\)/\Lcairo_\1_\2_\3_\4\E/g s/Xr\([A-Z]\+[a-z]\+\)\([A-Z]\+[a-z]\+\)\([A-Z]\+[a-z]\+\)/\Lcairo_\1_\2_\3\E/g s/Xr\([A-Z]\+[a-z]\+\)\([A-Z]\+[a-z0-9]\+\)/\Lcairo_\1_\2\E/g s/Xr\([A-Z]\+[a-z]\+\)/\Lcairo_\1\E/g s/\(cairo_\(operator\|status\|fill_rule\|line_cap\|line_join\|filter\|format\)_[a-z0-9_]\{2,\}\)/\U\1/g s/cairo_\(fill_rule\|line_cap\|line_join\|format\|operator\|status\|filter\|surface\|matrix\)$/cairo_\1_t/g s/cairo_\(fill_rule\|line_cap\|line_join\|format\|operator\|status\|filter\|surface\|matrix\)\([^_]\)/cairo_\1_t\2/g s/_cairo_\(fill_rule\|line_cap\|line_join\|format\|operator\|status\|filter\|surface\|matrix\)_t/cairo_\1/g s/cairo_state/cairo_t/g s/_cairo_t/cairo/g s/Xr\.h/cairo.h/g ' $backup > $file } while [ $# -gt 0 ]; do file=$1 shift xr2cairo $file done From cworth at east.isi.edu Fri Jul 18 13:08:58 2003 From: cworth at east.isi.edu (Carl Worth) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] Color transforms In-Reply-To: References: <16150.43021.652375.273170@scream.east.isi.edu> Message-ID: <16152.21466.110387.273805@scream.east.isi.edu> On Jul 18, Thorsten.Behrens@Sun.COM wrote: > I don't see the point here. By definition, your PNG rendering code does > not care about printing, and does not have to. So in neither scenario will > it contain anything specific to printing. No, of course not. The point I was trying to make is that, as much as possible, I'd like the interface for generating PostScript/PDF/SVG to be as simple as any other image type, (X11, PNG, etc.). Ideally, it's just a different type of image. > As others said, PDF has loads of specialities. I don't think it's wise to > provide all that in cairo. I have no plans to support any of that stuff in Cairo. > I'm currently asking myself whether font embedding is necessary at the > interface, but probably one can also handle that transparently within the > device-specific driver. The font/text API is the most open question in Cairo right now. Keith and I will be together at OLS next week. I'm hoping we can have a reasonable first attempt put together before the end of the week. -Carl From otaylor at redhat.com Fri Jul 18 15:33:34 2003 From: otaylor at redhat.com (Owen Taylor) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] Color transforms In-Reply-To: <16152.21466.110387.273805@scream.east.isi.edu> References: <16150.43021.652375.273170@scream.east.isi.edu> <16152.21466.110387.273805@scream.east.isi.edu> Message-ID: <1058567613.27940.513.camel@poincare.devel.redhat.com> On Fri, 2003-07-18 at 16:08, Carl Worth wrote: > The font/text API is the most open question in Cairo right now. Keith > and I will be together at OLS next week. I'm hoping we can have a > reasonable first attempt put together before the end of the week. Just remember that any Cairo text API's for applications will be more or less "toy"; for heavy-duty usage, you need a Pango equivalent. So, there is no point in getting too fancy with the part that isn't "draw these glyphs at these positions". Regards, Owen From cworth at east.isi.edu Fri Jul 18 15:47:20 2003 From: cworth at east.isi.edu (Carl Worth) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] Color transforms In-Reply-To: <1058567613.27940.513.camel@poincare.devel.redhat.com> References: <16150.43021.652375.273170@scream.east.isi.edu> <16152.21466.110387.273805@scream.east.isi.edu> <1058567613.27940.513.camel@poincare.devel.redhat.com> Message-ID: <16152.30968.597393.9160@scream.east.isi.edu> On Jul 18, Owen Taylor wrote: > Just remember that any Cairo text API's for applications will be > more or less "toy"; for heavy-duty usage, you need a Pango equivalent. > So, there is no point in getting too fancy with the part that > isn't "draw these glyphs at these positions". Precisely. And we do not want anything resembling a Pango equivalent sneaking into Cairo. So, not too worry, the API will not go beyond glyph placement, (with transformation of course). Cairo will also build on top of significant libraries such as freetype and fontconfig. So there's not a whole lot left for Cairo to have to do, (running a few coordinates through a matrix is trivial enough). But as a middleman, Cairo must be careful not to get in the way. A higher-level "Pango equivalent" needs access to the metrics, etc. from the lower-level libraries. Providing that access in a clean and portable way may be the trickiest part of the interface to get right. -Carl From otaylor at redhat.com Fri Jul 18 15:56:13 2003 From: otaylor at redhat.com (Owen Taylor) Date: Mon Aug 15 11:10:44 2005 Subject: Text [was Re: [Cairo] Color transforms] In-Reply-To: <16152.29424.38039.740075@scream.east.isi.edu> References: <16150.43021.652375.273170@scream.east.isi.edu> <16152.21466.110387.273805@scream.east.isi.edu> <1058566330.27940.507.camel@poincare.devel.redhat.com> <16152.29424.38039.740075@scream.east.isi.edu> Message-ID: <1058568972.27940.535.camel@poincare.devel.redhat.com> On Fri, 2003-07-18 at 18:21, Carl Worth wrote: > On Jul 18, Owen Taylor wrote: > > Just remember that any Cairo text API's for applications will be > > more or less "toy"; for heavy-duty usage, you need a Pango equivalent. > > So, there is no point in getting too fancy with the part that > > isn't "draw these glyphs at these positions". > > Precisely. And we do not want anything resembling a Pango equivalent > sneaking into Cairo. So, not too worry, the API will not go beyond > glyph placement, (with transformation of course). Presumably you do also want the "toy": cairo_draw_string (CairoState crs, const char *utf8_string); as well, so people can have text in their demos. > Cairo will also build on top of significant libraries such as freetype > and fontconfig. > > So there's not a whole lot left for Cairo to have to do, (running a > few coordinates through a matrix is trivial enough). But as a > middleman, Cairo must be careful not to get in the way. A higher-level > "Pango equivalent" needs access to the metrics, etc. from the > lower-level libraries. Providing that access in a clean and portable > way may be the trickiest part of the interface to get right. Off the top of my head, I think what Pango needs from Cairo is something along the lines of: - Load the CairoFont for this fontconfig pattern - Give me the FT_FACE for this CairoFont set up for the current display metrics - Draw these glyphs from this CairoFont at these locations You might be able to avoid having a "CairoFont" object by just having "make this fontconfig pattern current", but I'd worry that the inefficiency from repeated pattern lookups could be considerable. The current Xft API generally works fine for Pango; the complete list of Xft functions that Pango uses is: XftCharExists XftCharIndex XftCharSpecRender XftDefaultSubstitute XftDrawCharSpec XftDrawGlyphSpec XftDrawRect XftFontClose XftFontOpen XftFontOpenPattern XftGlyphExtents XftGlyphSpecRender XftLockFace XftTextExtents8 XftUnlockFace The XftGlyphExtents usage is basically just for convenience since Pango also pulls metrics from the font directly for kerning / GPOS/GSUB / etc. XftTextExtents8, XftDrawCharSpec, XftDrawRect is just for drawing hex squares. Beyond what Pango is doing currenntly, I'd actually like to be able to access both: - The FT_FACE/metrics hinted for the current scale factor - The FT_FACE/metrics with no hinting scaled for the current scale factor Since I believe that the correct way of handling device-independent / device-dependent metrics differences is along the lines of "lay out words for device-independent metrics, adjust spacing within words for the But I'm not really sure how that plays out in the API. Regards, Owen From keithp at keithp.com Fri Jul 18 16:47:13 2003 From: keithp at keithp.com (Keith Packard) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] Color transforms In-Reply-To: Your message of "18 Jul 2003 18:33:34 EDT." <1058567613.27940.513.camel@poincare.devel.redhat.com> Message-ID: Around 18 o'clock on Jul 18, Owen Taylor wrote: > So, there is no point in getting too fancy with the part that > isn't "draw these glyphs at these positions". That's the plan -- some lame UTF-8 based API for applications that aren't wise enough to find a real text layout system, and then support for setting specific glyphs at specific locations. The UTF-8 API will probably do font merging right down inside cairo so that applications will always get that. I'm wondering how I can use this same code to accelerate this operation in Pango -- my plan is to use a single level hash to map unicode -> glyph/font so that I don't have to walk the sorted list of fonts for glyphs I've already found. -keith From xwin641 at vtnet.ca Sat Jul 19 03:43:22 2003 From: xwin641 at vtnet.ca (Trevor Woerner) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] The great renaming In-Reply-To: <16152.20523.138027.866496@scream.east.isi.edu> References: <16152.20523.138027.866496@scream.east.isi.edu> Message-ID: <200307190643.22332.xwin641@vtnet.ca> On July 18, 2003 03:53 pm, Carl Worth wrote: > I've just committed the first version of the source code to use the > new Cairo names. You may now checkout the "cairo" module from CVS, > (I've also tried to make sure that old checkouts will still work and > point to the new code, but do tell me if I missed something). I just did a 'cvs update -dP' on an existing checkout of Xr and everything worked fine. Good job! Trevor From otaylor at redhat.com Sat Jul 19 06:57:11 2003 From: otaylor at redhat.com (Owen Taylor) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] Color transforms In-Reply-To: References: Message-ID: <1058623030.1916.35.camel@localhost.localdomain> On Fri, 2003-07-18 at 19:47, Keith Packard wrote: > Around 18 o'clock on Jul 18, Owen Taylor wrote: > > > So, there is no point in getting too fancy with the part that > > isn't "draw these glyphs at these positions". > > That's the plan -- some lame UTF-8 based API for applications that aren't > wise enough to find a real text layout system, and then support for > setting specific glyphs at specific locations. > > The UTF-8 API will probably do font merging right down inside cairo so > that applications will always get that. I'm wondering how I can use this > same code to accelerate this operation in Pango -- my plan is to use a > single level hash to map unicode -> glyph/font so that I don't have to > walk the sorted list of fonts for glyphs I've already found. This operation hasn't shown up to be much of a bottleneck for Pango; it's the mapping from pattern => list of fonts that we needed to cache aggressively. I'm pretty sure we'll be going to non-local glyph selection for Pango in the near future to get punctuation/whitespace/etc from the right font, so a character => font cache isn't going to be useful for Pango. Regards, Owen From keithp at keithp.com Sat Jul 19 10:50:20 2003 From: keithp at keithp.com (Keith Packard) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] Color transforms In-Reply-To: Your message of "19 Jul 2003 09:57:11 EDT." <1058623030.1916.35.camel@localhost.localdomain> Message-ID: Around 9 o'clock on Jul 19, Owen Taylor wrote: > This operation hasn't shown up to be much of a bottleneck for Pango; > it's the mapping from pattern => list of fonts that we needed to > cache aggressively. Then I'll certainly cache that -- I can also tell when the configuration has changed and invalidate the cache. > I'm pretty sure we'll be going to non-local glyph selection for Pango > in the near future to get punctuation/whitespace/etc from the right > font, so a character => font cache isn't going to be useful > for Pango. Ok, so I guess we should profile things before I go implementing a lot of unnecessary optimizations... -keith From Thorsten.Behrens at Sun.COM Mon Jul 21 02:53:57 2003 From: Thorsten.Behrens at Sun.COM (Thorsten.Behrens@Sun.COM) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] Text API (was: Color transforms) In-Reply-To: <1058567613.27940.513.camel@poincare.devel.redhat.com> Message-ID: On Fri, Owen wrote: > Just remember that any Cairo text API's for applications will be > more or less "toy"; for heavy-duty usage, you need a Pango equivalent. > So, there is no point in getting too fancy with the part that > isn't "draw these glyphs at these positions". > There's at least one subtlety: for string search working in PDF export, mere glyphs are not sufficient. You need the original string for that. So, if Cairo really wants to provide useful PDF exports (other possible formats, like e.g. SVG, might pose similar problems), a glyph export might not be enough. -- Thorsten Word Perfect isn't, Excel doesn't, Works won't. From tor.andersson at dsek.lth.se Mon Jul 21 05:07:17 2003 From: tor.andersson at dsek.lth.se (Tor) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] Text API (was: Color transforms) In-Reply-To: References: <1058567613.27940.513.camel@poincare.devel.redhat.com> Message-ID: <20030721120717.GA25539@igloo.df.lth.se> On 2003-07-21 CE Thorsten.Behrens@Sun.COM wrote, > On Fri, Owen wrote: > > > Just remember that any Cairo text API's for applications will be > > more or less "toy"; for heavy-duty usage, you need a Pango equivalent. > > So, there is no point in getting too fancy with the part that > > isn't "draw these glyphs at these positions". > > > There's at least one subtlety: for string search working in PDF export, > mere glyphs are not sufficient. You need the original string for that. So, > if Cairo really wants to provide useful PDF exports (other possible > formats, like e.g. SVG, might pose similar problems), a glyph export might > not be enough. That's what the ToUnicode entry in the PDF is for, mapping glyphs to unicode character codes. Too bad it is still insufficient for more advanced scripts that do glyph reordering, like Devanagiri. -- 55.7N 13.2E From otaylor at redhat.com Mon Jul 21 06:29:07 2003 From: otaylor at redhat.com (Owen Taylor) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] Text API (was: Color transforms) In-Reply-To: References: Message-ID: <1058794147.28536.6.camel@poincare.devel.redhat.com> On Mon, 2003-07-21 at 05:53, Thorsten.Behrens@Sun.COM wrote: > On Fri, Owen wrote: > > > Just remember that any Cairo text API's for applications will be > > more or less "toy"; for heavy-duty usage, you need a Pango equivalent. > > So, there is no point in getting too fancy with the part that > > isn't "draw these glyphs at these positions". > > > There's at least one subtlety: for string search working in PDF export, > mere glyphs are not sufficient. You need the original string for that. So, > if Cairo really wants to provide useful PDF exports (other possible > formats, like e.g. SVG, might pose similar problems), a glyph export might > not be enough. There are quite a few features of PDF that a simple drawing API won't handle ... text flow information is an example fairly similar to the one you raise (If you have a series of boxes with text on the page, what's the ordering of them), but also hyperlinks, indices, etc. So, you have to draw the line somewhere. Perhaps a "draw these glyphs here, and here's the original text" API makes sense, though. There's also the question of bidirectional text output. Going back from visual output order to the logical order isn't always possible and is always tricky. I don't have my PDF book with me at the moment, so I can't look up how that is supposed t o work. Regards, Owen From Thorsten.Behrens at Sun.COM Mon Jul 21 08:08:33 2003 From: Thorsten.Behrens at Sun.COM (Thorsten.Behrens@Sun.COM) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] Text API (was: Color transforms) In-Reply-To: <1058794147.28536.6.camel@poincare.devel.redhat.com> Message-ID: Today, Owen wrote: > So, you have to draw the line somewhere. Perhaps a "draw these glyphs > here, and here's the original text" API makes sense, though. > That's an option, although not a very clean one. > There's also the question of bidirectional text output. > Going back from visual output order to the logical order isn't > always possible and is always tricky. > The original character string should be sufficient, according to our local scripting expert. This string is of course in the logical order. BTW: I assume you're all on this list, so I dropped the superfluous cc-ing, okay? -- Thorsten Word Perfect isn't, Excel doesn't, Works won't. From otaylor at redhat.com Mon Jul 21 08:35:17 2003 From: otaylor at redhat.com (Owen Taylor) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] Text API (was: Color transforms) In-Reply-To: References: Message-ID: <1058801717.28536.44.camel@poincare.devel.redhat.com> On Mon, 2003-07-21 at 11:08, Thorsten.Behrens@Sun.COM wrote: > Today, Owen wrote: > > > So, you have to draw the line somewhere. Perhaps a "draw these glyphs > > here, and here's the original text" API makes sense, though. > > > That's an option, although not a very clean one. It's clean, just not at the level you are thinking about. The application deals with the Pango API, and says "draw this paragraph here"; Pango interacts with the "not very clean" API to produce the correct output. The alternative is to stick "Pango" at the PDF backend for Cairo level and that isn't an alternative; the API that you have to thread down though the various levels is huge, the amount of duplicated code is huge. > > There's also the question of bidirectional text output. > > Going back from visual output order to the logical order isn't > > always possible and is always tricky. > > > The original character string should be sufficient, according to our local > scripting expert. This string is of course in the logical order. Several issues here: - Pango draws each bidirectional segment separately, in visual order, which is the sensible way to do it. - If you simply provide "here's a paragraph as glyphs, here's the text that goes with it" as two big chunks, then there isn't sufficient information to do selection of subsections of that paragraph available to a PDF viewer. However, for me to speculate further without re-reading the relevant parts of the PDF book wouldn't be useful. Regards, Owen From spitzak at d2.com Wed Jul 23 18:13:10 2003 From: spitzak at d2.com (Bill Spitzak) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] Text API In-Reply-To: <1058801717.28536.44.camel@poincare.devel.redhat.com> References: <1058801717.28536.44.camel@poincare.devel.redhat.com> Message-ID: <200307240113.h6O1DNDK028995@hermes.d2.com> My opinion is that the "font merging" must be done at a very low level, probably requiring changes to XRender itself, and maybe even the server portion of Xlib. The user and program do *not* want "font sets". Programs want one *short* string to describe the "font". The string "Times" must somehow define *every* glyph. If anything more complex than this short string is needed then programs will be forced to provide a higher-level wrapper in order to be user-friendly, and we will be back to the current situation where no programs agree on how to name fonts. It also seems to me that a sparse array of glyphs is going to be needed somewhere, since only a fraction of the 2^31 possible glyphs are going to be defined at any time. It certainly seems to me that any decisions about the source of glyphs should be done by the same code implementing this sparse matrix. ************* Here is my proposal for the Cairo text interface. My intention is to make it trivial to label GUI buttons, relatively easy to make a "dumb" UTF-8 editor, but also to allow a Pango-like interface use the same calls. By using the same calls it confirms that this is powerful enough to handle other uses, rather than being specialized to exactly two: cairo_set_text_matrix() : This copies the current transformation matrix to the "text" matrix (only the ABCD values are stored in this matrix and it is saved/restored at the same time the main matrix is). The reason for this seperate matrix is so you can use cairo transforms to position labels on objects without transforming the labels themselves (similar to OpenGL) while also allowing the PostScript ability to transform entire drawings. cairo_get_text_matrix() : The current transformation matrix is replaced with a new one such that 0,0 transforms to the current point and ABCD are set equal to the current text matrix. This is so cairo drawing operations can be used to draw glyphs. Use gsave/grestore to get the previous transformation back. cairo_set_font("name", A,B,C,D) : "name" selects a font. There are no errors, if name is not the name of a font an implementation-defined rule is used to pick the font. ABCD is a matrix and it is multiplied by the textmatrix to produce a matrix that transforms all the glyphs (a square that is the "point size" tall and wide is one unit). If B is non-zero (indicating rotation) then you probably will not get nice output unless you position each glyph with a seperate call. All possible 2^31 glyphs are set to predictable values by this call, no matter what font calls were done before. The likely implementation is that the name itself will define a few hundred glyphs, perhaps 1000 or so are pulled from hardcoded other names, and about 30,000 others will be set to roughly-scaled 16x16 bitmaps of all Unicode glyphs, and all the rest will draw en*1 or 1*1 rectangles. Fonts defining symbols (like "Symbol") will set the first 256 glyphs for compatability with existing software (note this is different that Xft). No glyphs other than a tiny set defined by Unicode standards are allowed to be blank, and none can be zero or negative width. cairo_draw_ucs32(dx,dy, unsigned* a, int n) : dx,dy is transformed by the text matrix and the current point (last moveto/lineto) is moved this distance in device space. Then the first glyph identified by a[0] is drawn with it's origin at this point. Then a value (x,0) (NOTE y == 0!!) called the "escapement" is determined from that glyph, transformed by the text matrix, and used to move the current point again in device space. (notice that kerning, bidir printing, overprinting, etc are NOT done!!!). float cairo_measure_usc32(unsigned* a, int n) : the escapement of all the glyphs is added together and the x is returned. Since the y is zero it is not returned. cairo_draw_utf8(dx,dy, unsigned char* a, int n) : The bytes a[0] through a[n-1] are interpreted as UTF-8 and the resulting glyphs are drawn the same as cairo_draw_ucs32. a[-1] and a[n] should not be looked at and should be assummed to be 0 for UTF-8 parsing rules. *THERE ARE NO ERRORS*, any sequence of bytes that is not legal UTF-8 (including a code using more bytes than necessary!!!) will instead be converted so each byte renders one glyph of that value (ie in the 128-255 range). This method allows about 99.9% of ISO-8859-1 strings to be printed correctly by this interface, which we must do to encourage programs to use it. (There is no "ascii" interface. This is on purpose to encourage use of UTF-8. If you really need it you must copy each byte to an unsigned array and use cairo_draw_ucs32). float cairo_measure_uft8(unsigned char* a, int n) : the escapement of all the glyphs is added together and the x is returned. Since the y is zero it is not returned. float cairo_ascent(), cairo_descent() : return the font-defined location of the baseline. Placing the current point at y-(ascent-descent)/2 will visibly center the text about the position y. cairo_list_fonts(...) : Some kind of interface to enumerate all the strings that can be passed to cairo_set_font. cairo_glyph_attibutes(...) : Find out information about the glyphs as necessary for Pango. Not sure what is needed here. ***************** The PC (politically correct) crowd is going to lynch me because it is obvious that my interface is biased towards European text. However, we have to face reality: if the programming interface is not simple enough to be understood while at the same time useful for a large number of programmers, it is not going to get used! PC has done more to prevent I18N than any redneck programmers ever did. To defend against these PC attacks you can point out that kerning is also not supported and that the interface is useless for drawing English vertically (letters horizontal but above each other) thus people are encouraged to use Pango. There are obvious ways to "improve" this interface to support kerning and vertical text, but I feel it is best to compromise the design so that a defense against PC can be made. Also such changes make Pango harder to implement and thus can backfire. -- ,~,~,~,~ ~ ~ ~ ~ /\_ _|_========___ Bill Spitzak ~~~/\/\\~~~~~~\____________/~~~~~~~~ spitzak@d2.com From skuloor at verano.com Fri Jul 25 11:33:47 2003 From: skuloor at verano.com (Soorya Kuloor) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] Stroking problem Message-ID: <1059158027.28176.10.camel@dolphin.calgary.verano.com> Hi Carl, I just upgraded to Cairo from Xr, so that I can implement cairo_surface_set_clip_region() function. However, in the process I have found a bug. I am attaching a test program that reproduces the bug. The test tries to draw a rectangle and then rotates it by approx. 90 degrees (note: not exactly 90 degrees, but pretty close). On my machine it takes 5.8 secs to stroke this one rectangle. If I change the transformation to exact 90 degrees the rectangle draws in less than a millisecond as expected. I did a runtime profile and found that function _line_segs_intersect_ceil() in file cairo_traps.c goes into an almost infinite loop at the while loop at line 416. Unfortunately, I do not understand the math in there. The problem does not happen if I fill the rectangle, instead of stroking it. Can you please help? Thanks, -- Soorya -------------- next part -------------- A non-text attachment was scrubbed... Name: cairorect.c Type: text/x-c Size: 6097 bytes Desc: not available Url : http://lists.freedesktop.org/archives/cairo/attachments/20030725/9776d427/cairorect.bin From keithp at keithp.com Fri Jul 25 12:05:53 2003 From: keithp at keithp.com (Keith Packard) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] Stroking problem In-Reply-To: Your message of "25 Jul 2003 12:33:47 MDT." <1059158027.28176.10.camel@dolphin.calgary.verano.com> Message-ID: Around 12 o'clock on Jul 25, Soorya Kuloor wrote: > I did a runtime profile and found that function > _line_segs_intersect_ceil() in file cairo_traps.c goes into an almost > infinite loop at the while loop at line 416. Cool -- it didn't infinite loop. We just rewrote that code to make sure it was correct and are doing a linear search at sub-pixel resolution. Changing that to a faster search should solve the performance problem. Thanks for constructing a test case for this... -keith From cworth at east.isi.edu Fri Jul 25 12:32:05 2003 From: cworth at east.isi.edu (Carl Worth) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] Stroking problem In-Reply-To: References: <1059158027.28176.10.camel@dolphin.calgary.verano.com> Message-ID: <16161.34229.551589.272770@scream.east.isi.edu> On Jul 25, Keith Packard wrote: > Around 12 o'clock on Jul 25, Soorya Kuloor wrote: > > > I did a runtime profile and found that function > > _line_segs_intersect_ceil() in file cairo_traps.c goes into an almost > > infinite loop at the while loop at line 416. > > Cool -- it didn't infinite loop. We just rewrote that code to make sure > it was correct and are doing a linear search at sub-pixel resolution. > Changing that to a faster search should solve the performance > problem. Keith just did the error analysis and determined that the "search" is actually just a conditional increment. The fix is committed now. -Carl From skuloor at verano.com Fri Jul 25 14:09:46 2003 From: skuloor at verano.com (Soorya Kuloor) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] Stroking problem In-Reply-To: <16161.34229.551589.272770@scream.east.isi.edu> References: <1059158027.28176.10.camel@dolphin.calgary.verano.com> <16161.34229.551589.272770@scream.east.isi.edu> Message-ID: <1059167386.28176.28.camel@dolphin.calgary.verano.com> Carl, Keith, The problem is fixed. Thanks for the fix. I'll try to implement the clip region function over the next couple of days and send you a patch. Is it OK if just test the Render part of it and send the patch? Thanks for the fix, -- Soorya On Fri, 2003-07-25 at 13:32, Carl Worth wrote: > On Jul 25, Keith Packard wrote: > > Around 12 o'clock on Jul 25, Soorya Kuloor wrote: > > > > > I did a runtime profile and found that function > > > _line_segs_intersect_ceil() in file cairo_traps.c goes into an almost > > > infinite loop at the while loop at line 416. > > > > Cool -- it didn't infinite loop. We just rewrote that code to make sure > > it was correct and are doing a linear search at sub-pixel resolution. > > Changing that to a faster search should solve the performance > > problem. > > Keith just did the error analysis and determined that the "search" is > actually just a conditional increment. > > The fix is committed now. > > -Carl > > > _______________________________________________ > cairo mailing list > cairo@cairographics.org > http://cairographics.org/cgi-bin/mailman/listinfo/cairo From skuloor at verano.com Fri Jul 25 15:45:37 2003 From: skuloor at verano.com (Soorya Kuloor) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] cairo_surfce_set_clip_region Message-ID: <1059173137.28176.36.camel@dolphin.calgary.verano.com> Hi, I am trying to implement cairo_surface_set_clip_region() function. I now have a version that works if the server has Render extension. I basically, un-commented the existing function and commented out libic specific stuff. I could not figure out a way to convert from Region to PixRegion. However, if the function cairo_surfce_set_clip_region() takes x, y, width and height as argument rather than the Region, it is possible to convert these to PixRegion. Does this sound OK? Should I go ahead and implement it? -- Soorya From cworth at east.isi.edu Sun Jul 27 10:41:34 2003 From: cworth at east.isi.edu (Carl Worth) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] cairo_surfce_set_clip_region In-Reply-To: <1059173137.28176.36.camel@dolphin.calgary.verano.com> References: <1059173137.28176.36.camel@dolphin.calgary.verano.com> Message-ID: <16164.3790.961999.334619@scream.east.isi.edu> On Jul 25, Soorya Kuloor wrote: > I could not figure out a way to convert from Region to > PixRegion. However, if the function cairo_surfce_set_clip_region() > takes x, y, width and height as argument rather than the Region, it > is possible to convert these to PixRegion. Yes, this sounds like the right idea. I don't want to actually export any Region/PixRegion data structure. Instead, I'd like to propose the following two functions for pixel-aligned clipping on a surface: cairo_surface_clip_rectangle (cairo_surface_t *surface, int x, int y, int width, int height); cairo_surface_clip_restore (cairo_surface_t *surface); Those should be sufficient for any purpose and should be quite simple to implement. As always, any other suggestions are quite welcome. > Does this sound OK? Should I go ahead and implement it? Please feel free to go ahead with this. -Carl -- Carl Worth USC Information Sciences Institute cworth@isi.edu From skuloor at verano.com Mon Jul 28 11:04:52 2003 From: skuloor at verano.com (Soorya Kuloor) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] cairo_surfce_set_clip_region In-Reply-To: <16164.3790.961999.334619@scream.east.isi.edu> References: <1059173137.28176.36.camel@dolphin.calgary.verano.com> <16164.3790.961999.334619@scream.east.isi.edu> Message-ID: <1059415492.28176.45.camel@dolphin.calgary.verano.com> How do I restore a clip? I do not see a function to do this in either Render or libic. Do I need to remember the original surface dimensions and set the clip to the full dimension? I see an internal function in libic to destroy a clip, but don't see anything like that for Render. Thanks, -- Soorya On Sun, 2003-07-27 at 11:41, Carl Worth wrote: > On Jul 25, Soorya Kuloor wrote: > > I could not figure out a way to convert from Region to > > PixRegion. However, if the function cairo_surfce_set_clip_region() > > takes x, y, width and height as argument rather than the Region, it > > is possible to convert these to PixRegion. > > Yes, this sounds like the right idea. I don't want to actually export > any Region/PixRegion data structure. Instead, I'd like to propose the > following two functions for pixel-aligned clipping on a surface: > > cairo_surface_clip_rectangle (cairo_surface_t *surface, > int x, int y, > int width, int height); > > cairo_surface_clip_restore (cairo_surface_t *surface); > > Those should be sufficient for any purpose and should be quite simple > to implement. As always, any other suggestions are quite welcome. > > > Does this sound OK? Should I go ahead and implement it? > > Please feel free to go ahead with this. > > -Carl From jboulnois at neo-rousseaux.org Mon Jul 28 14:15:53 2003 From: jboulnois at neo-rousseaux.org (jboulnois@neo-rousseaux.org) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] gtk2 cairo engine Message-ID: <1059426953.3f259289a312d@webmail.tuxfamily.org> Hi, I have done a sample gtk2 engine using cairo, For now it is in very early stage, but the result is promising. You can find it at http://www.neo-rousseaux.org/jboulnois/vector-engine_07282003.tar.gz Please send feedback Julien Boulnois From skuloor at verano.com Mon Jul 28 16:06:33 2003 From: skuloor at verano.com (Soorya Kuloor) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] Dashes problem Message-ID: <1059433593.28176.53.camel@dolphin.calgary.verano.com> Hi Carl, Cairo does not seem to support dashed stroking for curves. I looked at the code and when stroking splines, it does not use the dash information. I am attaching a test code that reproduces the problem. The test draws a rectangle and an ellipse. Before drawing both of them I used the cairo_set_dash() call. The rectangle gets drawn correctly, but not the ellipse. Similarly, if I draw a path with line and curve segments (not in the test code) the line segments get drawn using dashes, but not the curve segments. BTW, how did the OLS presentation go? -- Soorya -------------- next part -------------- A non-text attachment was scrubbed... Name: cairo-dashes.c Type: text/x-c Size: 6607 bytes Desc: not available Url : http://lists.freedesktop.org/archives/cairo/attachments/20030728/32cb0540/cairo-dashes.bin From rakko at charter.net Mon Jul 28 17:12:05 2003 From: rakko at charter.net (Eric Christopherson) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] Odd crash in cairo-demo/xrspline Message-ID: <20030729001205.GA20033@localhost> I seem to suffer a consistently reproducible crash when running the demo program xrspline. Upon running it, the X server itself crashes hard; it doesn't do any cleanup such as setting the keyboard or video back to their old states. I can't tell what's causing it. It behaves the same way whether or not RENDER hardware acceleration is turned on. I have logged the X server (with -verbose 9) and an strace of xrspline, and attached the logs to this message; besides that, I ran gdb on xrspline, using a user-defined function to continuously perform the 'step' instruction. Since the log of that is very long (130K bzip2-compressed), I have included just the last part of it in this message: [...] win_print_help (win=0xbffff3d0) at xrspline.c:548 548 for (i=0; i < ARRAY_SIZE(key_binding); i++) 549 if (! key_binding[i].is_alias) 550 printf("%s:\t%s\n", get_callback_doc (callback=0x804a383) at xrspline.c:526 526 for (i=0; i < ARRAY_SIZE(callback_doc); i++) 527 if (callback_doc[i].callback == callback) 526 for (i=0; i < ARRAY_SIZE(callback_doc); i++) 527 if (callback_doc[i].callback == callback) 526 for (i=0; i < ARRAY_SIZE(callback_doc); i++) 527 if (callback_doc[i].callback == callback) 526 for (i=0; i < ARRAY_SIZE(callback_doc); i++) 527 if (callback_doc[i].callback == callback) 526 for (i=0; i < ARRAY_SIZE(callback_doc); i++) 527 if (callback_doc[i].callback == callback) 526 for (i=0; i < ARRAY_SIZE(callback_doc); i++) 527 if (callback_doc[i].callback == callback) 526 for (i=0; i < ARRAY_SIZE(callback_doc); i++) 527 if (callback_doc[i].callback == callback) 526 for (i=0; i < ARRAY_SIZE(callback_doc); i++) 527 if (callback_doc[i].callback == callback) 526 for (i=0; i < ARRAY_SIZE(callback_doc); i++) 527 if (callback_doc[i].callback == callback) 526 for (i=0; i < ARRAY_SIZE(callback_doc); i++) 527 if (callback_doc[i].callback == callback) 526 for (i=0; i < ARRAY_SIZE(callback_doc); i++) 527 if (callback_doc[i].callback == callback) 526 for (i=0; i < ARRAY_SIZE(callback_doc); i++) 527 if (callback_doc[i].callback == callback) 526 for (i=0; i < ARRAY_SIZE(callback_doc); i++) 527 if (callback_doc[i].callback == callback) 526 for (i=0; i < ARRAY_SIZE(callback_doc); i++) 527 if (callback_doc[i].callback == callback) 526 for (i=0; i < ARRAY_SIZE(callback_doc); i++) 527 if (callback_doc[i].callback == callback) 526 for (i=0; i < ARRAY_SIZE(callback_doc); i++) 527 if (callback_doc[i].callback == callback) 526 for (i=0; i < ARRAY_SIZE(callback_doc); i++) 527 if (callback_doc[i].callback == callback) 526 for (i=0; i < ARRAY_SIZE(callback_doc); i++) 527 if (callback_doc[i].callback == callback) 526 for (i=0; i < ARRAY_SIZE(callback_doc); i++) 527 if (callback_doc[i].callback == callback) 526 for (i=0; i < ARRAY_SIZE(callback_doc); i++) 527 if (callback_doc[i].callback == callback) 526 for (i=0; i < ARRAY_SIZE(callback_doc); i++) 527 if (callback_doc[i].callback == callback) 528 return callback_doc[i].doc; 531 } win_print_help (win=0xbffff3d0) at xrspline.c:548 548 for (i=0; i < ARRAY_SIZE(key_binding); i++) 553 } main (argc=1, argv=0xbffff4f4) at xrspline.c:316 316 win_handle_events(&win); win_handle_events (win=0xbffff3d0) at xrspline.c:644 644 XEvent xev; 648 if (!XPending(win->dpy) && win->needs_refresh) { Program received signal SIGPIPE, Broken pipe. 0x410cba04 in write () from /lib/libc.so.6 Single stepping until exit from function write, which has no line number information. Program terminated with signal SIGPIPE, Broken pipe. The program no longer exists. The program is not being run. Does anyone know what could be wrong here? If any more info is necessary to diagnose the situation, please ask (I'm inexperienced at debugging these things myself). -- Furrfu! r a k k o at c h a r t e r dot n e t From rakko at charter.net Mon Jul 28 17:13:14 2003 From: rakko at charter.net (Eric Christopherson) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] Re: Odd crash in cairo-demo/xrspline In-Reply-To: <20030729001205.GA20033@localhost> References: <20030729001205.GA20033@localhost> Message-ID: <20030729001313.GA20147@localhost> I'm sorry; I forgot to attach the logs. -- Furrfu! r a k k o at c h a r t e r dot n e t -------------- next part -------------- A non-text attachment was scrubbed... Name: startx.out.bz2 Type: application/octet-stream Size: 7053 bytes Desc: not available Url : http://lists.freedesktop.org/archives/cairo/attachments/20030728/0ff98a60/startx.out.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: xrspline.strace.bz2 Type: application/octet-stream Size: 9620 bytes Desc: not available Url : http://lists.freedesktop.org/archives/cairo/attachments/20030728/0ff98a60/xrspline.strace.obj From cworth at east.isi.edu Mon Jul 28 16:18:19 2003 From: cworth at east.isi.edu (Carl Worth) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] gtk2 cairo engine In-Reply-To: <1059426953.3f259289a312d@webmail.tuxfamily.org> References: <1059426953.3f259289a312d@webmail.tuxfamily.org> Message-ID: <16165.44859.134933.170388@scream.east.isi.edu> On Jul 28, jboulnois@neo-rousseaux.org wrote: > Hi, > I have done a sample gtk2 engine using cairo, > For now it is in very early stage, but the result is promising. > You can find it at > http://www.neo-rousseaux.org/jboulnois/vector-engine_07282003.tar.gz > Please send feedback Julien, Great work! This looks quite interesting. Let me know if there are any aspects of the Cairo API that make this task especially painful, (or even especially pleasant). One thing I noticed in the code: cairo_t *xrs=cairo_create(); xrs=cairo_create(); That allocates two separate cairo_t structures (and leaks the first one). You definitely don't want to do that. Also, if you are interested, you might try rendering gradients with Cairo. The OLS paper has an example that shows how you can achieve linear gradients, (you'll have to change the XrNames to cairo_names of course): http://cairographics.org/xr_ols2003/html/xr_ols2003.html#fig:outline_source The idea is to draw a small Nx1 image with one pixel per component of the gradient, (eg. in the black->white->black gradients in the paper, N=3). Then set a matrix to scale this image to the size of the object to be filled and set it to use bilinear interpolation when scaling. Apply the scaled image using cairo_set_pattern, then fill and Voila! a lovely, smooth gradient. Cheers, -Carl From cworth at east.isi.edu Mon Jul 28 16:26:37 2003 From: cworth at east.isi.edu (Carl Worth) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] Dashes problem In-Reply-To: <1059433593.28176.53.camel@dolphin.calgary.verano.com> References: <1059433593.28176.53.camel@dolphin.calgary.verano.com> Message-ID: <16165.45357.979613.7277@scream.east.isi.edu> On Jul 28, Soorya Kuloor wrote: > Cairo does not seem to support dashed stroking for curves. Correct. This just hasn't been implemented yet. Keith wrote the dash code, but he did that before I had the spline code written. Now, I just need to find a way to con him into coding up similar support for splines. ;-) > BTW, how did the OLS presentation go? I think it went pretty well -- thanks for asking. We had pretty good attendance, (especially for such a heavily kernel-oriented conference). The good questions that were asked showed that people were putting real thought into the problems we were discussing, (which is even more impressive when you realize this was the first time slot on Saturday morning). We had fun drawing up a little concept for a Cairo logo that we put on the opening slide. Unfortunately, I didn't get a copy of the presentation off of Keith's laptop, and now I think he's off on vacation with no net access. When he gets back, we'll post the slides and use some of the graphics to spruce up the web page a bit. -Carl From cworth at east.isi.edu Mon Jul 28 16:48:32 2003 From: cworth at east.isi.edu (Carl Worth) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] Odd crash in cairo-demo/xrspline In-Reply-To: <20030729001205.GA20033@localhost> References: <20030729001205.GA20033@localhost> Message-ID: <16165.46672.589153.38980@scream.east.isi.edu> On Jul 28, Eric Christopherson wrote: > I seem to suffer a consistently reproducible crash when running the demo > program xrspline. Upon running it, the X server itself crashes hard; it > doesn't do any cleanup such as setting the keyboard or video back to their > old states. The server crash is obviously a bad sign. Cairo should not be able to crash the server so there is at least a bug in the server or driver somewhere, (not to say that there isn't a Cairo bug tickling it). > 648 if (!XPending(win->dpy) && win->needs_refresh) { My guess is the XPending call is causing previous requests to flush and one of those is actually triggering the problem. Why don't you try adding the following call right before the call to win_init: XSynchronize (dpy, 1); That might give a little more insight into what's causing the server such grief. Another thing to try would be to configure your server with a different driver to see if the problem goes away. If so, that would of course be very helpful to know. -Carl From cworth at east.isi.edu Mon Jul 28 17:51:30 2003 From: cworth at east.isi.edu (Carl Worth) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] Text API proposal Message-ID: <16165.50450.896068.714551@scream.east.isi.edu> OLS was a lot of fun, and Keith and I were able to put some good time into the Cairo API and implementation. We audited the API for warts[*], fixed a few numerical problems in the implementation, and sketched out a plan for text. My current tree is still churning as I prepare the new backend abstraction framework. While I'm doing that, I thought I'd let everyone take a look at the text API and give feedback. Here's the proposed primary Cairo text functionality which fits in 7 functions. There's a "toy" API here so people like me can succeed in getting a string on the screen. Then there's a real API for placing individual glyphs at absolute locations so that people like Pango/OOo developers can get their work done: /* Font/Text functions */ void cairo_select_font (cairo_t *ct, char *name); void cairo_set_font (cairo_t *ct, cairo_font_t *font); void cairo_show_text (cairo_t *ct, const unsigned char *utf8); void cairo_text_extents (cairo_t *ct, const unsigned char *utf8, double *x, double *y, double *width, double *height, double *dx, double *dy); typedef struct cairo_glyph { cairo_font_t *font; FT_UInt id; double x; double y; } cairo_glyph_t; void cairo_show_glyphs (cairo_t *ct, cairo_glyph_t *glyphs, int num_glyphs); void cairo_text_path (cairo_t *ct, const unsigned char *utf8); void cairo_glyph_path (cairo_t *ct, cairo_glyph_t *glyphs, int num_glyphs); /* XXX: Does anyone really need a cairo_glyph_extents function? */ Notice that a Freetype datatype is exposed, (and fontconfig is implicit in that the "name" parameter will be interpreted as a fontconfig pattern string). That theme continues in the remaining new cairo_font_t functions. Most of these just exist to let users get at what they need in order to be able to call fontconfig/Freetype directly: /* Font manipulation */ cairo_font_t * cairo_font_create (FcPattern *pattern); cairo_font_t * cairo_font_create_scale (FcPattern *pattern, double scale); cairo_font_t * cairo_font_create_transform (FcPattern *pattern, cairo_matrix_t *transform); cairo_font_t * cairo_font_create_for_ft_face (FT_Face face); void cairo_font_destroy (cairo_font_t *font); cairo_font_t * cairo_font_scale (cairo_font_t *font, double scale); cairo_font_t * cairo_font_transform (cairo_font_t *font, cairo_matrix_t *transform); FT_Face cairo_font_ft_face (cairo_font_t *font); FcPattern * cairo_font_pattern (cairo_font_t *font); FcCharSet * cairo_font_char_set (cairo_font_t *font); double cairo_font_ascent (cairo_font_t *font); double cairo_font_descent (cairo_font_t *font); double cairo_font_height (cairo_font_t *font); double cairo_font_max_advance_width (cairo_font_t *font); So let us know what you think. Especially if you have a real application that needs something that's not here. -Carl [*] This is buried here in the vain hope that I can slip a couple of API changes past without anyone complaining, (we'll see who actually reads this far): 1) Right now, there are a bunch of "cairo_get_*" functions which is a gratuitous deviation from the PostScript current* operator names. The biggest wart is the function "cairo_get_current_point" which can't make up its mind which convention to follow. And, since "cairo_get_point" doesn't work, we propose to use "cairo_current_point" and change all other "cairo_get_*" functions to "cairo_current_*". So sorry that the function names get longer. Some of you might need to save up and buy new terminal emulators with more columns. 2) After an initial idea from my wife, Keith had the idea to rename "cairo_surface_*" to "cairo_papyrus_*". The metaphor is more direct in addition to being thematic. But of course, the coolest part of that is that the number of characters doesn't change at all. -- Carl Worth USC Information Sciences Institute cworth@isi.edu From rakko at charter.net Mon Jul 28 20:48:37 2003 From: rakko at charter.net (Eric Christopherson) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] Odd crash in cairo-demo/xrspline In-Reply-To: <16165.46672.589153.38980@scream.east.isi.edu> References: <20030729001205.GA20033@localhost> <16165.46672.589153.38980@scream.east.isi.edu> Message-ID: <20030729034837.GA3959@localhost> On Mon, Jul 28, 2003 at 07:48:32PM -0400, Carl Worth wrote: > On Jul 28, Eric Christopherson wrote: > > I seem to suffer a consistently reproducible crash when running the demo > > program xrspline. Upon running it, the X server itself crashes hard; it > > doesn't do any cleanup such as setting the keyboard or video back to their > > old states. > > The server crash is obviously a bad sign. Cairo should not be able to > crash the server so there is at least a bug in the server or driver > somewhere, (not to say that there isn't a Cairo bug tickling it). > > > 648 if (!XPending(win->dpy) && win->needs_refresh) { > > My guess is the XPending call is causing previous requests to flush > and one of those is actually triggering the problem. Why don't you try > adding the following call right before the call to win_init: > > XSynchronize (dpy, 1); > > That might give a little more insight into what's causing the server > such grief. > > Another thing to try would be to configure your server with a > different driver to see if the problem goes away. If so, that would of > course be very helpful to know. Thanks... but neither the added XSynchronize nor changing drivers (from proprietary NVidia to open-source NV) helped. -- Furrfu! r a k k o at c h a r t e r dot n e t From rth at twiddle.net Mon Jul 28 23:40:38 2003 From: rth at twiddle.net (Richard Henderson) Date: Mon Aug 15 11:10:44 2005 Subject: [Cairo] ELF shared library improvements [0/4] Message-ID: <20030729064038.GB29315@twiddle.net> Inspired by Carl and Keith's nice OLS talk, I'd like to help out by adding machinery to build better elf shared libraries. The patches I've generated for this are somewhat long and tedious, but that's what transcontinental flights are for, right? Anyway, part the zeroth concerns a couple of common header files that I think would be nice to have. I can't think of what to name them though. For my own testing I've just dropped them by hand into an include directory. I think ideally they'd live alongside other useful headers such as , but what to do for the moment is still an issue. Parts 1 through 4 will use these headers (plus other minor changes, usually the addition of "static" or "const") to reduce the number of dynamic symbols and relocations to what appears to be the bare minimum. Later I will add elf symbol versioning, but I havn't yet written the autoconfigury to make sure that such support exists. At the moment I've just edited the makefiles by hand to see that the versioning itself works. Anyway, here's the common header files mentioned above, with names not quite chosen at random. Perhaps someone can suggest what should be done with them, package-wise? r~ -------------- next part -------------- --- /dev/null 2003-01-30 05:24:37.000000000 -0500 +++ bits/export.h 2003-07-27 21:33:40.000000000 -0400 @@ -0,0 +1,7 @@ +/* This file is included multiple times. Don't ifdef protect it. */ + +#if defined(WIN32) || defined(__CYGWIN__) +#define __external_linkage __declspec(dllexport) +#else +#define __external_linkage +#endif --- /dev/null 2003-01-30 05:24:37.000000000 -0500 +++ bits/import.h 2003-07-27 21:33:14.000000000 -0400 @@ -0,0 +1,7 @@ +/* This file is included multiple times. Don't ifdef protect it. */ + +#if defined(WIN32) || defined(__CYGWIN__) +#define __external_linkage __declspec(dllimport) +#else +#define __external_linkage +#endif --- /dev/null 2003-01-30 05:24:37.000000000 -0500 +++ bits/internal.h 2003-07-27 21:51:34.000000000 -0400 @@ -0,0 +1,49 @@ +#ifndef BITS_INTERNAL_H +#define BITS_INTERNAL_H 1 + +#if (__GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 2)) && defined(__ELF__) +#define __internal_linkage __attribute__((__visibility__("hidden"))) +#else +#define __internal_linkage +#endif + +/* The following macros are used for PLT bypassing. First of all, + you need to have the function prototyped somewhere, say in foo.h: + + int foo (int __bar); + + If calls to foo within libfoo.so should always go to foo defined + in libfoo.so, then in fooint.h you add: + + hidden_proto (foo) + + and after the foo function definition: + + int foo (int __bar) + { + return __bar; + } + hidden_def (foo) +*/ + +#if __GNUC__ >= 2 && defined(__ELF__) +# define hidden_proto(name) hidden_proto1(name, INT_##name) +# define hidden_proto1(name, internal) \ + extern __typeof (name) name \ + __asm__ (hidden_asmname (internal)) \ + __internal_linkage; +# define hidden_def(name) hidden_def1(name, INT_##name) +# define hidden_def1(name, internal) \ + extern __typeof (name) EXT_##name __asm__(hidden_asmname(name)) \ + __attribute__((__alias__(hidden_asmname(internal)))); +# define hidden_ulp hidden_ulp1(__USER_LABEL_PREFIX__) +# define hidden_ulp1(x) hidden_ulp2(x) +# define hidden_ulp2(x) #x +# define hidden_asmname(name) hidden_asmname1(name) +# define hidden_asmname1(name) hidden_ulp #name +#else +# define hidden_proto(name) +# define hidden_def(name) +#endif + +#endif /* BITS_INTERNAL_H */ From rth at twiddle.net Mon Jul 28 23:51:46 2003 From: rth at twiddle.net (Richard Henderson) Date: Mon Aug 15 11:10:45 2005 Subject: [Cairo] ELF shared library improvements [1/4] In-Reply-To: <20030729064038.GB29315@twiddle.net> References: <20030729064038.GB29315@twiddle.net> Message-ID: <20030729065146.GC29315@twiddle.net> The patch to libpixregion is the simplest, mostly because the library is a single object file, and was already marked static as necessary. The first trick here that most folks are not aware of is the avoidance of PLT entries for calls within a single library. This is yet another side effect of the occasionally usefull, occasionally annoying name binding rules that ELF has. The mechanism to work around this is a pair of symbols at the same address, one private, one public. The somewhat automatic generation of these symbols is somewhat of a black art, and only works with gcc; see the previous patch for gory details. Other compilers just suffer with the unnecessary indirection. r~ -------------- next part -------------- Index: src/pixregion.c =================================================================== RCS file: /local/src/CVS/libpixregion/src/pixregion.c,v retrieving revision 1.2 diff -c -p -d -u -p -r1.2 pixregion.c --- src/pixregion.c 25 Feb 2003 18:28:05 -0000 1.2 +++ src/pixregion.c 29 Jul 2003 06:41:46 -0000 @@ -51,6 +51,7 @@ SOFTWARE. #include #include "pixregionint.h" +#include #if defined (__GNUC__) && !defined (NO_INLINES) #define INLINE __inline @@ -87,6 +88,10 @@ PixRegionInit (PixRegion *region, PixReg static void PixRegionUninit (PixRegion *region); +hidden_proto(PixRegionCreateSimple) +hidden_proto(PixRegionCopy) +hidden_proto(PixRegionUnion) + /* * The functions in this file implement the Region abstraction used extensively * throughout the X11 sample server. A Region is simply a set of disjoint @@ -325,6 +330,7 @@ PixRegionCreateSimple (PixRegionBox *ext return region; } +hidden_def(PixRegionCreateSimple) /***************************************************************** * RegionInit(pReg, rect, size) @@ -449,6 +455,7 @@ PixRegionCopy(PixRegion *dst, PixRegion dst->data->numRects * sizeof(PixRegionBox)); return PixRegionStatusSuccess; } +hidden_def(PixRegionCopy) /*====================================================================== @@ -1232,6 +1239,7 @@ PixRegionUnion(PixRegion *newReg, PixReg good(newReg); return PixRegionStatusSuccess; } +hidden_def(PixRegionUnion) /*====================================================================== Index: src/pixregion.h =================================================================== RCS file: /local/src/CVS/libpixregion/src/pixregion.h,v retrieving revision 1.3 diff -c -p -d -u -p -r1.3 pixregion.h --- src/pixregion.h 25 Apr 2003 20:21:42 -0000 1.3 +++ src/pixregion.h 29 Jul 2003 06:41:46 -0000 @@ -46,8 +46,18 @@ SOFTWARE. ******************************************************************/ /* $Id: pixregion.h,v 1.3 2003/04/25 20:21:42 cworth Exp $ */ -#ifndef PIXREGION_H -#define PIXREGION_H +#ifndef _PIXREGION_H_ +#define _PIXREGION_H_ + +#include + +#ifdef _PIXREGIONINT_H_ +#include +#else +#include +#endif + +_XFUNCPROTOBEGIN typedef struct _PixRegion PixRegion; @@ -62,51 +72,51 @@ typedef enum { /* creation/destruction */ -PixRegion * +extern PixRegion * __external_linkage PixRegionCreate (void); -PixRegion * +extern PixRegion * __external_linkage PixRegionCreateSimple (PixRegionBox *extents); -void +extern void __external_linkage PixRegionDestroy (PixRegion *region); /* manipulation */ -void +extern void __external_linkage PixRegionTranslate (PixRegion *region, int x, int y); -PixRegionStatus +extern PixRegionStatus __external_linkage PixRegionCopy (PixRegion *dest, PixRegion *source); -PixRegionStatus +extern PixRegionStatus __external_linkage PixRegionIntersect (PixRegion *newReg, PixRegion *reg1, PixRegion *reg2); -PixRegionStatus +extern PixRegionStatus __external_linkage PixRegionUnion (PixRegion *newReg, PixRegion *reg1, PixRegion *reg2); -PixRegionStatus +extern PixRegionStatus __external_linkage PixRegionUnionRect(PixRegion *dest, PixRegion *source, int x, int y, unsigned int width, unsigned int height); -PixRegionStatus +extern PixRegionStatus __external_linkage PixRegionSubtract (PixRegion *regD, PixRegion *regM, PixRegion *regS); -PixRegionStatus +extern PixRegionStatus __external_linkage PixRegionInverse (PixRegion *newReg, PixRegion *reg1, PixRegionBox *invRect); /* XXX: Need to fix this so it doesn't depend on an X data structure -PixRegion * +extern PixRegion * __external_linkage RectsToPixRegion (int nrects, xRectanglePtr prect, int ctype); */ /* querying */ /* XXX: These should proably be combined: PixRegionGetRects? */ -int +extern int __external_linkage PixRegionNumRects (PixRegion *region); -PixRegionBox * +extern PixRegionBox * __external_linkage PixRegionRects (PixRegion *region); /* XXX: Change to an enum */ @@ -114,36 +124,39 @@ PixRegionRects (PixRegion *region); #define rgnIN 1 #define rgnPART 2 -int +extern int __external_linkage PixRegionPointInRegion (PixRegion *region, int x, int y, PixRegionBox *box); -int +extern int __external_linkage PixRegionRectIn (PixRegion *PixRegion, PixRegionBox *prect); -int +extern int __external_linkage PixRegionNotEmpty (PixRegion *region); -PixRegionBox * +extern PixRegionBox * __external_linkage PixRegionExtents (PixRegion *region); /* mucking around */ /* WARNING: calling PixRegionAppend may leave dest as an invalid region. Follow-up with PixRegionValidate to fix it up. */ -PixRegionStatus +extern PixRegionStatus __external_linkage PixRegionAppend (PixRegion *dest, PixRegion *region); -PixRegionStatus +extern PixRegionStatus __external_linkage PixRegionValidate (PixRegion *badreg, int *pOverlap); /* Unclassified functionality * XXX: Do all of these need to be exported? */ -void +extern void __external_linkage PixRegionReset (PixRegion *region, PixRegionBox *pBox); -void +extern void __external_linkage PixRegionEmpty (PixRegion *region); -#endif /* PIXREGION_H */ +_XFUNCPROTOEND +#undef __external_linkage + +#endif /* _PIXREGION_H_ */ Index: src/pixregionint.h =================================================================== RCS file: /local/src/CVS/libpixregion/src/pixregionint.h,v retrieving revision 1.2 diff -c -p -d -u -p -r1.2 pixregionint.h --- src/pixregionint.h 25 Apr 2003 20:21:42 -0000 1.2 +++ src/pixregionint.h 29 Jul 2003 06:41:46 -0000 @@ -46,8 +46,8 @@ SOFTWARE. ******************************************************************/ /* $Id: pixregionint.h,v 1.2 2003/04/25 20:21:42 cworth Exp $ */ -#ifndef PIXREGIONINT_H -#define PIXREGIONINT_H +#ifndef _PIXREGIONINT_H_ +#define _PIXREGIONINT_H_ #include "pixregion.h" @@ -80,4 +80,4 @@ typedef struct _PixRegionPoint { #define PIXREGION_END(reg) PIXREGION_BOX(reg, (reg)->data->numRects - 1) #define PIXREGION_SZOF(n) (sizeof(PixRegionData) + ((n) * sizeof(PixRegionBox))) -#endif +#endif /* _PIXREGIONINT_H_ */ From rth at twiddle.net Mon Jul 28 23:59:49 2003 From: rth at twiddle.net (Richard Henderson) Date: Mon Aug 15 11:10:45 2005 Subject: [Cairo] ELF shared library improvements [2/4] In-Reply-To: <20030729064038.GB29315@twiddle.net> References: <20030729064038.GB29315@twiddle.net> Message-ID: <20030729065949.GD29315@twiddle.net> The patch for libic is the largest. It consists mostly of making all the individual compsiting routines and such all static functions. There's also some data arrays that are made const; some mutual header file inclusion that is cleaned up; and some plt entries hidden. r~ -------------- next part -------------- A non-text attachment was scrubbed... Name: d-cairo-elf-2.gz Type: application/x-gzip Size: 12356 bytes Desc: not available Url : http://lists.freedesktop.org/archives/cairo/attachments/20030728/92aefd57/d-cairo-elf-2.bin From rth at twiddle.net Tue Jul 29 00:01:48 2003 From: rth at twiddle.net (Richard Henderson) Date: Mon Aug 15 11:10:45 2005 Subject: [Cairo] ELF shared library improvements [0/4] In-Reply-To: <20030729064038.GB29315@twiddle.net> References: <20030729064038.GB29315@twiddle.net> Message-ID: <20030729070148.GE29315@twiddle.net> Hmm, I think I lied about patch 1 being the smallest. The libXc patch is actually a bit smaller. r~ -------------- next part -------------- Index: src/Xc.h =================================================================== RCS file: /local/src/CVS/Xc/src/Xc.h,v retrieving revision 1.10 diff -c -p -d -u -p -r1.10 Xc.h --- src/Xc.h 29 May 2003 02:34:41 -0000 1.10 +++ src/Xc.h 29 Jul 2003 07:00:30 -0000 @@ -33,6 +33,12 @@ #include #include +#ifdef _XCINT_H_ +#include +#else +#include +#endif + typedef struct _XcSurface XcSurface; typedef XRenderColor XcColor; @@ -43,36 +49,36 @@ _XFUNCPROTOBEGIN /* XXX: What's the best way to support both windows and pixmaps? Right now, this function uses exclusively visual or render_format. Visual is examined first and used if non-null. */ -XcSurface * +extern XcSurface * __external_linkage XcSurfaceCreateForDrawable (Display *dpy, Drawable drawable, Visual *visual, int render_format, Colormap colormap); -XcSurface * +extern XcSurface * __external_linkage XcSurfaceCreateForIcImage (IcImage *image); -void +extern void __external_linkage XcSurfaceDestroy (XcSurface *surface); /* surface manipulation */ /* XXX: Need to resolve Region vs. PixRegion * before this can work -void +extern void __external_linkage XcSurfaceSetClipRegion (XcSurface *surface, Region region); */ -void +extern void __external_linkage XcSurfaceSetAlphaMap (XcSurface *surface, XcSurface *alpha); -void +extern void __external_linkage XcSurfaceSetTransform (XcSurface *surface, XTransform *transform); -void +extern void __external_linkage XcSurfaceGetTransform (XcSurface *surface, XTransform *transform); @@ -84,17 +90,17 @@ typedef enum { XcFilterBilinear = IcFilterBilinear } XcFilter; -void +extern void __external_linkage XcSurfaceSetFilter (XcSurface *surface, XcFilter filter); -void +extern void __external_linkage XcSurfaceSetRepeat (XcSurface *surface, int repeat); /* XXX: Questions: should the data pointer be unsigned? Do we want to switch away from the char * for reasons of endian-ness? */ -void +extern void __external_linkage XcSurfacePutImage (XcSurface *surface, unsigned char *data, unsigned int width, @@ -103,7 +109,7 @@ XcSurfacePutImage (XcSurface *surface, /* compositing */ -void +extern void __external_linkage XcComposite (int op, XcSurface *src, XcSurface *mask, @@ -117,7 +123,7 @@ XcComposite (int op, unsigned int width, unsigned int height); -void +extern void __external_linkage XcFillRectangle (int op, XcSurface *dst, const XcColor *color, @@ -126,14 +132,14 @@ XcFillRectangle (int op, unsigned int width, unsigned int height); -void +extern void __external_linkage XcFillRectangles (int op, XcSurface *dst, const XcColor *color, const XRectangle *rects, int nrects); -void +extern void __external_linkage XcCompositeTrapezoids (int op, XcSurface *src, XcSurface *dst, @@ -142,7 +148,7 @@ XcCompositeTrapezoids (int op, const XTrapezoid *traps, int ntraps); -void +extern void __external_linkage XcCompositeTriangles (int op, XcSurface *src, XcSurface *dst, @@ -157,9 +163,10 @@ XcCompositeTriangles (int op, world. For now, though, while Xr is using Xft and until we decide the long-term plan for sharing code between Xft/Xc, Xr needs this function. */ -Picture +extern Picture __external_linkage XcSurfaceGetPicture(XcSurface *surface); _XFUNCPROTOEND +#undef __external_linkage -#endif +#endif /* _XC_H_ */ Index: src/xcint.h =================================================================== RCS file: /local/src/CVS/Xc/src/xcint.h,v retrieving revision 1.5 diff -c -p -d -u -p -r1.5 xcint.h --- src/xcint.h 15 May 2003 01:16:16 -0000 1.5 +++ src/xcint.h 29 Jul 2003 07:00:30 -0000 @@ -28,6 +28,7 @@ #define _XCINT_H_ #include "Xc.h" +#include #define XC_SURFACE_RENDER_AT_LEAST(surface, major, minor) \ (((surface)->render_major > major) ? 1 \ @@ -76,10 +77,10 @@ struct _XcSurface { /* XXX: Can someone think of better names for these? These functions are used when there are two copies of the image data. One where the user wants it, and another one local for manipulation. */ -void +extern void __internal_linkage _XcSurfacePullImage (XcSurface *surface); -void +extern void __internal_linkage _XcSurfacePushImage (XcSurface *surface); #endif From rth at twiddle.net Tue Jul 29 00:07:38 2003 From: rth at twiddle.net (Richard Henderson) Date: Mon Aug 15 11:10:45 2005 Subject: [Cairo] ELF shared library improvements [0/4] In-Reply-To: <20030729064038.GB29315@twiddle.net> References: <20030729064038.GB29315@twiddle.net> Message-ID: <20030729070738.GF29315@twiddle.net> Finally, the cairo patch. All plt avoidance here. I have to apologize; I just noticed that one of the files seems to have been gratuitously re-indented by my editor. Since I use vi, I'd never considered this to be a danger that I needed to watch out for. Clearly there's some New Evil in vim that I need to figure out how to turn off. Anyway, I can undo this and generate a new patch, but thought I'd go ahead and post this so that it shows up with the others. r~ -------------- next part -------------- Index: src/cairo.c =================================================================== RCS file: /local/src/CVS/cairo/src/cairo.c,v retrieving revision 1.2 diff -c -p -d -u -p -r1.2 cairo.c --- src/cairo.c 24 Jul 2003 04:20:25 -0000 1.2 +++ src/cairo.c 29 Jul 2003 07:02:02 -0000 @@ -103,6 +103,7 @@ cairo_save (cairo_t *cr) top->next = cr->gstate; cr->gstate = top; } +hidden_def(cairo_save) void cairo_restore (cairo_t *cr) @@ -122,6 +123,7 @@ cairo_restore (cairo_t *cr) _cairo_gstate_destroy (top); } +hidden_def(cairo_restore) /* XXX: I want to rethink this API void @@ -159,6 +161,7 @@ cairo_set_target_surface (cairo_t *cr, c cr->status = _cairo_gstate_set_target_surface (cr->gstate, surface); } +hidden_def(cairo_set_target_surface) cairo_surface_t * cairo_get_target_surface (cairo_t *cr) @@ -493,6 +496,7 @@ cairo_move_to (cairo_t *cr, double x, do cr->status = _cairo_gstate_move_to (cr->gstate, x, y); } +hidden_def(cairo_move_to) void cairo_line_to (cairo_t *cr, double x, double y) @@ -535,6 +539,7 @@ cairo_rel_line_to (cairo_t *cr, double d cr->status = _cairo_gstate_rel_line_to (cr->gstate, dx, dy); } +hidden_def(cairo_rel_line_to) void cairo_rel_curve_to (cairo_t *cr, @@ -574,6 +579,7 @@ cairo_close_path (cairo_t *cr) cr->status = _cairo_gstate_close_path (cr->gstate); } +hidden_def(cairo_close_path) void cairo_get_current_point (cairo_t *cr, double *x, double *y) Index: src/cairo.h =================================================================== RCS file: /local/src/CVS/cairo/src/cairo.h,v retrieving revision 1.2 diff -c -p -d -u -p -r1.2 cairo.h --- src/cairo.h 18 Jul 2003 19:42:49 -0000 1.2 +++ src/cairo.h 29 Jul 2003 07:02:02 -0000 @@ -28,238 +28,243 @@ #ifndef _CAIRO_H_ #define _CAIRO_H_ +#include #include +#ifdef _CAIROINT_H_ +#include +#else +#include +#endif + typedef struct cairo cairo_t; typedef struct cairo_surface cairo_surface_t; typedef struct cairo_matrix cairo_matrix_t; -#ifdef __cplusplus -extern "C" { -#endif +_XFUNCPROTOBEGIN /* Functions for manipulating state objects */ -cairo_t * +extern cairo_t * __external_linkage cairo_create (void); -void +extern void __external_linkage cairo_destroy (cairo_t *cr); -void +extern void __external_linkage cairo_save (cairo_t *cr); -void +extern void __external_linkage cairo_restore (cairo_t *cr); /* XXX: I want to rethink this API -void -cairo_push_group (cairo_t *cr); + extern void __external_linkage + cairo_push_group (cairo_t *cr); -void -cairo_pop_group (cairo_t *cr); -*/ + extern void __external_linkage + cairo_pop_group (cairo_t *cr); + */ /* Modify state */ -void +extern void __external_linkage cairo_set_target_surface (cairo_t *cr, cairo_surface_t *surface); typedef enum cairo_format { - CAIRO_FORMAT_ARGB32 = PictStandardARGB32, - CAIRO_FORMAT_RGB24 = PictStandardRGB24, - CAIRO_FORMAT_A8 = PictStandardA8, - CAIRO_FORMAT_A1 = PictStandardA1 + CAIRO_FORMAT_ARGB32 = PictStandardARGB32, + CAIRO_FORMAT_RGB24 = PictStandardRGB24, + CAIRO_FORMAT_A8 = PictStandardA8, + CAIRO_FORMAT_A1 = PictStandardA1 } cairo_format_t; -void +extern void __external_linkage cairo_set_target_drawable (cairo_t *cr, - Display *dpy, - Drawable drawable); + Display *dpy, + Drawable drawable); -void +extern void __external_linkage cairo_set_target_image (cairo_t *cr, - char *data, - cairo_format_t format, - int width, - int height, - int stride); + char *data, + cairo_format_t format, + int width, + int height, + int stride); typedef enum cairo_operator { - CAIRO_OPERATOR_CLEAR = PictOpClear, - CAIRO_OPERATOR_SRC = PictOpSrc, - CAIRO_OPERATOR_DST = PictOpDst, - CAIRO_OPERATOR_OVER = PictOpOver, - CAIRO_OPERATOR_OVER_REVERSE = PictOpOverReverse, - CAIRO_OPERATOR_IN = PictOpIn, - CAIRO_OPERATOR_IN_REVERSE = PictOpInReverse, - CAIRO_OPERATOR_OUT = PictOpOut, - CAIRO_OPERATOR_OUT_REVERSE = PictOpOutReverse, - CAIRO_OPERATOR_ATOP = PictOpAtop, - CAIRO_OPERATOR_ATOP_REVERSE = PictOpAtopReverse, - CAIRO_OPERATOR_XOR = PictOpXor, - CAIRO_OPERATOR_ADD = PictOpAdd, - CAIRO_OPERATOR_SATURATE = PictOpSaturate, + CAIRO_OPERATOR_CLEAR = PictOpClear, + CAIRO_OPERATOR_SRC = PictOpSrc, + CAIRO_OPERATOR_DST = PictOpDst, + CAIRO_OPERATOR_OVER = PictOpOver, + CAIRO_OPERATOR_OVER_REVERSE = PictOpOverReverse, + CAIRO_OPERATOR_IN = PictOpIn, + CAIRO_OPERATOR_IN_REVERSE = PictOpInReverse, + CAIRO_OPERATOR_OUT = PictOpOut, + CAIRO_OPERATOR_OUT_REVERSE = PictOpOutReverse, + CAIRO_OPERATOR_ATOP = PictOpAtop, + CAIRO_OPERATOR_ATOP_REVERSE = PictOpAtopReverse, + CAIRO_OPERATOR_XOR = PictOpXor, + CAIRO_OPERATOR_ADD = PictOpAdd, + CAIRO_OPERATOR_SATURATE = PictOpSaturate, - CAIRO_OPERATOR_DISJOINT_CLEAR = PictOpDisjointClear, - CAIRO_OPERATOR_DISJOINT_SRC = PictOpDisjointSrc, - CAIRO_OPERATOR_DISJOINT_DST = PictOpDisjointDst, - CAIRO_OPERATOR_DISJOINT_OVER = PictOpDisjointOver, - CAIRO_OPERATOR_DISJOINT_OVER_REVERSE = PictOpDisjointOverReverse, - CAIRO_OPERATOR_DISJOINT_IN = PictOpDisjointIn, - CAIRO_OPERATOR_DISJOINT_IN_REVERSE = PictOpDisjointInReverse, - CAIRO_OPERATOR_DISJOINT_OUT = PictOpDisjointOut, - CAIRO_OPERATOR_DISJOINT_OUT_REVERSE = PictOpDisjointOutReverse, - CAIRO_OPERATOR_DISJOINT_ATOP = PictOpDisjointAtop, - CAIRO_OPERATOR_DISJOINT_ATOP_REVERSE = PictOpDisjointAtopReverse, - CAIRO_OPERATOR_DISJOINT_XOR = PictOpDisjointXor, + CAIRO_OPERATOR_DISJOINT_CLEAR = PictOpDisjointClear, + CAIRO_OPERATOR_DISJOINT_SRC = PictOpDisjointSrc, + CAIRO_OPERATOR_DISJOINT_DST = PictOpDisjointDst, + CAIRO_OPERATOR_DISJOINT_OVER = PictOpDisjointOver, + CAIRO_OPERATOR_DISJOINT_OVER_REVERSE = PictOpDisjointOverReverse, + CAIRO_OPERATOR_DISJOINT_IN = PictOpDisjointIn, + CAIRO_OPERATOR_DISJOINT_IN_REVERSE = PictOpDisjointInReverse, + CAIRO_OPERATOR_DISJOINT_OUT = PictOpDisjointOut, + CAIRO_OPERATOR_DISJOINT_OUT_REVERSE = PictOpDisjointOutReverse, + CAIRO_OPERATOR_DISJOINT_ATOP = PictOpDisjointAtop, + CAIRO_OPERATOR_DISJOINT_ATOP_REVERSE = PictOpDisjointAtopReverse, + CAIRO_OPERATOR_DISJOINT_XOR = PictOpDisjointXor, - CAIRO_OPERATOR_CONJOINT_CLEAR = PictOpConjointClear, - CAIRO_OPERATOR_CONJOINT_SRC = PictOpConjointSrc, - CAIRO_OPERATOR_CONJOINT_DST = PictOpConjointDst, - CAIRO_OPERATOR_CONJOINT_OVER = PictOpConjointOver, - CAIRO_OPERATOR_CONJOINT_OVER_REVERSE = PictOpConjointOverReverse, - CAIRO_OPERATOR_CONJOINT_IN = PictOpConjointIn, - CAIRO_OPERATOR_CONJOINT_IN_REVERSE = PictOpConjointInReverse, - CAIRO_OPERATOR_CONJOINT_OUT = PictOpConjointOut, - CAIRO_OPERATOR_CONJOINT_OUT_REVERSE = PictOpConjointOutReverse, - CAIRO_OPERATOR_CONJOINT_ATOP = PictOpConjointAtop, - CAIRO_OPERATOR_CONJOINT_ATOP_REVERSE = PictOpConjointAtopReverse, - CAIRO_OPERATOR_CONJOINT_XOR = PictOpConjointXor + CAIRO_OPERATOR_CONJOINT_CLEAR = PictOpConjointClear, + CAIRO_OPERATOR_CONJOINT_SRC = PictOpConjointSrc, + CAIRO_OPERATOR_CONJOINT_DST = PictOpConjointDst, + CAIRO_OPERATOR_CONJOINT_OVER = PictOpConjointOver, + CAIRO_OPERATOR_CONJOINT_OVER_REVERSE = PictOpConjointOverReverse, + CAIRO_OPERATOR_CONJOINT_IN = PictOpConjointIn, + CAIRO_OPERATOR_CONJOINT_IN_REVERSE = PictOpConjointInReverse, + CAIRO_OPERATOR_CONJOINT_OUT = PictOpConjointOut, + CAIRO_OPERATOR_CONJOINT_OUT_REVERSE = PictOpConjointOutReverse, + CAIRO_OPERATOR_CONJOINT_ATOP = PictOpConjointAtop, + CAIRO_OPERATOR_CONJOINT_ATOP_REVERSE = PictOpConjointAtopReverse, + CAIRO_OPERATOR_CONJOINT_XOR = PictOpConjointXor } cairo_operator_t; -void +extern void __external_linkage cairo_set_operator (cairo_t *cr, cairo_operator_t op); /* XXX: Probably want to bite the bullet and expose a cairo_color_t object */ -void +extern void __external_linkage cairo_set_rgb_color (cairo_t *cr, double red, double green, double blue); -void +extern void __external_linkage cairo_set_pattern (cairo_t *cr, cairo_surface_t *pattern); -void +extern void __external_linkage cairo_set_tolerance (cairo_t *cr, double tolerance); -void +extern void __external_linkage cairo_set_alpha (cairo_t *cr, double alpha); typedef enum cairo_fill_rule { - CAIRO_FILL_RULE_WINDING, - CAIRO_FILL_RULE_EVEN_ODD + CAIRO_FILL_RULE_WINDING, + CAIRO_FILL_RULE_EVEN_ODD } cairo_fill_rule_t; -void +extern void __external_linkage cairo_set_fill_rule (cairo_t *cr, cairo_fill_rule_t fill_rule); -void +extern void __external_linkage cairo_set_line_width (cairo_t *cr, double width); typedef enum cairo_line_cap { - CAIRO_LINE_CAP_BUTT, - CAIRO_LINE_CAP_ROUND, - CAIRO_LINE_CAP_SQUARE + CAIRO_LINE_CAP_BUTT, + CAIRO_LINE_CAP_ROUND, + CAIRO_LINE_CAP_SQUARE } cairo_line_cap_t; -void +extern void __external_linkage cairo_set_line_cap (cairo_t *cr, cairo_line_cap_t line_cap); typedef enum cairo_line_join { - CAIRO_LINE_JOIN_MITER, - CAIRO_LINE_JOIN_ROUND, - CAIRO_LINE_JOIN_BEVEL + CAIRO_LINE_JOIN_MITER, + CAIRO_LINE_JOIN_ROUND, + CAIRO_LINE_JOIN_BEVEL } cairo_line_join_t; -void +extern void __external_linkage cairo_set_line_join (cairo_t *cr, cairo_line_join_t line_join); -void +extern void __external_linkage cairo_set_dash (cairo_t *cr, double *dashes, int ndash, double offset); -void +extern void __external_linkage cairo_set_miter_limit (cairo_t *cr, double limit); -void +extern void __external_linkage cairo_translate (cairo_t *cr, double tx, double ty); -void +extern void __external_linkage cairo_scale (cairo_t *cr, double sx, double sy); -void +extern void __external_linkage cairo_rotate (cairo_t *cr, double angle); -void +extern void __external_linkage cairo_concat_matrix (cairo_t *cr, - cairo_matrix_t *matrix); + cairo_matrix_t *matrix); -void +extern void __external_linkage cairo_set_matrix (cairo_t *cr, - cairo_matrix_t *matrix); + cairo_matrix_t *matrix); -void +extern void __external_linkage cairo_default_matrix (cairo_t *cr); /* XXX: There's been a proposal to add cairo_default_matrix_exact */ -void +extern void __external_linkage cairo_identity_matrix (cairo_t *cr); -void +extern void __external_linkage cairo_transform_point (cairo_t *cr, double *x, double *y); -void +extern void __external_linkage cairo_transform_distance (cairo_t *cr, double *dx, double *dy); -void +extern void __external_linkage cairo_inverse_transform_point (cairo_t *cr, double *x, double *y); -void +extern void __external_linkage cairo_inverse_transform_distance (cairo_t *cr, double *dx, double *dy); /* Path creation functions */ -void +extern void __external_linkage cairo_new_path (cairo_t *cr); -void +extern void __external_linkage cairo_move_to (cairo_t *cr, double x, double y); -void +extern void __external_linkage cairo_line_to (cairo_t *cr, double x, double y); -void +extern void __external_linkage cairo_curve_to (cairo_t *cr, - double x1, double y1, - double x2, double y2, - double x3, double y3); + double x1, double y1, + double x2, double y2, + double x3, double y3); -void +extern void __external_linkage cairo_rel_move_to (cairo_t *cr, double dx, double dy); -void +extern void __external_linkage cairo_rel_line_to (cairo_t *cr, double dx, double dy); -void +extern void __external_linkage cairo_rel_curve_to (cairo_t *cr, - double dx1, double dy1, - double dx2, double dy2, - double dx3, double dy3); + double dx1, double dy1, + double dx2, double dy2, + double dx3, double dy3); -void +extern void __external_linkage cairo_rectangle (cairo_t *cr, - double x, double y, - double width, double height); + double x, double y, + double width, double height); -void +extern void __external_linkage cairo_close_path (cairo_t *cr); /* Painting functions */ -void +extern void __external_linkage cairo_stroke (cairo_t *cr); -void +extern void __external_linkage cairo_fill (cairo_t *cr); /* Clipping */ -void +extern void __external_linkage cairo_clip (cairo_t *cr); /* Font/Text functions */ @@ -267,97 +272,97 @@ cairo_clip (cairo_t *cr); /* XXX: The font support should probably expose a cairo_font_t object with several functions, (cairo_font_transform, etc.) in a parallel manner as cairo_matrix_t and (eventually) cairo_color_t */ -void +extern void __external_linkage cairo_select_font (cairo_t *cr, const char *key); -void +extern void __external_linkage cairo_scale_font (cairo_t *cr, double scale); /* XXX: Probably want to use a cairo_matrix_t here, (to fix as part of the big text support rewrite) */ -void +extern void __external_linkage cairo_transform_font (cairo_t *cr, double a, double b, double c, double d); -void +extern void __external_linkage cairo_text_extents (cairo_t *cr, - const unsigned char *utf8, - double *x, double *y, - double *width, double *height, - double *dx, double *dy); + const unsigned char *utf8, + double *x, double *y, + double *width, double *height, + double *dx, double *dy); -void +extern void __external_linkage cairo_show_text (cairo_t *cr, const unsigned char *utf8); /* Image functions */ -void +extern void __external_linkage cairo_show_surface (cairo_t *cr, - cairo_surface_t *surface, - int width, - int height); + cairo_surface_t *surface, + int width, + int height); /* Query functions */ -cairo_operator_t +extern cairo_operator_t __external_linkage cairo_get_operator (cairo_t *cr); -void +extern void __external_linkage cairo_get_rgb_color (cairo_t *cr, double *red, double *green, double *blue); /* XXX: Do we want cairo_get_pattern as well? */ -double +extern double __external_linkage cairo_get_tolerance (cairo_t *cr); -double +extern double __external_linkage cairo_get_alpha (cairo_t *cr); -void +extern void __external_linkage cairo_get_current_point (cairo_t *cr, double *x, double *y); -cairo_fill_rule_t +extern cairo_fill_rule_t __external_linkage cairo_get_fill_rule (cairo_t *cr); -double +extern double __external_linkage cairo_get_line_width (cairo_t *cr); -cairo_line_cap_t +extern cairo_line_cap_t __external_linkage cairo_get_line_cap (cairo_t *cr); -cairo_line_join_t +extern cairo_line_join_t __external_linkage cairo_get_line_join (cairo_t *cr); -double +extern double __external_linkage cairo_get_miter_limit (cairo_t *cr); /* XXX: How to do cairo_get_dash??? Do we want to switch to a cairo_dash object? */ -void +extern void __external_linkage cairo_get_matrix (cairo_t *cr, - double *a, double *b, - double *c, double *d, - double *tx, double *ty); + double *a, double *b, + double *c, double *d, + double *tx, double *ty); -cairo_surface_t * +extern cairo_surface_t * __external_linkage cairo_get_target_surface (cairo_t *cr); /* Error status queries */ typedef enum cairo_status { - CAIRO_STATUS_SUCCESS = 0, - CAIRO_STATUS_NO_MEMORY, - CAIRO_STATUS_INVALID_RESTORE, - CAIRO_STATUS_INVALID_POP_GROUP, - CAIRO_STATUS_NO_CURRENT_POINT, - CAIRO_STATUS_INVALID_MATRIX + CAIRO_STATUS_SUCCESS = 0, + CAIRO_STATUS_NO_MEMORY, + CAIRO_STATUS_INVALID_RESTORE, + CAIRO_STATUS_INVALID_POP_GROUP, + CAIRO_STATUS_NO_CURRENT_POINT, + CAIRO_STATUS_INVALID_MATRIX } cairo_status_t; -cairo_status_t +extern cairo_status_t __external_linkage cairo_get_status (cairo_t *cr); -const char * +extern const char * __external_linkage cairo_get_status_string (cairo_t *cr); /* Surface mainpulation */ @@ -366,129 +371,127 @@ cairo_get_status_string (cairo_t *cr); cairo_format_t control what render format is used? Maybe I can have cairo_surface_create_for_window with a visual, and cairo_surface_create_for_pixmap with a cairo_format_t. Would that work? -*/ -cairo_surface_t * + */ +extern cairo_surface_t * __external_linkage cairo_surface_create_for_drawable (Display *dpy, - Drawable drawable, - Visual *visual, - cairo_format_t format, - Colormap colormap); + Drawable drawable, + Visual *visual, + cairo_format_t format, + Colormap colormap); -cairo_surface_t * +extern cairo_surface_t * __external_linkage cairo_surface_create_for_image (char *data, - cairo_format_t format, - int width, - int height, - int stride); + cairo_format_t format, + int width, + int height, + int stride); -cairo_surface_t * +extern cairo_surface_t * __external_linkage cairo_surface_create_similar (cairo_surface_t *other, - cairo_format_t format, - int width, - int height); + cairo_format_t format, + int width, + int height); /* XXX: One problem with having RGB and A here in one function is that it introduces the question of pre-multiplied vs. non-pre-multiplied alpha. Do I want to export a cairo_color_t structure instead? So far, no other public functions need it. */ -cairo_surface_t * +extern cairo_surface_t * __external_linkage cairo_surface_create_similar_solid (cairo_surface_t *other, - cairo_format_t format, - int width, - int height, - double red, - double green, - double blue, - double alpha); + cairo_format_t format, + int width, + int height, + double red, + double green, + double blue, + double alpha); -void +extern void __external_linkage cairo_surface_destroy (cairo_surface_t *surface); /* XXX: Should this take an X/Y offset as well? (Probably) */ -cairo_status_t +extern cairo_status_t __external_linkage cairo_surface_put_image (cairo_surface_t *surface, - char *data, - int width, - int height, - int stride); + char *data, + int width, + int height, + int stride); /* XXX: The Xc version of this function isn't quite working yet -cairo_status_t -cairo_surface_set_clip_region (cairo_surface_t *surface, Region region); -*/ + extern cairo_status_t __external_linkage + cairo_surface_set_clip_region (cairo_surface_t *surface, Region region); + */ /* XXX: Note: The current Render/Ic implementations don't do the right thing with repeat when the surface has a non-identity matrix. */ -cairo_status_t +extern cairo_status_t __external_linkage cairo_surface_set_repeat (cairo_surface_t *surface, int repeat); -cairo_status_t +extern cairo_status_t __external_linkage cairo_surface_set_matrix (cairo_surface_t *surface, cairo_matrix_t *matrix); -cairo_status_t +extern cairo_status_t __external_linkage cairo_surface_get_matrix (cairo_surface_t *surface, cairo_matrix_t *matrix); typedef enum cairo_filter { - CAIRO_FILTER_FAST = XcFilterFast, - CAIRO_FILTER_GOOD = XcFilterGood, - CAIRO_FILTER_BEST = XcFilterBest, - CAIRO_FILTER_NEAREST = XcFilterNearest, - CAIRO_FILTER_BILINEAR = XcFilterBilinear + CAIRO_FILTER_FAST = XcFilterFast, + CAIRO_FILTER_GOOD = XcFilterGood, + CAIRO_FILTER_BEST = XcFilterBest, + CAIRO_FILTER_NEAREST = XcFilterNearest, + CAIRO_FILTER_BILINEAR = XcFilterBilinear } cairo_filter_t; -cairo_status_t +extern cairo_status_t __external_linkage cairo_surface_set_filter (cairo_surface_t *surface, cairo_filter_t filter); /* Matrix functions */ -cairo_matrix_t * +extern cairo_matrix_t * __external_linkage cairo_matrix_create (void); -void +extern void __external_linkage cairo_matrix_destroy (cairo_matrix_t *matrix); -cairo_status_t +extern cairo_status_t __external_linkage cairo_matrix_copy (cairo_matrix_t *matrix, const cairo_matrix_t *other); -cairo_status_t +extern cairo_status_t __external_linkage cairo_matrix_set_identity (cairo_matrix_t *matrix); -cairo_status_t +extern cairo_status_t __external_linkage cairo_matrix_set_affine (cairo_matrix_t *cr, - double a, double b, - double c, double d, - double tx, double ty); + double a, double b, + double c, double d, + double tx, double ty); -cairo_status_t +extern cairo_status_t __external_linkage cairo_matrix_get_affine (cairo_matrix_t *matrix, - double *a, double *b, - double *c, double *d, - double *tx, double *ty); + double *a, double *b, + double *c, double *d, + double *tx, double *ty); -cairo_status_t +extern cairo_status_t __external_linkage cairo_matrix_translate (cairo_matrix_t *matrix, double tx, double ty); -cairo_status_t +extern cairo_status_t __external_linkage cairo_matrix_scale (cairo_matrix_t *matrix, double sx, double sy); -cairo_status_t +extern cairo_status_t __external_linkage cairo_matrix_rotate (cairo_matrix_t *matrix, double radians); -cairo_status_t +extern cairo_status_t __external_linkage cairo_matrix_invert (cairo_matrix_t *matrix); -cairo_status_t +extern cairo_status_t __external_linkage cairo_matrix_multiply (cairo_matrix_t *result, const cairo_matrix_t *a, const cairo_matrix_t *b); -cairo_status_t +extern cairo_status_t __external_linkage cairo_matrix_transform_distance (cairo_matrix_t *matrix, double *dx, double *dy); -cairo_status_t +extern cairo_status_t __external_linkage cairo_matrix_transform_point (cairo_matrix_t *matrix, double *x, double *y); -#ifdef __cplusplus -} -#endif - -#endif +_XFUNCPROTOEND +#undef __external_linkage +#endif /* _CAIRO_H_ */ Index: src/cairo_matrix.c =================================================================== RCS file: /local/src/CVS/cairo/src/cairo_matrix.c,v retrieving revision 1.1 diff -c -p -d -u -p -r1.1 cairo_matrix.c --- src/cairo_matrix.c 18 Jul 2003 18:34:19 -0000 1.1 +++ src/cairo_matrix.c 29 Jul 2003 07:02:02 -0000 @@ -84,6 +84,7 @@ cairo_matrix_copy (cairo_matrix_t *matri return CAIRO_STATUS_SUCCESS; } +hidden_def(cairo_matrix_copy) cairo_status_t cairo_matrix_set_identity (cairo_matrix_t *matrix) @@ -92,6 +93,7 @@ cairo_matrix_set_identity (cairo_matrix_ return CAIRO_STATUS_SUCCESS; } +hidden_def(cairo_matrix_set_identity) cairo_status_t cairo_matrix_set_affine (cairo_matrix_t *matrix, @@ -105,6 +107,7 @@ cairo_matrix_set_affine (cairo_matrix_t return CAIRO_STATUS_SUCCESS; } +hidden_def(cairo_matrix_set_affine) cairo_status_t cairo_matrix_get_affine (cairo_matrix_t *matrix, @@ -158,6 +161,7 @@ cairo_matrix_scale (cairo_matrix_t *matr return cairo_matrix_multiply (matrix, &tmp, matrix); } +hidden_def(cairo_matrix_scale) cairo_status_t _cairo_matrix_set_rotate (cairo_matrix_t *matrix, @@ -203,6 +207,7 @@ cairo_matrix_multiply (cairo_matrix_t *r return CAIRO_STATUS_SUCCESS; } +hidden_def(cairo_matrix_multiply) cairo_status_t cairo_matrix_transform_distance (cairo_matrix_t *matrix, double *dx, double *dy) @@ -219,6 +224,7 @@ cairo_matrix_transform_distance (cairo_m return CAIRO_STATUS_SUCCESS; } +hidden_def(cairo_matrix_transform_distance) cairo_status_t cairo_matrix_transform_point (cairo_matrix_t *matrix, double *x, double *y) @@ -230,6 +236,7 @@ cairo_matrix_transform_point (cairo_matr return CAIRO_STATUS_SUCCESS; } +hidden_def(cairo_matrix_transform_point) cairo_status_t cairo_matrix_transform_bounding_box (cairo_matrix_t *matrix, @@ -331,6 +338,7 @@ cairo_matrix_invert (cairo_matrix_t *mat return CAIRO_STATUS_SUCCESS; } +hidden_def(cairo_matrix_invert) cairo_status_t _cairo_matrix_compute_determinant (cairo_matrix_t *matrix, double *det) Index: src/cairo_surface.c =================================================================== RCS file: /local/src/CVS/cairo/src/cairo_surface.c,v retrieving revision 1.1 diff -c -p -d -u -p -r1.1 cairo_surface.c --- src/cairo_surface.c 18 Jul 2003 18:34:19 -0000 1.1 +++ src/cairo_surface.c 29 Jul 2003 07:02:02 -0000 @@ -58,6 +58,7 @@ cairo_surface_create_for_drawable (Displ return surface; } +hidden_def(cairo_surface_create_for_drawable) /* XXX: These definitions are 100% bogus. The problem that needs to be fixed is that Ic needs to export a real API for passing in @@ -166,6 +167,7 @@ cairo_surface_create_for_image (char *d return surface; } +hidden_def(cairo_surface_create_for_image) cairo_surface_t * cairo_surface_create_similar (cairo_surface_t *other, @@ -250,6 +252,7 @@ cairo_surface_create_similar_solid (cair _cairo_surface_fill_rectangle (surface, CAIRO_OPERATOR_SRC, &color, 0, 0, width, height); return surface; } +hidden_def(cairo_surface_create_similar_solid) void _cairo_surface_reference (cairo_surface_t *surface) @@ -281,6 +284,7 @@ cairo_surface_destroy (cairo_surface_t * free (surface); } +hidden_def(cairo_surface_destroy) cairo_status_t cairo_surface_put_image (cairo_surface_t *surface, @@ -322,6 +326,7 @@ cairo_surface_set_matrix (cairo_surface_ return CAIRO_STATUS_SUCCESS; } +hidden_def(cairo_surface_set_matrix) cairo_status_t cairo_surface_get_matrix (cairo_surface_t *surface, cairo_matrix_t *matrix) @@ -340,6 +345,7 @@ cairo_surface_get_matrix (cairo_surface_ return CAIRO_STATUS_SUCCESS; } +hidden_def(cairo_surface_get_matrix) cairo_status_t cairo_surface_set_filter (cairo_surface_t *surface, cairo_filter_t filter) @@ -365,6 +371,7 @@ cairo_surface_set_repeat (cairo_surface_ return CAIRO_STATUS_SUCCESS; } +hidden_def(cairo_surface_set_repeat) /* XXX: This function is going away, right? */ Picture Index: src/cairoint.h =================================================================== RCS file: /local/src/CVS/cairo/src/cairoint.h,v retrieving revision 1.5 diff -c -p -d -u -p -r1.5 cairoint.h --- src/cairoint.h 26 Jul 2003 06:16:31 -0000 1.5 +++ src/cairoint.h 29 Jul 2003 07:02:03 -0000 @@ -44,6 +44,8 @@ #include "cairo.h" +#include + #ifndef __GCC__ #define __attribute__(x) #endif @@ -301,304 +303,304 @@ typedef struct cairo_stroke_face { } cairo_stroke_face_t; /* cairo_gstate_t.c */ -cairo_gstate_t * +extern cairo_gstate_t * __internal_linkage _cairo_gstate_create (void); -void +extern void __internal_linkage _cairo_gstate_init (cairo_gstate_t *gstate); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_gstate_init_copy (cairo_gstate_t *gstate, cairo_gstate_t *other); -void +extern void __internal_linkage _cairo_gstate_fini (cairo_gstate_t *gstate); -void +extern void __internal_linkage _cairo_gstate_destroy (cairo_gstate_t *gstate); -cairo_gstate_t * +extern cairo_gstate_t * __internal_linkage _cairo_gstate_clone (cairo_gstate_t *gstate); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_gstate_begin_group (cairo_gstate_t *gstate); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_gstate_end_group (cairo_gstate_t *gstate); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_gstate_set_drawable (cairo_gstate_t *gstate, Drawable drawable); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_gstate_set_visual (cairo_gstate_t *gstate, Visual *visual); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_gstate_set_format (cairo_gstate_t *gstate, cairo_format_t format); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_gstate_set_target_surface (cairo_gstate_t *gstate, cairo_surface_t *surface); -cairo_surface_t * +extern cairo_surface_t * __internal_linkage _cairo_gstate_get_target_surface (cairo_gstate_t *gstate); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_gstate_set_pattern (cairo_gstate_t *gstate, cairo_surface_t *pattern); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_gstate_set_operator (cairo_gstate_t *gstate, cairo_operator_t operator); -cairo_operator_t +extern cairo_operator_t __internal_linkage _cairo_gstate_get_operator (cairo_gstate_t *gstate); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_gstate_set_rgb_color (cairo_gstate_t *gstate, double red, double green, double blue); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_gstate_get_rgb_color (cairo_gstate_t *gstate, double *red, double *green, double *blue); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_gstate_set_tolerance (cairo_gstate_t *gstate, double tolerance); -double +extern double __internal_linkage _cairo_gstate_get_tolerance (cairo_gstate_t *gstate); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_gstate_set_alpha (cairo_gstate_t *gstate, double alpha); -double +extern double __internal_linkage _cairo_gstate_get_alpha (cairo_gstate_t *gstate); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_gstate_set_fill_rule (cairo_gstate_t *gstate, cairo_fill_rule_t fill_rule); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_gstate_set_line_width (cairo_gstate_t *gstate, double width); -double +extern double __internal_linkage _cairo_gstate_get_line_width (cairo_gstate_t *gstate); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_gstate_set_line_cap (cairo_gstate_t *gstate, cairo_line_cap_t line_cap); -cairo_line_cap_t +extern cairo_line_cap_t __internal_linkage _cairo_gstate_get_line_cap (cairo_gstate_t *gstate); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_gstate_set_line_join (cairo_gstate_t *gstate, cairo_line_join_t line_join); -cairo_line_join_t +extern cairo_line_join_t __internal_linkage _cairo_gstate_get_line_join (cairo_gstate_t *gstate); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_gstate_set_dash (cairo_gstate_t *gstate, double *dash, int num_dashes, double offset); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_gstate_set_miter_limit (cairo_gstate_t *gstate, double limit); -double +extern double __internal_linkage _cairo_gstate_get_miter_limit (cairo_gstate_t *gstate); -cairo_status_t +extern cairo_status_t __internal_linkage cairo_gstate_translate (cairo_gstate_t *gstate, double tx, double ty); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_gstate_scale (cairo_gstate_t *gstate, double sx, double sy); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_gstate_rotate (cairo_gstate_t *gstate, double angle); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_gstate_concat_matrix (cairo_gstate_t *gstate, cairo_matrix_t *matrix); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_gstate_set_matrix (cairo_gstate_t *gstate, cairo_matrix_t *matrix); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_gstate_default_matrix (cairo_gstate_t *gstate); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_gstate_identity_matrix (cairo_gstate_t *gstate); -cairo_status_t +extern cairo_status_t __internal_linkage cairo_gstateransform_point (cairo_gstate_t *gstate, double *x, double *y); -cairo_status_t +extern cairo_status_t __internal_linkage cairo_gstateransform_distance (cairo_gstate_t *gstate, double *dx, double *dy); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_gstate_inverse_transform_point (cairo_gstate_t *gstate, double *x, double *y); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_gstate_inverse_transform_distance (cairo_gstate_t *gstate, double *dx, double *dy); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_gstate_new_path (cairo_gstate_t *gstate); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_gstate_move_to (cairo_gstate_t *gstate, double x, double y); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_gstate_line_to (cairo_gstate_t *gstate, double x, double y); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_gstate_curve_to (cairo_gstate_t *gstate, double x1, double y1, double x2, double y2, double x3, double y3); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_gstate_rel_move_to (cairo_gstate_t *gstate, double dx, double dy); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_gstate_rel_line_to (cairo_gstate_t *gstate, double dx, double dy); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_gstate_rel_curve_to (cairo_gstate_t *gstate, double dx1, double dy1, double dx2, double dy2, double dx3, double dy3); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_gstate_close_path (cairo_gstate_t *gstate); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_gstate_get_current_point (cairo_gstate_t *gstate, double *x, double *y); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_gstate_stroke (cairo_gstate_t *gstate); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_gstate_fill (cairo_gstate_t *gstate); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_gstate_clip (cairo_gstate_t *gstate); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_gstate_select_font (cairo_gstate_t *gstate, const char *key); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_gstate_scale_font (cairo_gstate_t *gstate, double scale); -cairo_status_t +extern cairo_status_t __internal_linkage cairo_gstateransform_font (cairo_gstate_t *gstate, double a, double b, double c, double d); -cairo_status_t +extern cairo_status_t __internal_linkage cairo_gstateext_extents (cairo_gstate_t *gstate, const unsigned char *utf8, double *x, double *y, double *width, double *height, double *dx, double *dy); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_gstate_show_text (cairo_gstate_t *gstate, const unsigned char *utf8); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_gstate_show_surface (cairo_gstate_t *gstate, cairo_surface_t *surface, int width, int height); /* cairo_color_t.c */ -void +extern void __internal_linkage _cairo_color_init (cairo_color_t *color); -void +extern void __internal_linkage _cairo_color_fini (cairo_color_t *color); -void +extern void __internal_linkage _cairo_color_set_rgb (cairo_color_t *color, double red, double green, double blue); -void +extern void __internal_linkage _cairo_color_get_rgb (cairo_color_t *color, double *red, double *green, double *blue); -void +extern void __internal_linkage _cairo_color_set_alpha (cairo_color_t *color, double alpha); /* cairo_font_t.c */ -void +extern void __internal_linkage _cairo_font_init (cairo_font_t *font); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_font_init_copy (cairo_font_t *font, cairo_font_t *other); -void +extern void __internal_linkage _cairo_font_fini (cairo_font_t *font); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_font_select (cairo_font_t *font, const char *key); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_font_scale (cairo_font_t *font, double scale); -cairo_status_t +extern cairo_status_t __internal_linkage cairo_font_transform (cairo_font_t *font, double a, double b, double c, double d); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_font_resolve_xft_font (cairo_font_t *font, cairo_gstate_t *gstate, XftFont **xft_font); /* cairo_path_t.c */ -void +extern void __internal_linkage _cairo_path_init (cairo_path_t *path); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_path_init_copy (cairo_path_t *path, cairo_path_t *other); -void +extern void __internal_linkage _cairo_path_fini (cairo_path_t *path); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_path_move_to (cairo_path_t *path, double x, double y); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_path_line_to (cairo_path_t *path, double x, double y); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_path_curve_to (cairo_path_t *path, double x1, double y1, double x2, double y2, double x3, double y3); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_path_close_path (cairo_path_t *path); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_path_interpret (cairo_path_t *path, cairo_path_direction_t dir, const cairo_path_callbacks_t *cb, void *closure); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_path_bounds (cairo_path_t *path, double *x1, double *y1, double *x2, double *y2); /* cairo_path_tfill.c */ -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_path_fill_to_traps (cairo_path_t *path, cairo_gstate_t *gstate, cairo_traps_t *traps); /* cairo_path_tstroke.c */ -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_path_stroke_to_traps (cairo_path_t *path, cairo_gstate_t *gstate, cairo_traps_t *traps); /* cairo_surface_t.c */ -void +extern void __internal_linkage _cairo_surface_reference (cairo_surface_t *surface); -XcSurface * +extern XcSurface * __internal_linkage _cairo_surface_get_xc_surface (cairo_surface_t *surface); /* XXX: This function is going away, right? */ -Picture +extern Picture __internal_linkage _cairo_surface_get_picture (cairo_surface_t *surface); -void +extern void __internal_linkage _cairo_surface_fill_rectangle (cairo_surface_t *surface, cairo_operator_t operator, cairo_color_t *color, @@ -608,125 +610,149 @@ _cairo_surface_fill_rectangle (cairo_sur int height); /* cairo_pen_t.c */ -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_pen_init (cairo_pen_t *pen, double radius, cairo_gstate_t *gstate); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_pen_init_empty (cairo_pen_t *pen); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_pen_init_copy (cairo_pen_t *pen, cairo_pen_t *other); -void +extern void __internal_linkage _cairo_pen_fini (cairo_pen_t *pen); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_pen_add_points (cairo_pen_t *pen, XPointFixed *pt, int num_pts); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_pen_add_points_for_slopes (cairo_pen_t *pen, XPointFixed *a, XPointFixed *b, XPointFixed *c, XPointFixed *d); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_pen_find_active_cw_vertex_index (cairo_pen_t *pen, cairo_slope_fixed_t *slope, int *active); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_pen_find_active_ccw_vertex_index (cairo_pen_t *pen, cairo_slope_fixed_t *slope, int *active); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_pen_stroke_spline (cairo_pen_t *pen, cairo_spline_t *spline, double tolerance, cairo_traps_t *traps); /* cairo_polygon_t.c */ -void +extern void __internal_linkage _cairo_polygon_init (cairo_polygon_t *polygon); -void +extern void __internal_linkage _cairo_polygon_fini (cairo_polygon_t *polygon); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_polygon_add_edge (cairo_polygon_t *polygon, XPointFixed *p1, XPointFixed *p2); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_polygon_add_point (cairo_polygon_t *polygon, XPointFixed *pt); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_polygon_close (cairo_polygon_t *polygon); /* cairo_spline_t.c */ -cairo_int_status_t +extern cairo_int_status_t __internal_linkage _cairo_spline_init (cairo_spline_t *spline, XPointFixed *a, XPointFixed *b, XPointFixed *c, XPointFixed *d); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_spline_decompose (cairo_spline_t *spline, double tolerance); -void +extern void __internal_linkage _cairo_spline_fini (cairo_spline_t *spline); /* cairo_matrix_t.c */ -void +extern void __internal_linkage _cairo_matrix_init (cairo_matrix_t *matrix); -void +extern void __internal_linkage _cairo_matrix_fini (cairo_matrix_t *matrix); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_matrix_set_translate (cairo_matrix_t *matrix, double tx, double ty); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_matrix_set_scale (cairo_matrix_t *matrix, double sx, double sy); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_matrix_set_rotate (cairo_matrix_t *matrix, double angle); -cairo_status_t +extern cairo_status_t __internal_linkage cairo_matrix_transform_bounding_box (cairo_matrix_t *matrix, double *x, double *y, double *width, double *height); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_matrix_compute_determinant (cairo_matrix_t *matrix, double *det); -cairo_status_t +extern cairo_status_t __internal_linkage _cairo_matrix_compute_eigen_values (cairo_matrix_t *matrix, double *lambda1, double *lambda2); /* cairo_traps.c */ -void +extern void __internal_linkage cairo_traps_init (cairo_traps_t *traps); -void +extern void __internal_linkage cairo_traps_fini (cairo_traps_t *traps); -cairo_status_t +extern cairo_status_t __internal_linkage cairo_traps_tessellate_triangle (cairo_traps_t *traps, XPointFixed t[3]); -cairo_status_t +extern cairo_status_t __internal_linkage cairo_traps_tessellate_rectangle (cairo_traps_t *traps, XPointFixed q[4]); -cairo_status_t +extern cairo_status_t __internal_linkage cairo_traps_tessellate_polygon (cairo_traps_t *traps, cairo_polygon_t *poly, cairo_fill_rule_t fill_rule); /* cairo_misc.c */ -void +extern void __internal_linkage _compute_slope (XPointFixed *a, XPointFixed *b, cairo_slope_fixed_t *slope); + +/* Avoid unnecessary PLT entries. */ + +hidden_proto(cairo_close_path) +hidden_proto(cairo_matrix_copy) +hidden_proto(cairo_matrix_invert) +hidden_proto(cairo_matrix_multiply) +hidden_proto(cairo_matrix_scale) +hidden_proto(cairo_matrix_set_affine) +hidden_proto(cairo_matrix_set_identity) +hidden_proto(cairo_matrix_transform_distance) +hidden_proto(cairo_matrix_transform_point) +hidden_proto(cairo_move_to) +hidden_proto(cairo_rel_line_to) +hidden_proto(cairo_restore) +hidden_proto(cairo_save) +hidden_proto(cairo_set_target_surface) +hidden_proto(cairo_surface_create_for_drawable) +hidden_proto(cairo_surface_create_for_image) +hidden_proto(cairo_surface_create_similar_solid) +hidden_proto(cairo_surface_destroy) +hidden_proto(cairo_surface_get_matrix) +hidden_proto(cairo_surface_set_matrix) +hidden_proto(cairo_surface_set_repeat) #endif From thorsten.behrens at sun.com Tue Jul 29 08:13:56 2003 From: thorsten.behrens at sun.com (Thorsten Behrens) Date: Mon Aug 15 11:10:45 2005 Subject: [Cairo] Text API proposal Message-ID: Yesterday, Carl wrote: > Here's the proposed primary Cairo text functionality which fits in 7 > functions. There's a "toy" API here so people like me can succeed in > getting a string on the screen. Then there's a real API for placing > individual glyphs at absolute locations so that people like Pango/OOo > developers can get their work done: > Okay, speaking of OOo: we're currently also in the progress of overhauling our text rendering APIs, and when comparing the functionality needed for our latest draft (http://gsl.openoffice.org/canvas/api/XCanvas.html and http://gsl.openoffice.org/canvas/api/XFont.html), we're wondering whether cairo will fit the needs (or maybe, if we overestimate our needs). Because: One thing we learned in OOo is that most people prefer native widgets over a cross-platform one-size-fits-it-all approach. So when overhauling OOo's text API one of the most important design goals was to avoid this problem: The native text infrastructure should be used if possible. Users of the text API blackbox should never be bothered with any of these implementation details though. We're not sure what cairo's priorities are but we think the design goal mentioned above has some merits. We won't debate the toy API here, except for the fact that exposing FreeType might be troublesome when porting to native Windows (or OS X, that is). No, we're mainly concerned with the proposed glyph rendering API. We assume here that a Windows port will _not_ just push bitmaps for text rendering, taking all supporting libs like Pango, FreeType etc. with it, but make use of built-in functionality. Our experience has shown that working around a native font subsystems when there already is a good infrastructure causes more trouble than it solves. We think that the layout framework and the generic text API need to be so tightly coupled as to be indistinguishable for from the outside. When native font subsystems like Win's Uniscribe or OSX's ATSUI are to be used, it is very hard to separate them. Why not abstracting away the layout framework within a generic text API? That would also cater for backends (like e.g. PDF) that need more than raw glyph codes. It also allows the implementation of some neat features like "artificial glyphs". E.g. displaying the unicode character U+FF10 ("FullWidth Digit Zero") with an ASCII only font using the normal U+0030 ("ASCII Digit Zero"). Also "glyph fallback" should be possible without troubling the user of the text API. Imagine an ASCII-only font. When somebody types a text with e.g. an u-umlaut this character is not in the font. Getting the glyph from a related font and using this fallback glyph transparently for everything including e.g. measurements makes life much easier. Just our 2 cents, -- Herbert Duerr, Thorsten Behrens SO/OOo developers From jboulnois at neo-rousseaux.org Tue Jul 29 08:33:13 2003 From: jboulnois at neo-rousseaux.org (jboulnois@neo-rousseaux.org) Date: Mon Aug 15 11:10:45 2005 Subject: [Cairo] gtk2 cairo engine In-Reply-To: <16165.44859.134933.170388@scream.east.isi.edu> References: <1059426953.3f259289a312d@webmail.tuxfamily.org> <16165.44859.134933.170388@scream.east.isi.edu> Message-ID: <1059492793.3f2693b90b383@webmail.tuxfamily.org> > Great work! This looks quite interesting. Let me know if there are any > aspects of the Cairo API that make this task especially painful, (or > even especially pleasant). I found in cairo an easy way to make my own gtk engine (unlike gdk). The API has just enough functions to be understood quickly and to do powerfull rendering. Really good work! > One thing I noticed in the code: > > cairo_t *xrs=cairo_create(); > xrs=cairo_create(); > > That allocates two separate cairo_t structures (and leaks the first > one). You definitely don't want to do that. I definitely don't want to do that ! > Also, if you are interested, you might try rendering gradients with > Cairo. The OLS paper has an example that shows how you can achieve > linear gradients, (you'll have to change the XrNames to cairo_names of > course): > > http://cairographics.org/xr_ols2003/html/xr_ols2003.html#fig:outline_source > > The idea is to draw a small Nx1 image with one pixel per component of > the gradient, (eg. in the black->white->black gradients in the paper, > N=3). Then set a matrix to scale this image to the size of the object > to be filled and set it to use bilinear interpolation when > scaling. Apply the scaled image using cairo_set_pattern, then fill and > Voila! a lovely, smooth gradient. I have integreted gradient in the engine, for now, gradients are compiled with the engine but it will be possible to setup gradient in gtk RC file to choose the direction and number of colors in them. With gradients theme looks so good! The new archive is avaible at http://www.neo-rousseaux.org/jboulnois/vector-engine_07292003.tar.gz Julien Boulnois From otaylor at redhat.com Tue Jul 29 11:10:41 2003 From: otaylor at redhat.com (Owen Taylor) Date: Mon Aug 15 11:10:45 2005 Subject: [Cairo] Text API proposal In-Reply-To: References: Message-ID: <1059502241.11802.52.camel@poincare.devel.redhat.com> On Tue, 2003-07-29 at 11:13, Thorsten Behrens wrote: [...] > We won't debate the toy API here, except for the fact that exposing > FreeType might be troublesome when porting to native Windows (or OS X, > that is). No, we're mainly concerned with the proposed glyph rendering > API. We assume here that a Windows port will _not_ just push bitmaps for > text rendering, taking all supporting libs like Pango, FreeType etc. with > it, but make use of built-in functionality. Our experience has shown that > working around a native font subsystems when there already is a good > infrastructure causes more trouble than it solves. > > We think that the layout framework and the generic text API need to be so > tightly coupled as to be indistinguishable for from the outside. When > native font subsystems like Win's Uniscribe or OSX's ATSUI are to be used, > it is very hard to separate them. > Why not abstracting away the layout framework within a generic text API? > That would also cater for backends (like e.g. PDF) that need more than raw > glyph codes. Would you use Pango in OpenOffice.org on all platforms? Would use it if it was called CairoText? That's what you are proposing. Once you have: - A high level easy-to-use API that has the full power to handle complex writing systems. - A low-level abstraction that can work with different font systems like FreeType and Uniscribe. (Pango has a fully functioning Uniscribe backend. There are some performance issues, but we think they are incidental.) You have all of Pango (and 50,000 or so lines of code). If you implemented the FreeType/Unix backend by using Pango itself, you'd save a bit of that code, at the cost of efficiency and increased complexity. The question of how you can use "Pango" and Cairo together on top of something other than FreeType is indeed an interesting one and one that needs to be handled if GTK+ is going to use Cairo as it's rendering API. I don't see how putting a Pango equivalent into Cairo really helps with that; the basic plan of a solution is: - Figure out what operations Cairo needs from the font API to implement it's low-level and toy APIs: - Load a font from a name - Scale/Apply a transformation matrix to a font - Convert Unicode text to glyphs - Render a glyph to a bitmap - Add a glyph to a cairo path - Create virtualized CairoFontmap, CairoFont (or, I guess, cairo_fontmap_t, cairo_font_t, ugh.) objects. - Have functions for setting the CairoFontmap for a context - Ship implementations of CairoFont* with Cairo for major rendering systems. These would have functions like CairoFont *cairo_fontconfig_font_new_for_pattern() FT_Face cairo_fontconfig_font_lock_ft_face (). Then, as the person hooking together Cairo and Pango, then all I have to do is to write a little bit of glue to hook CairoFontconfigFont to PangoFontconfig and a bit of glue for hooking CairoWin32Font to PangoWin32. > It also allows the implementation of some neat features like "artificial > glyphs". E.g. displaying the unicode character U+FF10 ("FullWidth Digit > Zero") with an ASCII only font using the normal U+0030 ("ASCII Digit > Zero"). > Also "glyph fallback" should be possible without troubling the user of the > text API. Imagine an ASCII-only font. When somebody types a text with e.g. > an u-umlaut this character is not in the font. Getting the glyph from a > related font and using this fallback glyph transparently for everything > including e.g. measurements makes life much easier. These are "toy API" issues. Regards, Owen From cworth at east.isi.edu Tue Jul 29 13:38:14 2003 From: cworth at east.isi.edu (Carl Worth) Date: Mon Aug 15 11:10:45 2005 Subject: [Cairo] ELF shared library improvements [0/4] In-Reply-To: <20030729064038.GB29315@twiddle.net> References: <20030729064038.GB29315@twiddle.net> Message-ID: <16166.56118.787806.136208@scream.east.isi.edu> On Jul 28, Richard Henderson wrote: > Inspired by Carl and Keith's nice OLS talk, I'd like to help out > by adding machinery to build better elf shared libraries. Richard, Thank you very much for you contribution! This will be a nice improvement. > Anyway, part the zeroth concerns a couple of common header files > that I think would be nice to have. I can't think of what to > name them though. If we can come up with a reasonable name, we can add a "name_" prefix to the macros and package a single /usr/include/name.h file as its own package. Here are some lame ideas for a name, just to get the ball rolling: sos Shared Object Solution. The answer to longtime pleas for help from library developers. lips Library Protection Service. lips makes a fine prefix. Though, of course, the package name can be lipservice. slim Shared-Library Interface Macros. tia Total Interface Awareness. (Yes, I do have an office next door to DARPA). I'd probably better stop now. As far as "apt-cache search" is concerned, any of those names would be available. I think I'm partial to slim myself. -Carl From rakko at charter.net Tue Jul 29 13:46:59 2003 From: rakko at charter.net (Eric Christopherson) Date: Mon Aug 15 11:10:45 2005 Subject: [Cairo] Odd crash in cairo-demo/xrspline In-Reply-To: <16165.46672.589153.38980@scream.east.isi.edu> References: <20030729001205.GA20033@localhost> <16165.46672.589153.38980@scream.east.isi.edu> Message-ID: <20030729204659.GC24406@localhost> On Mon, Jul 28, 2003 at 07:48:32PM -0400, Carl Worth wrote: > On Jul 28, Eric Christopherson wrote: > > I seem to suffer a consistently reproducible crash when running the demo > > program xrspline. Upon running it, the X server itself crashes hard; it > > doesn't do any cleanup such as setting the keyboard or video back to their > > old states. > > The server crash is obviously a bad sign. Cairo should not be able to > crash the server so there is at least a bug in the server or driver > somewhere, (not to say that there isn't a Cairo bug tickling it). > > > 648 if (!XPending(win->dpy) && win->needs_refresh) { > > My guess is the XPending call is causing previous requests to flush > and one of those is actually triggering the problem. Why don't you try > adding the following call right before the call to win_init: > > XSynchronize (dpy, 1); > > That might give a little more insight into what's causing the server > such grief. [snip] I've run another test after adding that, and getting librender and libXrender from CVS. The end of the gdb log now looks like: XRenderFindStandardFormat (dpy=0x804b340, format=134532248) at Xrender.c:821 821 } 0x400dd3d2 in XcCompositeTrapezoids (op=3, src=0x804d4e8, dst=0x804cb70, xSrc=49, ySrc=-32767, traps=0x804eb38, ntraps=33) at xc.c:140 140 XRenderCompositeTrapezoids (dst->dpy, op, src->picture, dst->picture, XRenderCompositeTrapezoids (dpy=0x804b340, op=3, src=16777224, dst=16777220, maskFormat=0x804cc98, xSrc=49, ySrc=-32767, traps=0x804eb38, ntrap=33) at Trap.c:38 38 XRenderExtDisplayInfo *info = XRenderFindDisplay (dpy); XRenderFindDisplay (dpy=0x804b340) at Xrender.c:283 283 dpyinfo = XRenderExtFindDisplay (&XRenderExtensionInfo, dpy); XRenderExtFindDisplay (extinfo=0x40153610, dpy=0x804b340) at Xrender.c:47 47 if ((dpyinfo = extinfo->cur) && dpyinfo->display == dpy) 41 { 47 if ((dpyinfo = extinfo->cur) && dpyinfo->display == dpy) 41 { 47 if ((dpyinfo = extinfo->cur) && dpyinfo->display == dpy) 58 return dpyinfo; 64 } XRenderFindDisplay (dpy=0x804b340) at Xrender.c:284 284 if (!dpyinfo) 288 } XRenderCompositeTrapezoids (dpy=0x804b340, op=3, src=16777224, dst=16777220, maskFormat=0x804cc98, xSrc=49, ySrc=-32767, traps=0x804eb38, ntrap=33) at Trap.c:42 42 unsigned long max_req = dpy->bigreq_size ? dpy->bigreq_size : dpy->max_request_size; 44 RenderSimpleCheckExtension (dpy, info); 45 LockDisplay(dpy); 46 while (ntrap) 48 GetReq(RenderTrapezoids, req); 49 req->reqType = info->codes->major_opcode; 48 GetReq(RenderTrapezoids, req); 49 req->reqType = info->codes->major_opcode; 50 req->renderReqType = X_RenderTrapezoids; 51 req->op = (CARD8) op; 53 req->dst = dst; 54 req->maskFormat = maskFormat ? maskFormat->id : 0; 52 req->src = src; 53 req->dst = dst; 54 req->maskFormat = maskFormat ? maskFormat->id : 0; 48 GetReq(RenderTrapezoids, req); 52 req->src = src; 54 req->maskFormat = maskFormat ? maskFormat->id : 0; 59 if (len > (max_req - req->length)) { 55 req->xSrc = xSrc; 54 req->maskFormat = maskFormat ? maskFormat->id : 0; 57 n = ntrap; 56 req->ySrc = ySrc; 55 req->xSrc = xSrc; 57 n = ntrap; 59 if (len > (max_req - req->length)) { 58 len = ((long) n) * (SIZEOF (xTrapezoid) >> 2); 59 if (len > (max_req - req->length)) { 56 req->ySrc = ySrc; 59 if (len > (max_req - req->length)) { 58 len = ((long) n) * (SIZEOF (xTrapezoid) >> 2); 59 if (len > (max_req - req->length)) { 63 SetReqLen (req, len, len); 65 DataInt32 (dpy, (int *) traps, len); 64 len <<= 2; 65 DataInt32 (dpy, (int *) traps, len); 67 traps += n; 65 DataInt32 (dpy, (int *) traps, len); 67 traps += n; 69 UnlockDisplay(dpy); 70 SyncHandle(); 0x401508f4 71 } X connection to :0.0 broken (explicit kill or server shutdown). Does this help anyone tell what might be going on? -- Furrfu! r a k k o at c h a r t e r dot n e t From graydon at redhat.com Tue Jul 29 13:49:06 2003 From: graydon at redhat.com (graydon hoare) Date: Mon Aug 15 11:10:45 2005 Subject: [Cairo] [patch] implement push/pull on xc surfaces Message-ID: <87ptjtukhp.fsf@dub.venge.net> hi, this implements the previously-disabled push and pull functions on xc surfaces. this allows you to, for example, call cairo_show_surface to display a local image surface on a remote RENDER surface. it's not a terribly *good* implementation, but the entire library seems to be in enough of a state of flux that I figured I'd just post what I have and let carl's grand unification and restructuring plan borrow whatever part of it is deemed appropriate, if any. -graydon -------------- next part -------------- A non-text attachment was scrubbed... Name: push-and-pull.patch Type: text/x-patch Size: 5241 bytes Desc: not available Url : http://lists.freedesktop.org/archives/cairo/attachments/20030729/6969f73e/push-and-pull.bin From skuloor at verano.com Tue Jul 29 14:42:56 2003 From: skuloor at verano.com (Soorya Kuloor) Date: Mon Aug 15 11:10:45 2005 Subject: [Cairo] Clip rectangle Message-ID: <1059514975.28176.69.camel@dolphin.calgary.verano.com> Hi, Here are 2 patches that implement cairo_surfcae_set_clip_rectangle(). I could not find a way to implement cairo_surface_clip_restore(). Any help in implementing this is appreciated. The patches are for cairo and Xc. -- Soorya -------------- next part -------------- A non-text attachment was scrubbed... Name: cairo.patch Type: text/x-patch Size: 1615 bytes Desc: not available Url : http://lists.freedesktop.org/archives/cairo/attachments/20030729/c1a79d13/cairo.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: Xc.patch Type: text/x-patch Size: 2237 bytes Desc: not available Url : http://lists.freedesktop.org/archives/cairo/attachments/20030729/c1a79d13/Xc.bin From rth at twiddle.net Tue Jul 29 14:50:18 2003 From: rth at twiddle.net (Richard Henderson) Date: Mon Aug 15 11:10:45 2005 Subject: [Cairo] ELF shared library improvements [0/4] In-Reply-To: <16166.56118.787806.136208@scream.east.isi.edu> References: <20030729064038.GB29315@twiddle.net> <16166.56118.787806.136208@scream.east.isi.edu> Message-ID: <20030729215018.GB359@twiddle.net> On Tue, Jul 29, 2003 at 04:38:14PM -0400, Carl Worth wrote: > If we can come up with a reasonable name, we can add a "name_" prefix > to the macros and package a single /usr/include/name.h file as its own > package. If I'm not mistaken, I think we still need all three installed headers. One possible improvement would be to avoid the reliance on _PKGINT_H_ that is present in the user's public header file (e.g. ic.h). A solution that comes to mind is to edit that file twice. Once, when configuring the package to build (so that it includes the variant) and once when installing the package (so that it includes ). We could possibly hide all this with autoconf macros also distributed with the slim package. Thoughts? > slim Shared-Library Interface Macros. I think I like this best myself. r~ From cworth at east.isi.edu Tue Jul 29 15:44:51 2003 From: cworth at east.isi.edu (Carl Worth) Date: Mon Aug 15 11:10:45 2005 Subject: [Cairo] ELF shared library improvements [0/4] In-Reply-To: <20030729215018.GB359@twiddle.net> References: <20030729064038.GB29315@twiddle.net> <16166.56118.787806.136208@scream.east.isi.edu> <20030729215018.GB359@twiddle.net> Message-ID: <16166.63715.18980.232812@scream.east.isi.edu> On Jul 29, Richard Henderson wrote: > If I'm not mistaken, I think we still need all three installed > headers. Ah, I hadn't look closely enough at how this was implemented. > One possible improvement would be to avoid the reliance on _PKGINT_H_ > that is present in the user's public header file (e.g. ic.h). Would the following proposal/convention work? Slim provides two header files, (maybe slim.h and slim_internal.h). A user of slim, (say libic for example), would do the following: icint.h ------- #include #include "ic.h" ic.h ---- #include Then, the conflicting definitions from slim_internal.h and slim.h, (eg. __external_linkage macro) would be protected so that the first definition seen wins. I might be missing something as I didn't understand the comment about multiple inclusion and not using ifdef protection in internal.h and external.h. But if that works, then slim should be fairly easy to use and no autoconf macros should be needed. Plus, the changes to the public header file end up being, dare I say it?, quite slim. Or am I way off base? > > slim Shared-Library Interface Macros. > > I think I like this best myself. Sounds like it's unanimous then. -Carl From cworth at east.isi.edu Tue Jul 29 17:03:23 2003 From: cworth at east.isi.edu (Carl Worth) Date: Mon Aug 15 11:10:45 2005 Subject: [Cairo] Odd crash in cairo-demo/xrspline In-Reply-To: <20030729204659.GC24406@localhost> References: <20030729001205.GA20033@localhost> <16165.46672.589153.38980@scream.east.isi.edu> <20030729204659.GC24406@localhost> Message-ID: <16167.2891.379148.35444@scream.east.isi.edu> On Jul 29, Eric Christopherson wrote: > I've run another test after adding that, and getting librender and > libXrender from CVS. The end of the gdb log now looks like: The server is crashing in the code to render trapezoids. You might extract the trapezoid data to construct a small test case in order to file a bug against the server. Another interesting test might be to take that same trapezoid data, but feed it into an IcImage rather than XRender. Since libic contains the same trapezoid rasterization algorithm as the server, you might be able to replicate the crash within your program, (which will be much easier to debug than the server). > XRenderCompositeTrapezoids (dpy=0x804b340, op=3, src=16777224, dst=16777220, > maskFormat=0x804cc98, xSrc=49, ySrc=-32767, traps=0x804eb38, > ntrap=33) at Trap.c:42 There's one obvious piece of suspect data here. The ySrc value should be an offset into the src image, so it should not be negative and it should not have a value with such a large magnitude. You might track down where that number is coming from. Just for comparison, here's a typical call to XRenderCompositeTrapezoids that I see when running xrspline: XRenderCompositeTrapezoids (dpy=0x804b340, op=3, src=35651610, dst=35651606, maskFormat=0x804caf8, xSrc=49, ySrc=53, traps=0x804fc08, ntrap=168) at Trap.c:38 -Carl From rth at twiddle.net Tue Jul 29 17:40:47 2003 From: rth at twiddle.net (Richard Henderson) Date: Mon Aug 15 11:10:45 2005 Subject: [Cairo] ELF shared library improvements [0/4] In-Reply-To: <16166.63715.18980.232812@scream.east.isi.edu> References: <20030729064038.GB29315@twiddle.net> <16166.56118.787806.136208@scream.east.isi.edu> <20030729215018.GB359@twiddle.net> <16166.63715.18980.232812@scream.east.isi.edu> Message-ID: <20030730004047.GA887@twiddle.net> On Tue, Jul 29, 2003 at 06:44:51PM -0400, Carl Worth wrote: > Would the following proposal/convention work? No, because: > Slim provides two header files, (maybe slim.h and slim_internal.h). A > user of slim, (say libic for example), would do the following: > > icint.h > ------- > #include > #include "ic.h" > > ic.h > ---- > #include Recall that ic.h includes pixregion.h. But pixregion.h *also* includes slim.h, and we'd wind up defining all of pixregion's symbols as export instead of import. Which is bad. I.e. your scheme works only if one package at a time uses slim. Which sort of defeats the purpose. r~ From cworth at east.isi.edu Tue Jul 29 20:12:19 2003 From: cworth at east.isi.edu (Carl Worth) Date: Mon Aug 15 11:10:45 2005 Subject: [Cairo] ELF shared library improvements [0/4] In-Reply-To: <20030730004047.GA887@twiddle.net> References: <20030729064038.GB29315@twiddle.net> <16166.56118.787806.136208@scream.east.isi.edu> <20030729215018.GB359@twiddle.net> <16166.63715.18980.232812@scream.east.isi.edu> <20030730004047.GA887@twiddle.net> Message-ID: <16167.14227.886799.515709@scream.east.isi.edu> On Jul 29, Richard Henderson wrote: > Recall that ic.h includes pixregion.h. But pixregion.h *also* > includes slim.h, and we'd wind up defining all of pixregion's > symbols as export instead of import. Which is bad. OK, I think I really do understand what's going on this time, (yes I am dense --- blame it on missing almost a full week of sleep at OLS). I'm perfectly fine to live with the condition on _PKGINT_H_ in the public header. If you can come up with some magic for avoiding it, that would be great to. There's a slim module in CVS now that people can start playing with, (I haven't committed the actual macros yet -- I'll let Richard do that). -Carl From cworth at east.isi.edu Tue Jul 29 20:26:34 2003 From: cworth at east.isi.edu (Carl Worth) Date: Mon Aug 15 11:10:45 2005 Subject: [Cairo] Text API proposal In-Reply-To: References: Message-ID: <16167.15082.609615.58163@scream.east.isi.edu> On Jul 29, Thorsten Behrens wrote: > Why not abstracting away the layout framework within a generic text API? > That would also cater for backends (like e.g. PDF) that need more than raw > glyph codes. The problem is that I don't trust myself well enough to successfully abstract away high-level text layout in a sane way that will make all consumers happy, (eg. it won't prevent essential capabilities from being accessed). That's a really hard problem, that would require a font expert, (eg. not me), to pull it off. And besides, even if such a thing existed, I would think it belongs at a higher level and should build on top of what Cairo provides. The only remaining problem I see with the lower level API that Cairo exposes, is that you might have a native font service that you want to use that provides a higher-level API, but is so tightly coupled with another backend that it can't be hooked up to Cairo. If that's the case, then I'm afraid I don't know what to do to solve the problem, (other than fix the font service so that it can be retargeted). -Carl -- Carl Worth USC Information Sciences Institute cworth@isi.edu From cworth at east.isi.edu Tue Jul 29 20:36:24 2003 From: cworth at east.isi.edu (Carl Worth) Date: Mon Aug 15 11:10:45 2005 Subject: [Cairo] Text API proposal In-Reply-To: <1059502241.11802.52.camel@poincare.devel.redhat.com> References: <1059502241.11802.52.camel@poincare.devel.redhat.com> Message-ID: <16167.15672.963031.49977@scream.east.isi.edu> On Jul 29, Owen Taylor wrote: > The question of how you can use "Pango" and Cairo together on top > of something other than FreeType is indeed an interesting one > and one that needs to be handled if GTK+ is going to use Cairo > as it's rendering API. When Keith and I came up with this API, we made the conscious decision to export both fontconfig and Freetype interfaces. This is because I'm lazy and dumb. I'm too lazy to try to copy enough of Freetype's interfaces down into Cairo. And I'm too dumb to know what pieces of that interface would be essential to have in Cairo in order to abstract away Freetype. So, I have two questions: fontconfig ---------- Does anyone have a problem with Cairo exporting fontconfig as proposed? fontconfig is quite portable and I, (speaking as a user), would love to have a standard cross-platform means for naming fonts, etc. Freetype -------- Does anyone have concrete suggestions for what API to push down into Cairo in order to abstract away Freetype? If someone smart can convince me to do that, and tell me how, I might be able to overcome my laziness. Or, another option is to give in to my laziness, not invent a new interface, but declare that the Freetype API is good as is. With that, we would just require the abstraction to happen below Cairo. That is, if someone wants to use a non-Freetype renderer below Cairo, they would have to write a Freetype-style wrapper above it for Cairo to use and export. Does that make sense? Do such wrappers perhaps exist already? -Carl From thorsten.behrens at sun.com Wed Jul 30 01:52:41 2003 From: thorsten.behrens at sun.com (Thorsten Behrens) Date: Mon Aug 15 11:10:45 2005 Subject: [Cairo] Text API proposal In-Reply-To: <1059502241.11802.52.camel@poincare.devel.redhat.com> Message-ID: Yesterday, Owen wrote: > > We think that the layout framework and the generic text API need to be so > > tightly coupled as to be indistinguishable for from the outside. When > > native font subsystems like Win's Uniscribe or OSX's ATSUI are to be used, > > it is very hard to separate them. > > Would you use Pango in OpenOffice.org on all platforms? Would > use it if it was called CairoText? That's what you are proposing. > > [...] > > - A low-level abstraction that can work with different font systems > like FreeType and Uniscribe. (Pango has a fully functioning > Uniscribe backend. There are some performance issues, but we > think they are incidental.) > Yes, that was our intention. Unless somebody proves it's no longer necessary, using Uniscribe on Windows is more or less a requirement for us. Currently, we use ICU for layouting and other stuff, but (at least in principle) we think there's no problem with Pango. > The question of how you can use "Pango" and Cairo together on top > of something other than FreeType is indeed an interesting one > and one that needs to be handled if GTK+ is going to use Cairo > as it's rendering API. > Exactly. And one that should maybe figured out before the APIs become too finalized. > I don't see how putting a Pango equivalent into Cairo really helps with > that; the basic plan of a solution is: > > - Figure out what operations Cairo needs from the font API > to implement it's low-level and toy APIs: > > - Load a font from a name > - Scale/Apply a transformation matrix to a font > - Convert Unicode text to glyphs > - Render a glyph to a bitmap > - Add a glyph to a cairo path > > - Create virtualized CairoFontmap, CairoFont (or, I guess, > cairo_fontmap_t, cairo_font_t, ugh.) objects. > > - Have functions for setting the CairoFontmap for a context > > - Ship implementations of CairoFont* with Cairo for major > rendering systems. These would have functions like > CairoFont *cairo_fontconfig_font_new_for_pattern() > FT_Face cairo_fontconfig_font_lock_ft_face (). > > Then, as the person hooking together Cairo and Pango, then all > I have to do is to write a little bit of glue to hook > CairoFontconfigFont to PangoFontconfig and a bit of glue for hooking > CairoWin32Font to PangoWin32. > That sounds reasonable. The only thing we need to use Cairo portably is a high-level text interface. Do you still think that the proposed Cairo glyph render API suffices for Windows? As we've said, Uniscribe and glyph output on Windows are extremely hard to separate. Best regards, -- Thorsten "Historically speaking, the presence of wheels in Unix has never precluded their reinvention." [Larry Wall] From thorsten.behrens at sun.com Wed Jul 30 02:06:21 2003 From: thorsten.behrens at sun.com (Thorsten Behrens) Date: Mon Aug 15 11:10:45 2005 Subject: [Cairo] Text API proposal In-Reply-To: <16167.15672.963031.49977@scream.east.isi.edu> Message-ID: Yesterday, Carl wrote: > So, I have two questions: > > fontconfig > ---------- > Does anyone have a problem with Cairo exporting fontconfig as > proposed? fontconfig is quite portable and I, (speaking as a user), > would love to have a standard cross-platform means for naming fonts, > etc. > If I got Owen right, he plans something like that (or what should CairoWin32Font stand for?). > Freetype > -------- > Does anyone have concrete suggestions for what API to push down into > Cairo in order to abstract away Freetype? If someone smart can > convince me to do that, and tell me how, I might be able to overcome > my laziness. > No idea about that. How about an API that deals exactly with the functionality needed by Cairo? Makes porter's life much more easy. Generally speaking, I have the impression that we're theorizing here. The thing Cairo will benefit the most are actual ports to Windows and OSX. Only then, potential issues will show up. From what we can tell, the Cairo glyph interface will not suffice for Windows. If Owen got Pango working with Uniscribe and a glyph API, all the better (would be interesting, how broad test coverage for that version has been, though). Just some 2 cents again, -- Thorsten "Historically speaking, the presence of wheels in Unix has never precluded their reinvention." [Larry Wall] From cworth at east.isi.edu Wed Jul 30 04:53:57 2003 From: cworth at east.isi.edu (Carl Worth) Date: Mon Aug 15 11:10:45 2005 Subject: [Cairo] Text API proposal In-Reply-To: References: <16167.15672.963031.49977@scream.east.isi.edu> Message-ID: <16167.45525.400348.33937@scream.east.isi.edu> On Jul 30, Thorsten Behrens wrote: > No idea about that. How about an API that deals exactly with the > functionality needed by Cairo? Makes porter's life much more easy. The problem is that Cairo doesn't need much. It just draws glyphs at specified locations, and that's pretty easy. However, applications that compute the glyph positions are going to need a lot more information from the backend text engine. Rather than implementing all of that API in Cairo, I'm currently just passing up an FT_Face. The more I think about it, the more I realize that wrapping a native text engine to conform to a yet-to-be-proposed Cairo text API would be substantially the same effort as wrapping it to conform to the FT_Face APIs, (though it would add an extra layer within Cairo itself). So, the question is, would most of the API in Freetype be used? Is it basically what users want? Or is there a substantially smaller subset that would simplify the backend wrapping effort enough to justify more complexity in Cairo? I need feedback from potential users of Cairo text functionality in order to decide that. > Generally speaking, I have the impression that we're theorizing here. The > thing Cairo will benefit the most are actual ports to Windows and > OSX. There is a Windows port in progress, so we'll be able to look at that soon. The other datapoint that can be useful is from people that have experience wrapping text engines from various platforms. -Carl From kai.wetzel1 at freenet.de Wed Jul 30 05:32:23 2003 From: kai.wetzel1 at freenet.de (Kai Wetzel) Date: Mon Aug 15 11:10:45 2005 Subject: [Cairo] Text API proposal In-Reply-To: <16165.50450.896068.714551@scream.east.isi.edu> References: <16165.50450.896068.714551@scream.east.isi.edu> Message-ID: <200307301432.23548.kai.wetzel1@freenet.de> Hi, have you considered to get in touch with Raph Levien, David Turner, Werner Lemberg regarding the font API and maybe forward to the gs-devel mailing list ? On Tuesday 29 July 2003 02:51, Carl Worth wrote: [...] > My current tree is still churning as I prepare the new backend > abstraction framework. While I'm doing that, I thought I'd let > everyone take a look at the text API and give feedback. That's one of my main itches with the API proposal: What is the seperation between the low-level drivers' responsibilities and the "shared", high(er)-level parts of the API, e.g. is "show_text" implemented by the driver and defined to mean exactly what the PostScript "show" operator does (allowing pass-through) or is it a high-level convenience function which the driver will see as a call to "show_glyphs" ? Will exposing the FontConfig pattern (name) in select_font require a PostScript driver to know (and use, I guess) FontConfig to resolve the pattern and find a "good match" to use in the PostScript stream ? This approach seems both underspecified (in terms of how drivers agree on using the "same" font that was used in layout) as well as too broad (requiring a lot of work on the side of an individual driver). Did you consider adding "display list" support to Cairo ? I think display lists (in OpenGL, or user-defined operators/words in PostScript, stored procedures or how you want to call them) are very useful to allow some optimizations to be performed by the drivers which are otherwise hard or impossible to do (such as writing dense PostScript or SVG, caching paths or composits, preserving network bandwidth, etc.) example display lists functions: uint (tag) cairo_list_start (CAIRO_ARG); /* start "recording" */ /* operators beeing called on CAIRO_ARG are recorded, operators that return a value are not allowed here */ void cairo_list_end (CAIRO_ARG); /* end recording */ /* ... */ void call_list (CAIRO_ARG, uint tag); /* execute list */ Any chance ? > Here's the proposed primary Cairo text functionality which fits in 7 > functions. There's a "toy" API "convenience functions" :) > here so people like me can succeed in > getting a string on the screen. Then there's a real API for placing > individual glyphs at absolute locations so that people like Pango/OOo > developers can get their work done: > > /* Font/Text functions */ > > void > cairo_select_font (cairo_t *ct, char *name); Where "name" is a Xft pattern including scale/matrix, etc. ? > void > cairo_set_font (cairo_t *ct, cairo_font_t *font); I personally think that only one of the above schemes should be required at the driver-level (possible ?). > void > cairo_show_text (cairo_t *ct, const unsigned char *utf8); > > void > cairo_text_extents (cairo_t *ct, > const unsigned char *utf8, > double *x, double *y, > double *width, double *height, > double *dx, double *dy); This function, along with the "current*" functions, shouldn't be expected from all drivers, making it possible to have "write-only" drivers (PostScript, PDF, etc.). Actually it looks like it belongs to high-level layout, not the rendering part of the API, maybe it should be provided in the "object-oriented" CairoFont interface only. > typedef struct cairo_glyph { > cairo_font_t *font; > FT_UInt id; > double x; > double y; > } cairo_glyph_t; I'd suggest to strip "font", make id a uint32 or even uint, and get rid of the struct. > void > cairo_show_glyphs (cairo_t *ct, cairo_glyph_t *glyphs, int num_glyphs); void cairo_show_glyphs (CAIRO_ARG, uint*, double*, int num_glyphs); > > void > cairo_text_path (cairo_t *ct, const unsigned char *utf8); driver-level yes/no ? > void > cairo_glyph_path (cairo_t *ct, cairo_glyph_t *glyphs, int num_glyphs); > > /* XXX: Does anyone really need a cairo_glyph_extents function? */ > > Notice that a Freetype datatype is exposed, (and fontconfig is > implicit in that the "name" parameter will be interpreted as a > fontconfig pattern string). That theme continues in the remaining new > cairo_font_t functions. Most of these just exist to let users get at > what they need in order to be able to call fontconfig/Freetype > directly: > > /* Font manipulation */ > > cairo_font_t * Is there any chance to change the naming convection of structs due to popular request at this point (CairoFont) ? How will drivers and the high-level layout layer communicate fonts and font-metrics to match ? Other then that Idon't think Cairo is the right place for a high-level "object-oriented" font API like you propose. (But if the seperation of concerns is done well, it wouldn't hurt, I guess). E.g. I could just use FreeType directly or let Pango use FreeType directly, no need to go through Cairo in the layout phase, right ? [...] > 1) Right now, there are a bunch of "cairo_get_*" functions which is a > gratuitous deviation from the PostScript current* operator > names. The biggest wart is the function "cairo_get_current_point" > which can't make up its mind which convention to follow. And, since > "cairo_get_point" doesn't work, we propose to use > "cairo_current_point" and change all other "cairo_get_*" functions > to "cairo_current_*". So sorry that the function names get > longer. Some of you might need to save up and buy new terminal > emulators with more columns. Nice! But please consider the driver-issue mentioned above. Best regards, kai From cworth at east.isi.edu Wed Jul 30 05:45:28 2003 From: cworth at east.isi.edu (Carl Worth) Date: Mon Aug 15 11:10:45 2005 Subject: [Cairo] Text API proposal In-Reply-To: <200307301432.23548.kai.wetzel1@freenet.de> References: <16165.50450.896068.714551@scream.east.isi.edu> <200307301432.23548.kai.wetzel1@freenet.de> Message-ID: <16167.48616.829594.410011@scream.east.isi.edu> On Jul 30, Kai Wetzel wrote: > That's one of my main itches with the API proposal: What is the > seperation between the low-level drivers' responsibilities and the > "shared", high(er)-level parts of the API That's the big open question right now. The goal of Cairo is to have extremely high fidelity in rendering across many different output devices. Of necessity, this requires Cairo to implement a lot of functionality itself, and have a rather low-level backend interface. At the same time, we're not sure of all the answers at this point, and we'll learn a lot as we actually start implementing more backends. One thing we are doing is not exporting the backend interface, (at least for the time being). This gives a lot more flexibility in adapting the interface as we learn, and it may be that different backends plug in at different levels. > Did you consider adding "display list" support to Cairo ? Not yet. We can certainly look into it. > > void > > cairo_select_font (cairo_t *ct, char *name); > > Where "name" is a Xft pattern including scale/matrix, etc. ? The idea was to use a fontconfig pattern string, yes. The nice thing about this string-based interface is that it provides a lot of flexibility. PostScript, for example, leaves the interpretation of the name as completely implementation dependent. I'd like to make some stronger guarantees about what the user can expect than that, though. > This function, along with the "current*" functions, shouldn't > be expected from all drivers, making it possible to have "write-only" > drivers (PostScript, PDF, etc.). I'm not convinced it will be necessary to have any write-only drivers. Since Cairo provides alpha-blended compositing, and PostScript does not, it will be essential to be able to get the current output state for input to the compositor. Keith's latest idea is to always have a libic-based in-memory buffer being rendered to alongside the PostScript output stream. It would also keep track of the region that has been touched by non-opaque objects. Then, at the time of showpage, it could put the relevant region from the libic surface onto the PostScript output. > How will drivers and the high-level layout layer communicate > fonts and font-metrics to match ? The current proposal is to just directly expose the Freetype API. I'm waiting to see if that plan will meet violent objections or not. > E.g. I could just use FreeType directly or let Pango use FreeType > directly, no need to go through Cairo in the layout phase, right ? That's the idea. -Carl From cworth at east.isi.edu Wed Jul 30 06:03:48 2003 From: cworth at east.isi.edu (Carl Worth) Date: Mon Aug 15 11:10:45 2005 Subject: [Cairo] [patch] implement push/pull on xc surfaces In-Reply-To: <87ptjtukhp.fsf@dub.venge.net> References: <87ptjtukhp.fsf@dub.venge.net> Message-ID: <16167.49716.31543.511914@scream.east.isi.edu> On Jul 29, graydon hoare wrote: > this implements the previously-disabled push and pull functions on xc > surfaces. this allows you to, for example, call cairo_show_surface to > display a local image surface on a remote RENDER surface. Graydon, Thanks for looking into this! As you saw, I had some code lying there, but never had the chance to try fixing it up. Other benefits of having this code working include the ability to transparently use Cairo with X servers without the Render extension. It will also even automatically fall back to using local rendering for unsupported operations when using an X server with an old version of the Render extension, (say today's Debian unstable xfree86 package that doesn't support CompositeTrapezoid request). Plus, the ability to composite two surface of different types, (in-memory image with window), or even from two different X servers, should be fun to play with. I haven't committed this to Xc, but just because my local tree doesn't even use Xc anymore -- it's already been absorbed up into Cairo. My tree builds now, but I'm only getting output on the blue channel for some reason. As soon as I fix that, I'll commit and add this implementation as well. Oh, and with this working, it won't be necessary to have cairo_put_image anymore. Instead, one would just create a cairo_surface_t from the image and use cairo_show_surface. So I'll probably drop cairo_put_image from the interface. -Carl From otaylor at redhat.com Wed Jul 30 07:12:30 2003 From: otaylor at redhat.com (Owen Taylor) Date: Mon Aug 15 11:10:45 2005 Subject: [Cairo] Text API proposal In-Reply-To: <16167.15672.963031.49977@scream.east.isi.edu> References: <1059502241.11802.52.camel@poincare.devel.redhat.com> <16167.15672.963031.49977@scream.east.isi.edu> Message-ID: <1059574350.30221.35.camel@poincare.devel.redhat.com> On Tue, 2003-07-29 at 23:36, Carl Worth wrote: [ I've cc'ed a couple of our Windows developers on this mail; Tor/Hans if you want to see the rest of this thread see http://cairographics.org/pipermail/cairo/2003-July/000273.html The issue here is font support for Cairo; which is likely to be the primary rendering API in future versions of GTK+. I've also Cc'ed fontconfig@fontconfig.org since this mail is largely about fontconfig; sorry for the wide distribution. ] [...] > So, I have two questions: > > fontconfig > ---------- > Does anyone have a problem with Cairo exporting fontconfig as > proposed? fontconfig is quite portable and I, (speaking as a user), > would love to have a standard cross-platform means for naming fonts, > etc. I don't necessarily have a problem with using fontconfig on non-Unix systems, though I do have some concerns. - The set of fonts listed has to follow the system set of fonts pretty much exactly and automatically; any approach that requires separate user configuration of fontconfig isn't going to work. - The end result of fontconfig pattern resolution is currently a filename. This doesn't work on Windows, since you can't use the system font API's with a filename. So, that would need to more flexible. - It's important to be able to go from: system representation of a font [LOGFONT on windows] => fontconfig pattern matching => fontconfig pattern result => rendering And get a result that is consistent with the rendering going through the system directly. Otherwise, things like matching the default system font won't work. - There may be some concerns with interaction with interaction with system rendering API's like Uniscribe and ATSUI - Thorsten may know better there. I think it probably does work out for Uniscribe; in Pango, we already put Pango font matching ahead of Uniscribe. But my understanding of ATSUI is that it is higher level; more "paragraph" based, and it may want to do font matching itself. You could say that you are only using fontconfig for the "toy api"' and leave the low level API open, but the idea of requiring fontconfig for GTK+ on win32, then not using it, isn't all that attractive... > Freetype > -------- > Does anyone have concrete suggestions for what API to push down into > Cairo in order to abstract away Freetype? If someone smart can > convince me to do that, and tell me how, I might be able to overcome > my laziness. My suggestion is that you don't try to "abstract away FreeType" but rather you allow a font-system specific implementation of the Cairo toy API, which is going to be a much, much smaller API. The list of operations that I gave in my previous mail was meant to be (approximately) complete. For the toy API, you need: - Load a font from a name - Convert Unicode text to glyphs And for the real API, you need: - Scale/Apply a transformation matrix to a font - Render a glyph to a bitmap - Add a glyph to a cairo path And that's all Cairo needs to know about the font system. > Or, another option is to give in to my laziness, not invent a new > interface, but declare that the Freetype API is good as is. With that, > we would just require the abstraction to happen below Cairo. That is, > if someone wants to use a non-Freetype renderer below Cairo, they > would have to write a Freetype-style wrapper above it for Cairo to use > and export. Does that make sense? Do such wrappers perhaps exist > already? No, I don't think that makes sense: - The FreeType API is really large - The FreeType API is quit fluid; there are additions in almost every dot-release of FreeType. - The FreeType API is in not compatible with the font API's on other operating system.. it is far too detailed; the only way to implement the FreeType API on windows would be basically to dump out the contents of each font table and run FreeType on that. Regards, Owen From otaylor at redhat.com Wed Jul 30 07:24:41 2003 From: otaylor at redhat.com (Owen Taylor) Date: Mon Aug 15 11:10:45 2005 Subject: [Cairo] Text API proposal In-Reply-To: References: Message-ID: <1059575080.30221.57.camel@poincare.devel.redhat.com> On Wed, 2003-07-30 at 04:52, Thorsten Behrens wrote: > That sounds reasonable. The only thing we need to use Cairo portably is a > high-level text interface. Do you still think that the proposed Cairo > glyph render API suffices for Windows? As we've said, Uniscribe and glyph > output on Windows are extremely hard to separate. Seems to work for Pango - the code to convert string to positioned glyphs is in: http://cvs.gnome.org/lxr/source/pango/modules/basic/basic-win32.c Then the drawing goes on in http://cvs.gnome.org/lxr/source/pango/pango/pangowin32.c (pango_win32_render()) using ExtTextOutW() and the ETO_GLYPH_INDEX flag. You are basically reimplementing the ScriptTextOut() call of Uniscribe, but I don't think it does anything magic that isn't available to Win32 applications. Regards, Owen From otaylor at redhat.com Wed Jul 30 07:25:49 2003 From: otaylor at redhat.com (Owen Taylor) Date: Mon Aug 15 11:10:45 2005 Subject: [Cairo] Text API proposal In-Reply-To: References: Message-ID: <1059575149.30221.60.camel@poincare.devel.redhat.com> On Wed, 2003-07-30 at 05:06, Thorsten Behrens wrote: > Yesterday, Carl wrote: > > > So, I have two questions: > > > > fontconfig > > ---------- > > Does anyone have a problem with Cairo exporting fontconfig as > > proposed? fontconfig is quite portable and I, (speaking as a user), > > would love to have a standard cross-platform means for naming fonts, > > etc. > > > If I got Owen right, he plans something like that (or what should > CairoWin32Font stand for?). No, that wasn't part of my proposal. In my proposal CairoWin32Font was just an opaque handle that support the generic "CairoFont" operations. > > Freetype > > -------- > > Does anyone have concrete suggestions for what API to push down into > > Cairo in order to abstract away Freetype? If someone smart can > > convince me to do that, and tell me how, I might be able to overcome > > my laziness. > > > No idea about that. How about an API that deals exactly with the > functionality needed by Cairo? Makes porter's life much more easy. > > Generally speaking, I have the impression that we're theorizing here. The > thing Cairo will benefit the most are actual ports to Windows and OSX. I'd definitely agree with that; it's hard to predict all issues in advance. > Only then, potential issues will show up. From what we can tell, the Cairo > glyph interface will not suffice for Windows. If Owen got Pango working > with Uniscribe and a glyph API, all the better (would be interesting, how > broad test coverage for that version has been, though). See my other mail. Regards, Owen From otaylor at redhat.com Wed Jul 30 07:33:10 2003 From: otaylor at redhat.com (Owen Taylor) Date: Mon Aug 15 11:10:45 2005 Subject: [Cairo] Text API proposal In-Reply-To: <16167.45525.400348.33937@scream.east.isi.edu> References: <16167.15672.963031.49977@scream.east.isi.edu> <16167.45525.400348.33937@scream.east.isi.edu> Message-ID: <1059575590.30221.68.camel@poincare.devel.redhat.com> On Wed, 2003-07-30 at 07:53, Carl Worth wrote: > On Jul 30, Thorsten Behrens wrote: > > No idea about that. How about an API that deals exactly with the > > functionality needed by Cairo? Makes porter's life much more easy. > > The problem is that Cairo doesn't need much. It just draws glyphs at > specified locations, and that's pretty easy. > > However, applications that compute the glyph positions are going to > need a lot more information from the backend text engine. Rather than > implementing all of that API in Cairo, I'm currently just passing up > an FT_Face. What I'd like to see is that you abstract things sufficiently so that you pass up a FT_Face on Unix and a LOGFONT (or whatever) on Windows. We already have code in Pango to handle laying out out text for both FT_Face's and LOGFONT's. I'd much rather be able to use that code rather than write new code to lay out text for CairoFonts. And an additional problem with trying to present any sort of font API in Cairo that allows for advanced text layout is one of level mismatch. On Unix, Pango contains code to parse OpenType tables, etc; on Win32 it just calls Uniscribe. So, it's hard to see what the Cairo API that would allow writing "lay out text for CairoFont" would look like. Regards, Owen From cworth at east.isi.edu Wed Jul 30 08:52:21 2003 From: cworth at east.isi.edu (Carl Worth) Date: Mon Aug 15 11:10:45 2005 Subject: [Cairo] libXc is dead Message-ID: <16167.59829.134301.371709@scream.east.isi.edu> I've just committed changes to incorporate all of the functionality from libXc into libcairo. So, Cairo will no longer link against libXc, (and we can all ignore the Xc module from now on). I've also moved the Cairo internals away from most of the X datatypes, (XFixed, XPointFixed, etc.), so it's getting closer to having honest support for multiple backends now. The next task in the backend-rework is to change cairo_surface to call backend-specific functions through function pointers rather than just testing surface->type and calling directly. Then, the X-specific portions of the implementation and header file can be moved into their own files. And that will provide a nice model for dropping in other backend implementations as well. -Carl From rth at twiddle.net Wed Jul 30 10:11:22 2003 From: rth at twiddle.net (Richard Henderson) Date: Mon Aug 15 11:10:45 2005 Subject: [Cairo] slim committed; used by pixregion Message-ID: <20030730171122.GB4571@twiddle.net> I've now committed the contents of the slim module, and have updated libpixregion to use it. My patches for libic and cairo need updating for conflicts. I'll work on those later this evening. r~ From jboulnois at neo-rousseaux.org Wed Jul 30 12:05:36 2003 From: jboulnois at neo-rousseaux.org (jboulnois@neo-rousseaux.org) Date: Mon Aug 15 11:10:45 2005 Subject: [Cairo] vector-engine-0.1 Message-ID: <1059591936.3f281700146d2@webmail.tuxfamily.org> Hi, I finally release a 0.1 version of my gtk2 engine. Gradients (of N colors), round size, line size and more are configurable with the gtkrc file. archive avaible at http://www.neo-rousseaux.org/jboulnois/vector-engine-0.1.tar.gz Please test it and send feedback! Julien Boulnois From vektor at dumbterm.net Wed Jul 30 17:16:23 2003 From: vektor at dumbterm.net (Billy Biggs) Date: Mon Aug 15 11:10:45 2005 Subject: [Cairo] slim committed; used by pixregion In-Reply-To: <20030730171122.GB4571@twiddle.net> References: <20030730171122.GB4571@twiddle.net> Message-ID: <20030731001623.GA719@dumbterm.net> Richard Henderson (rth@twiddle.net): > I've now committed the contents of the slim module, and > have updated libpixregion to use it. You use the visibility attribute for gcc >= 3.2, however here with gcc 3.2.3 the attribute gives a warning. #if (__GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 2)) && defined(__ELF__) #define __internal_linkage __attribute__ ((__visibility__ ("hidden"))) As well, the docs on the gcc site say that the attribute name is 'visibility' not '__visibility__' (neither works with 3.2.3 fwiw). Thoughts? -Billy From rth at twiddle.net Thu Jul 31 01:27:44 2003 From: rth at twiddle.net (Richard Henderson) Date: Mon Aug 15 11:10:45 2005 Subject: [Cairo] slim committed; used by pixregion In-Reply-To: <20030731001623.GA719@dumbterm.net> References: <20030730171122.GB4571@twiddle.net> <20030731001623.GA719@dumbterm.net> Message-ID: <20030731082744.GB6958@twiddle.net> On Wed, Jul 30, 2003 at 07:16:23PM -0500, Billy Biggs wrote: > You use the visibility attribute for gcc >= 3.2, however > here with gcc 3.2.3 the attribute gives a warning. Ah, we must have backported that to 3.2-rhl8. I'll update that test to 3.3, I guess. > As well, the docs on the gcc site say that the attribute > name is 'visibility' not '__visibility__' ... There's fine print about __foo__ working for all foo. r~ From jboulnois at neo-rousseaux.org Thu Jul 31 09:43:15 2003 From: jboulnois at neo-rousseaux.org (jboulnois@neo-rousseaux.org) Date: Mon Aug 15 11:10:45 2005 Subject: [Cairo] vector-engine-0.2 In-Reply-To: <16168.26522.621282.732026@scream.east.isi.edu> References: <1059591936.3f281700146d2@webmail.tuxfamily.org> <16168.17544.252883.434442@scream.east.isi.edu> <1059605950.3f284dbe35293@webmail.tuxfamily.org> <16168.22953.119602.347669@scream.east.isi.edu> <1059612093.3f2865bd44b34@webmail.tuxfamily.org> <16168.26522.621282.732026@scream.east.isi.edu> Message-ID: <1059669795.3f2947235b0a9@webmail.tuxfamily.org> New version of the vector engine, A lot of improvements and bugfixes, and a new beautiful look for the default vector-theme. archive available at http://www.neo-rousseaux.org/jboulnois/vector-engine-0.2.tar.gz Julien Boulnois From rth at twiddle.net Thu Jul 31 16:40:24 2003 From: rth at twiddle.net (Richard Henderson) Date: Mon Aug 15 11:10:45 2005 Subject: [Cairo] Use __builtin_popcount when available Message-ID: <20030731234024.GA10315@twiddle.net> Ok? r~ * iccolor.c (Ones): Define as __builtin_popcount when available. Index: iccolor.c =================================================================== RCS file: /local/src/CVS/libic/src/iccolor.c,v retrieving revision 1.2 diff -c -p -d -r1.2 iccolor.c *** iccolor.c 31 Jul 2003 17:00:09 -0000 1.2 --- iccolor.c 31 Jul 2003 17:31:16 -0000 *************** *** 25,35 **** #include "icint.h" static int ! Ones(unsigned long mask); ! ! static int ! Ones(unsigned long mask) /* HACKMEM 169 */ { register unsigned long y; --- 25,44 ---- #include "icint.h" + /* GCC 3.4 supports a "population count" builtin, which on many targets is + implemented with a single instruction. There is a fallback definition + in libgcc in case a target does not have one, which should be just as + good as the static function below. */ + #if __GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 4) + # if __INT_MIN__ == 0x7fffffff + # define Ones(mask) __builtin_popcount(mask) + # else + # define Ones(mask) __builtin_popcountl((mask) & 0xffffffff) + # endif + #else + /* Otherwise fall back on HACKMEM 169. */ static int ! Ones(unsigned long mask) { register unsigned long y; *************** Ones(unsigned long mask) *** 37,42 **** --- 46,52 ---- y = mask - y - ((y >>1) & 033333333333); return (((y + (y >> 3)) & 030707070707) % 077); } + #endif void IcColorToPixel (const IcFormat *format, From cworth at east.isi.edu Thu Jul 31 17:16:08 2003 From: cworth at east.isi.edu (Carl Worth) Date: Mon Aug 15 11:10:45 2005 Subject: [Cairo] Use __builtin_popcount when available In-Reply-To: <20030731234024.GA10315@twiddle.net> References: <20030731234024.GA10315@twiddle.net> Message-ID: <16169.45384.940543.31915@scream.east.isi.edu> On Jul 31, Richard Henderson wrote: > * iccolor.c (Ones): Define as __builtin_popcount when > available. Seems fine to me. I'm all for Cairo going faster, (it's not been optimized at all yet). A note to anybody considering digging through and optimizing things: We plan on throwing away the current trapezoid rasterization algorithm, (all of ictrap.c), as we found a bug in its specification. We've got a new algorithm planned and prototyped in nickle -- just need to whip out a C version. So please don't waste time with the current ictrap.c. And while I'm on the topic, when stroking splines, the tessellation into trapezoids is currently O(n^2), but I think it can be done in O(n). If anyone is interested in helping to fix that, just let me know. Other fun processor-specific improvements could be made to the compositing code to take advantage of the extended instruction set of current processors. I know that Billy Biggs is currently looking into that problem. Oh, and more of the RENDER extension could be accelerated within the X drivers... And we might want an OpenGL backend... Lots of fun to be had in the make-it-fast realm. Just be sure to profile first, and be sure we're not about to change the implementation either. ;-) -Carl