Re: Print preview widget
On Thu, 17 Apr 2008 13:15:42 -0400, Behdad Esfahbod wrote: On Thu, 2008-04-17 at 18:07 +0100, Gustavo J. A. M. Carneiro wrote: +1 too. Though opening the actual generated PDF in evince is always going to be a more reliable preview than rendering to a widget. There always will be bugs here and there, you know... ... Because as I said, There always will be bugs here and there. I think the always in Behdad's there always will be bugs is much stronger than in his [using evince] is always going to be a more reliable preview. You could claim quite the reverse. If print preview does not go through App-Cairo-PDF-Cairo-Screen layers (would be only App-Cairo-Screen), then users will not catch PDF/PS generation bugs so soon, they only see the bugs appear on paper, and then it will be convoluted by printer driver bugs, etc. That's what I meant. Right. We do get to test more layers by doing the full round-trip. And I also agree that's a good thing. Interestingly, though, some of those layers can show bugs that are unique to this preview environment. So here's at least one concrete example where doing preview this way is actually less reliable. I can write a program where both of these are correct: Display to screen: App-Cairo-Screen Print to PDF: App-Cairo-PDF But the following is totally broken: Print preview: App-Cairo-PDF-Cairo-Screen And that's simply because there are bugs in poppler, which does the PDF-Cairo step, and poppler isn't actually involved in either the display-to-screen or print-to-pdf scenarios. That's not to single out poppler. There are certainly bugs in any of the stages, (App-Cairo, Cairo-Screen, or Cairo-PDF). And we definitely need to just use this full-round-trip process and make it as bomb-proof as possible. And we do do that kind of round-trip testing within cairo's test suite, and it does find poppler bugs in the PDF-Cairo stage. Here's our tracking bug that shows what issues we've found so far: Poppler does not yet handle everything in the cairo test suite https://bugs.freedesktop.org/show_bug.cgi?id=12143 Any help on fixing those will be greatly appreciated of course, (and will make any poppler-based print preview much more reliable). -Carl pgpOniaRfwYyG.pgp Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Suggested even/odd convention for the micro version numbers (like cairo)
On Tue, 11 Dec 2007 21:22:32 +0100, Jürg Billeter wrote: On Tue, 2007-12-11 at 13:08 -0600, Shaun McCance wrote: The problem I see with the proposed scheme is that we can't fit step (e) into it, since 2.12.2 is never in SVN. With our current scheme, you can do this: ... The cairo repository shows that also the even release version is committed and this commit is then tagged. Since cairo also uses git, we do the bump; tag; bump sequence as local commits that are pushed atomically. So the released version is available in the history and can be checked out by its tag. But at no point will someone that is tracking the head of development get a build that results in an even-numbered version. I do regard the approach as quite successful for cairo, for what that's worth. -Carl pgp34P4AGzTOE.pgp Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GDK-DirectFB Patches
On Thu, 06 Dec 2007 09:44:55 +0100, Denis Oliver Kropp wrote: Carl Worth wrote: For interleaving cairo and non-cairo rendering, cairo provides the cairo_surface_flush and cairo_surface_mark_dirty APIs. Does cairo-directfb implement those and does your application use them. Thanks for the pointer. The cairo-directfb backend seems to do nothing in these functions. I'm not sure what it's supposed to do. Should the first accumulate a region to flip and the second actually flips? I don't know how cairo-directfb surface is implemented exactly. So I'll describe the general concepts and then illustrate them by way of a fictitious shadow backend that is implemented with a cairo-image-surface internally and can copy back and forth between that and some underlying system object. When an application wants to switch from cairo- to non-cairo-based drawing it should call cairo_surface_flush. In this case, our shadow backend would copy its state from the image surface to the underlying system. (Ideally it would copy a minimal region based on the extents of cairo drawing operations that have occurred, but cairo's current backend interfaces don't make it easy to know this. But there would be no API impact from improving that.) Then, when an application wants to switch back from non-cairo- to cairo-based drawing it should call cairo_surface_mark_dirty_rectangle one or more times. Our shadow backend would accumulate a region from these rectangles and before the next cairo drawing operation would copy that region from the system to the image surface. Does that make sense? -Carl pgpEcrygSGOra.pgp Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GDK-DirectFB Patches
On Thu, 06 Dec 2007 21:52:08 +0100, Denis Oliver Kropp wrote: I'd also like to see that revived: * @CAIRO_FORMAT_RGB16_565: This format value is deprecated. It has * never been properly implemented in cairo and should not be used * by applications. (since 1.2) Embedded devices running at 16bit should be able to use Cairo without converting back and forth. This is on the todo list for the current cairo development working toward a 1.6 release. Any help would definitely be appreciated. -Carl pgpcX8QHWamDV.pgp Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GDK-DirectFB Patches
On Wed, 05 Dec 2007 11:09:33 +0100, Denis Oliver Kropp wrote: CAIRO-DIRECTFB: Use DirectFB for show_glyphs() even if it is unaccelerated. The software fallback in DirectFB is well optimized. Hi Denis, I'm inclined to let anyone who wants to maintain cairo-directfb-surface.c do whatever they feel is best to it. But could you please send proposed patches to the cairo mailing list? There are probably cairo-directfb maintainers there that will want to review this. -#if DFB_SHOW_GLYPHS +#if DFB_SHOW_GLYPHS 0 if (!(dsc.acceleration_mask DFXL_BLIT)|| !(dsc.blitting_flags DSBLIT_COLORIZE) || !(dsc.blitting_flags DSBLIT_BLEND_ALPHACHANNEL)) Why leave this code around? If it's truly not wanted, it would be cleaner to remove it. -Carl pgp1ZGRTW2Mp4.pgp Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GDK-DirectFB Patches
On Wed, 5 Dec 2007 10:22:08 -0800, Mike Emmel wrote: Hi Carl Claudio one of the main directfb developers has a lot of cairo patches setting on the directfb git server. One can you give him check-in rights for Cairo. Here's the process to ask for that (ignore the CVS in the title, of course): http://freedesktop.org/wiki/AccountRequests I'd feel fine for Claudio to directly push anything that touches only cairo-directfb-surface.c. Patches that touch other files in cairo should be sent to the cairo mailing list first. Especially API additions must be discussed on the list first, (even cairo-directfb-specific API additions). And next we need to make sure that we are not breaking gdk. One approach may mean to pass in a features arg when initializing Cairo. It could be a simple bool accel or no acceleration. I'm not interested in anything like that at all. If it's not correct, then it's not acceleration---it's just broken. For the secondary ports its not easy to do comprehensive testing so I think its useful. What's the difficulty of testing cairo-directfb within cairo's test suite? -Carl pgpUuX0QdyNtE.pgp Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: CairoIO - Cairo compatible successor to GdkPixbuf
On Fri, 16 Nov 2007 14:04:45 +0100, =?ISO-8859-1?Q?BJ=F6rn_Lindqvist?= wrote:
surface = cairoio.load('foobar.png')
if surface.get_format() in (cairo.FORMAT_ARGB32,):
is equivalent with:
pixbuf = gdk.pixbuf_new_from_file('foobar.png')
if pixbuf.get_has_alpha():
Actually, better cairo code would be:
if surface.get_content() == cairo.CONTENT_COLOR_ALPHA:
Cairo currently only supports one alpha format which is FORMAT_ARGB32
(FORMAT_A8 and FORMAT_A1 doesn't count), but might support more in
the future.
The code I presented will be robust against future additions of
color-and-alpha-supporting image formats.
Another thought that occurs to me is that you should think about how
to support fast loading of image data directly into cairo surfaces
other than cairo-image surfaces, (for example a cairo-xlib surface).
There's been recent discussion on the cairo mailing list about adding
API to support this well, (for example, allowing XShm transport), and
it might be very nice if you could provide some feedback on that. Let
me know if you need a specific pointer to the thread(s).
-Carl
pgpQFpUbuM9TU.pgp
Description: PGP signature
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GdkPixbuf vs. Cairo, new image library needed?
On Sat, 13 Oct 2007 00:51:44 +, =?ISO-8859-1?Q?BJ=F6rn_Lindqvist?= wrote: I have played around with Cairo some more and it seems to me that it is not fully ready yet. :( Cairo blits and scales much slower than gdk-pixbuf (software that is) Do you have some simple test cases to demonstrate this so we can identify and fix anything necessary in cairo? and doesn't support as good-looking bilinear filtering that gdk-pixbuf does. The scaling code in cairo, (for downscaling by factors greater than 2), could definitely use some improvement, (the current result is embarrassingly ugly). But what GdkPixbuf does here is actively bad for performance. I'd like to see some middle-ground implementation. -Carl pgpOyJMQZALH8.pgp Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk+ configure can't find cairo-pdf
On Fri, 08 Jun 2007 21:15:34 +, rahed wrote: checking cairo-pdf.h usability... no checking cairo-pdf.h presence... no checking for cairo-pdf.h... no configure: error: *** Can't find cairo-pdf.h. You must build Cairo with the pdf *** backend enabled. You should be able to look at config.log to see details on why the header files aren't being found, (it's probably looking in the wrong place). The cairo-pdf.h file is indeed in /c/gtksource/include/cairo. Does anyone see what's wrong? Does your PKG_CONFIG_PATH variable include the directory containing cairo-pdf.pc? (probably /c/gtksource/lib/pkgconfig). -Carl pgp32rtmc1KjI.pgp Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Some comments about GVFS
On Fri, 04 May 2007 10:27:34 -0400, Havoc Pennington wrote: It's a run-time env variable. I think we don't advertise it at all, it's more of a defense against people who have strong views on the topic and prefer undefined behavior probably a crash to just exit ... And one thing to note here is that cairo does provide an additional option: No behavior, will not crash which I think can form a good compromise between the camps that prefer each of the options you mention. (Though I'll agree that debugging would be easier if cairo _also_ provided a run-time mechanism to get the just exit along with an error message giving as much context as possible for the time of the error.) The point is, while it might not make sense to talk about error recovery from any single low-level library operation, (see your failed to draw a rectangle example), applications still will very much want to have high-level behavior of something has gone very wrong, let's save the user's important state before exiting. There are a few things a library could do that would defeat that almost entirely: 1. Exit 2. Start doing undefined things 3. Require error-checks on every call into the library to prevent it from doing undefined things You seem to be saying that it's impractical for a library to avoid 2 or 3, so there's no reason not to do 1. But I think with cairo we've got a practical approach for getting close enough to avoiding all three so that applications really can do high-level error recovery. And that seems useful. When I first implemented this it found quite a few bugs, I then implemented something similar for part of libxml and also found a lot, so that's why my party line since has been that trying to handle OOM without testing the OOM codepaths is more hopeful fantasy than anything else. I absolutely agree that testing is essential, and out-of-memory handling is doomed without it. And now that we've fixed so much in cairo, we really want to go fix underlying libraries like fontconfig and freetype or else it's really all in vain. (it's just too hard to get right without testing - in some cases in dbus-daemon I had to implement fairly complex transactions that could be rolled back, in other cases I had to change the library API to allow e.g. callbacks to signal OOM) When we started testing cairo, we found several mistakes, (though fewer than I had anticipated to tell the truth). But we've had nothing come even close to needing any API changes. Part of that is certainly due to cairo's problem domain where there aren't a lot of complex interactions between separate operations, (can anyone imagine transactions being useful when drawing?). But another part comes from just accepting support for OOM-error- handling as an upfront design constraint, rather than hoping to bolt it on later. -Carl pgpDjQ9MQtXgn.pgp Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Some comments about GVFS
On Thu, 3 May 2007 11:11:39 +0200, Benjamin Otte wrote:
I much prefer the cairo model, where basically the
object keeps its own GError and has a function like cairo_status [3]
that gives you the last error that occured.
It's worth pointing out an additional aspect of the cairo
error-handling model: The object becomes entirely inert as soon as an
error occurs within it. That is, all methods of the object first check
the status and return immediately on error.
That part of the model is essential for the application code to be
able to benefit by deferring error-checking to a convenient time.
-Carl
PS. After I wrote that much I also wrote the following rambling
treatise on the model. I didn't have time to make it shorter, so feel
free to delete it. (I almost deleted it myself, but I think someone
might find it useful).
I think the model is extremely successful in that it actually becomes
practical to write correct programs. We started with the assumption
that programmers rarely include all the necessary checks to make their
program correct, so we decided to make the program correct without all
of those checks.
And that means that the correct program can remain readable---there's
a lot less clutter without from error-checking paths. I love the fact
that code samples in the documentation of the library don't need those
often-seen disclaimers, error-checking code removed for readability.
Another great benefit is that compiler features such as
attribute(warn_unused_result) can actually become feasible to use,
(that is, it doesn't result in a bunch of false-positive noise).
For example, in cairo's core API of about 200 functions, there are
less than 15 that can return an error status indication, (not counting
the calls where the user is explicitly asking for a status value). All
other functions are either void or are returning a value that is of
direct interest to the caller, (such as a constructor or a get
function). So, from the calling convention, it's obvious to the user
that the great majority of the time there's no further error-checking
required. And, in the few functions that _do_ return an error status,
it's actually very important for the user to check those, (and
something like the warn_unused_result attribute can be quite helpful
for this).
One thing that can be get trickier with this model is tracking down
what actually caused the error once it is detected. While it's
convenient to be able to defer the error checking, this also means
that detection of the error becomes separated in time and code from
when the error was committed. (With the old approach there is often
unintended deferral due to missing error-checks, but hopefully the
user gets lucky and a crash happens soon after the error. But the
inert stuff described above prevents this.)
So, to successfully adopt this model, the user really needs to be
provided with some means for getting early reports about detected
errors. Cairo is quite conservative about this, providing only a
function that can be set as a breakpoint for when an error is
detected---and that's probably not quite as much help as will be
desired in many cases. Within a glib world there should be no
compunction in spewing messages or allowing applications to register a
callback for when errors are detected by the library.
Also, another subtle issue is that application code can be incorrect
if it depends on side-effects of library calls that will not always
happen in the face of inert methods. For example, imagine some
fictitious code that looks like this:
while (collection_has_more_items (collection)) {
...
collection_remove_item (collection);
}
...
/* Finally check status of collection here. */
if (collection_has_error (collection))
handle_error();
If collection_remove_item could become inert, then the implicit
side-effect of reducing the return-value of collection_has_more_items
would be violated, and the application code would result in an
infinite loop.
So this would be a situation where the inert-object style would not
help at all. Writing a correct program in this case would be more
difficult, (the user would have to anticipate the problem and add an
extra call to check for errors within the loop), than if the
remove_item call directly returned an error indication, (letting the
user know it is important to check for that error).
For cairo, we largely get to ignore this issue, simply because the
side-effects of cairo operations, (drawing operations), rarely have
such a direct impact on a program's control flow.
So that's something else to keep in mind if considering this style.
Finally, cairo also avoids returning NULL from failed object-creation
functions. (The idea being to return a non-NULL object that can
indicate what type of failure occurred.) I don't know that that aspect
has been entirely successful. The application code ends up wanting to
Re: Some comments about GVFS
On Thu, 03 May 2007 14:11:02 -0400, Havoc Pennington wrote: Yeah, I think this keeps the Cairo model from being fully general - it only works for some types of operations or objects. Sure. If you want the object to remain usable after an error, then it shouldn't shut down. And note that that with cairo, we do have functions that do return an error indication instead of shutting down, (cairo_surface_write_to_png, for example). So I think a fair characterization of the cairo model is that it recognizes that you don't always do the shutdown-on-error thing, but it is darn handy when it's the right thing to do. Another thing about the Cairo model is that it's either weird or possibly broken if an object is used by multiple threads, which could arise in the current gvfs presumably. For cairo, at least, there's nothing broken here. If you want to use the same object from multiple threads, then you need to be doing your own locking. As for weird, the shutdown thing should only be happening if there's really no other appropriate response. There's a difference between causing an error _in_ an object, (in which case it will shutdown, and it's appropriate for it to be shutdown for all threads), as opposed to causing an error _with_ an object, (in which case it should just return the error indication and not shutdown). Another thing that's needed for gvfs for sure but not for Cairo perhaps is the error message. The model of lodging errors inside the objects doesn't prevent you from putting as detailed a message in their as you'd like. With cairo itself, we don't actually store anything more than an enum, but... 8859-1), but nonetheless in a lot of cases I think a detailed error can be better than a strerror-style string. Sometimes the error will be user-helpful, e.g. You aren't allowed to save to directory Foo ... even with the very strerror-style approach that cairo encourages, it's very easy for the calling application to add context like this when generating its error message. Returning *helpful* errors, even if only to programmers and techies, also frequently depends on context - meaning, the error can be more helpful if it's checked right away after every call. Sure. So everytime you want to emit a useful error message, check the status and generate the message with all the context you want. Or, like I said above, you could envision applying the cairo model and also adding a string to it. (That is, if applying the cairo model pushes the GError from a parameter to every function to instead be a field within the object, that doesn't mean that GErrror needs to become any less capable). Finally, Cairo of course mixes programmer errors (g_return_if_fail in GLib-world) with should-be-reported errors (GError in GLib-world) with unavoidable-and-should-be-ignored errors (just get ignored in GLib-world). See GError docs for how these are separated in GLib: http://developer.gnome.org/doc/API/2.2/glib/glib-Error-Reporting.html I definitely agree with you that there are different classes of errors and they require different kinds of handling. And I won't argue that cairo gets all of this right yet. (In a very real sense I've always felt that cairo's error-handling strategy was a big experiment, and it would be interesting to see how it played out. So I'm quite glad to see this discussion happening around it.) In the meantime, it's not clear to me that either cairo or glib has this all figured out yet. For example, the document above says: First and foremost: GError should only be used to report recoverable runtime errors, never to report programming errors. If the programmer has screwed up, then you should use g_warning(), g_return_if_fail(), g_assert(), g_error(), or some similar facility. For that second sentence, if we're talking about a non-recoverable programmer error, then what guidance is there for choosing g_return_if_fail as opposed to g_assert? Are programmer errors actually divided into two classes? I could imagine a consistent argument that all programmer errors should lead to an abort, (to force errors to get noticed and dealt with early). And I could accept that some people would want to configure the abort away as well, (which G_DISABLE_ASSERT allows for example). So I could imagine a consistent argument that g_assert should be used for all detected programmer errors. But how does g_return_if_fail fit into your model? Isn't it really doing basically the same thing as cairo's inert object functions? Differences I see are that: 1. g_return_if_fail prints a message 2. cairo's inert objects come with a guarantee that once an object shuts down, no future call to that object will have any effect. For me when using Cairo drawing I would say should-be-reported errors aren't really possible. When the problem is that I passed nonsense to a Cairo API,
Re: Some comments about GVFS
On Thu, 03 May 2007 15:41:43 -0400, Havoc Pennington wrote: I'd be for that in the case that the API has a required ending call, the equivalent of close(). Then you can force error checking on that last call with a GError or warn_if_unused approach and in theory people could skip the intermediate error checks. That makes sense. Yes, forcing the user to check the return value when finished with the object is definitely a good idea. Aside for the public error-handling strategy, we've been adopting the same shutdown-on-error approach internally within cairo bit-by-bit. And as we do that, we really need to propagate errors from one object to another. And we've found that forcing a check when disposing of an object is a good way to help us not forget that. We've wondered whether we can change cairo_destroy from void to cair I'm not sure there are unavoidable-and-ignorable errors. To me anything that could happen to cairo_t is probably in this category... what am I going to do if I draw a rectangle and it fails? Well, for draw a rectangle, cairo basically says that that can never fail, (if you look at the X interfaces we get, there's no other option). So I think that's an error case that really doesn't exist, as opposed to something that's unavoidable and ignorable. Just look at cairo_status_t---there's nothing like the requested drawing operation didn't happen there. really have no idea what kind of recovery code I'd write for that. Certainly nobody is writing such code that I've seen. I don't even know where the error check would go - in every widget's expose handler? In the toplevel event loop? As you said before, at the very least at the required ending call, (which is cairo_destroy in this case), you should definitely be checking this error. Is there anything that could happen to cairo_t in this category? I don't know. I'm mostly assuming there is because I have no idea what the cairo_t error state is for otherwise ;-) (other than as an internal make everything a noop flag) My guess is that out of memory (on client side or X server side) is in this category in cairo, it silently doesn't draw if OOM occurs, no? There's certainly not a large class of errors that can happen while drawing, (yes, out of memory is one). But the other way you can get an error lodged into a cairo_t is via propagation from some other object. So, if you forget to check a cairo_surface_t's status, (say it's FILE_NOT_FOUND), and then you do cairo_create(surface) then the FILE_NOT_FOUND status will propagate into the cairo_t. It would have been kind of nice if GTK+ were creating the cairo_t for the expose handler and then also checking the status, and printing that message. But that's not how GTK+ integrates with cairo---oh, well. And, no, getting a FILE_NOT_FOUND status on a cairo_t is not going to give you a meaningful error message. And no, I wouldn't think it would be sane for anyone to right code to handle a FILE_NOT_FOUND status from a cairo_t. But it might actually give enough of a hint to help you know where to look, (or else just go and get a _cairo_error-induced stack trace). And, yes, when you find the cairo_image_surface_create_from_png call that's failing, (and was missing any errro checking), you should add code there to print a meaningful error message. As long as the individual calls failing don't affect control flow, there's some close() call that reminds you to grab the error, and the errors are interesting/recoverable in the first place, I agree this is nice. That sounds quite reasonable to me. I don't think everyone will agree on which errors are or are not interesting. And I don't think it hurts at all to be able to fetch an uninteresting status value from an object, (see my example above of cairo_t reporting a FILE_NOT_FOUND status). -Carl pgpAjmYycGVjS.pgp Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkCanvas requirements?
On Tue, 24 Apr 2007 00:19:08 +0100, Damon Chaplin wrote: On Mon, 2007-04-23 at 20:09 +0100, Emmanuele Bassi wrote: floats. in Clutter, for instance, most of the operations are done using fixed point algebra and transforming doubles in the public API into 16.16 or 21.11 fixed point numbers internally; That's a similar approach as has been used in cairo very successfully. we also expose a fixed point API to avoid using doubles altogether. is this hard? yes. As a datapoint, cairo does not do this. cairo and pango developers and contributors went all the lengths to reduce the floating point usage in their libraries; we shouldn't screw the developers on embedded devices *again*. But the cairo API already uses doubles, for coordinates and transformations. So if the canvas used fixed point numbers you'd be converting to doubles and then back again. Some people have misunderstood what kinds of optimizations happened in cairo. Cairo has always had a floating-point API, with an implementation that tries to get to fixed-point as quickly as possible. There were several performance problems that were fixed between the 1.2 and 1.4 releases of cairo that involved the following: * Using clever techniques to make the conversion of floating-point to fixed-point values as fast as possible. * Using similar techniques to make the rounding of floating-point values to integers as fast as possible. * Avoiding floating-point arithmetic where the result was unchanged, (multiplying by an identity matrix, for example). At this point, cairo seems plenty fast on embedded systems for the kinds of things that people are throwing at it. Now, some of that speed comes from simply not doing some of the scaling and transformation that might be desired, (see the identity transformation optimization mentioned above). But even if more scaling and rotation were desired, there would be plenty of ways to optimize this, (using fixed-point arithmetic when the scaling is small enough to avoid overflow, using fast integer techniques for computing things like square roots, etc.). And all of that could be done without ever adding any fixed-point API to cairo. I'm quite convinced that using floating-point at the interface, and fixed-point internally as needed provides the right combination of performance and ease-of-use for cairo. I'd highly recommend any new canvas interfaces being proposed follow the same approach. -Carl pgpzlnZ1k131g.pgp Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_get_user_config_dir leaks memory ?
On Mon, 26 Mar 2007 19:19:22 -0600, Hans Petter Jansson wrote:
Also, the last time I checked, valgrind would only let you suppress
messages about invalid accesses, not leaked memory.
No, it definitely allows suppressions for leaked memory, via a
Memcheck:Leak suppression entry. I've included an example below from
what cairo is using to ignore still-reachable memory from Xrm.
But you should be able to easily get exactly what you want from
valgrind with its --gen-suppressions=yes option.
-Carl
{
XrmGetStringDatabase is fairly obnoxious about leaving reachable memory
around
Memcheck:Leak
fun:malloc
fun:PutEntry
fun:GetDatabase
fun:XrmGetStringDatabase
}
pgpdGfIgnjicw.pgp
Description: PGP signature
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Speeding up stroking of dashed rectangles (was: ideas on improving the performance of gtk_tree_view)
On Tue, 27 Mar 2007 17:50:08 +0200, Nicolas Setton wrote: Interesting, the dashed stroke is exactly what's causing problems - thanks for the pointer! Ah, ... though I *think* it has been adressed since. But if you are running 1.4, that would hint that it still is a problem. There have been great advances in cairo performance lately, unfortunately this one might have been overlooked. I'll investigate further. It hasn't been overlooked, per se. But we know it hasn't been addressed yet. The mention I made of it before, (from GUADEC last year), was with respect to a synthetic benchmark that just drew a single big, focused button over and over again as fast as it could. And that example showed quite clearly that post-cairo GTK+ drew that button much more slowly than pre-cairo GTK+, (and it is definitely the dashed stroke that is causing the problem). What hadn't ever been made clear is if real-world applications were seeing performance problems caused by the dashed stroking. It sounds like maybe you're on to one of those now. Indeed. Just subscribed to that list. In order to avoid confusing everyone, I'll stay on this list for now, and might open future topics on performance-list (or on the cairo list, if I can make myself useful there). I'm on all three of the lists, and I'd be glad to continue the discussion wherever you see fit. Within cairo, for example, there's a custom _cairo_path_fixed_stroke_rectilinear function that would be the ideal place to throw in support for really fast dashing. And I don't think it would even be a huge amount of work to fix that to support the kinds of dashing used in the focus rectangle here. One thing you could do that might be very useful would be to go into that function in cairo and remove the following two lines: if (stroke_style-dash) return CAIRO_INT_STATUS_UNSUPPORTED; After you do that, the results won't be correct, (the focus rectangle will come out solid instead of dashed), but it should give you a feeling of the upper-bound of the performance benefit you could expect from adding dash support to this function, (and also confirm if the dashed stroking is the cause of the problems you're seeing). And if so, then yes, the cairo list might be the best place to continue the discussion. In fact, I just decided to pull that list in with this reply. Please feel free to drop gtk-devel-list from future replies if we just keep talking about cairo's dashed stroking code. -Carl pgpZJ7qQMwjR4.pgp Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk+ unit tests (brainstorming)
On Tue, 31 Oct 2006 10:26:41 -0800, Carl Worth wrote: On Tue, 31 Oct 2006 15:26:35 +0100 (CET), Tim Janik wrote: i.e. using averaging, your numbers include uninteresting outliers that can result from scheduling artefacts (like measuring a whole second for copying a single pixel), and they hide the interesting information, which is the fastest possible performance encountered for your test code. If computing an average, it's obviously very important to eliminate the slow outliers, because they will otherwise skew it radically. What cairo-perf is currently doing for outliers is really cheesy, (ignoring a fixed percentage of the slowest results). One thing I started on was to do adaptive identification of outliers based on the Q3 + 1.5 * IQR rule as discussed here: http://en.wikipedia.org/wiki/Outlier For reference (or curiosity), in cairo's performance suite, I've now changed the cairo-perf program, (which does show me the performance for the current cairo revision), to report minimum (and median) times and it does do the adaptive outlier detection mentioned above. But when I take two of these reports generated separately and compare them, I'm still seeing more noise than I'd like to see, (things like a 40% change when I _know_ that nothing in that area has changed). I think one problem that is happening here is that even though we're doing many iterations for any given test, we're doing them all right together so some system-wide condition might affect all of them and get captured in the summary. So I've now taken a new approach which is working much better. What I'm doing now for cairo-perf-diff which does show me the performance difference between two different revisions of cairo is to save the raw timing for every iteration of every test. Then, statistics are generated only just before the comparison. This makes it easy to go back and append additional data if some of the results look off. This has several advantages: * I can append more data only for tests where the results look bad, so that's much faster. * I can run fewer iterations in the first place, since I'll be appending more later as needed. This makes the whole process much faster. * Appending data later means that I'm temporally separating runs for the same test and library version, so I'm more immune to random system-wide disturbances. * Also, when re-running the suite with only a small subset of the tests, the two versions of the library are compared at very close to the same time, so system-wide changes are less likely to make a difference in the result. I'm really happy with the net result now. I don't even bother worrying about not using my laptop while the performance suite is running anymore, since it's quick and easy to correct problems later. And when I see the results, if some of the results looks funny, I re-run just those tests, and sure enough the goofy stuff just disappears, (validating my assumption that it was bogus), or it sticks around no matter how many times I re-run it, (leading me to investigate and learn about some unexpected performance impact). And it caches all of those timing samples so it doesn't have to rebuild or re-run the suite to compare against something it has seen before, (the fact that git has hashes just sitting there for the content of every directory made this easy and totally free). The interface looks like this: # What's the performance impact of the latest commit? cairo-perf-diff HEAD # How has performance changed from 1.2.0 to 1.2.6? from 1.2.6 to now? cairo-perf-diff 1.2.0 1.2.6 cairo-perf-diff 1.2.6 HEAD # As above, but force a re-run even though there's cached data: cairo-perf-diff -f 1.2.6 HEAD # As above, but only re-run the named tests: cairo-perf-diff -f 1.2.6 HEAD -- stroke fill The same ideas could be implemented with any library performance suite, and with pretty much any revision control system. It is handy that git makes it easy to easily name ranges of commits. So, if I wanted a commit-by-commit report of every change that is unique to some branch, (let's say, whats on HEAD since 1.2 split off), I could do something like this: for rev in $(git rev-list 1.2.6..HEAD); do cairo-perf-diff rev done -Carl PS. Yes, it is embarrassing that no matter what the topic I end up plugging git eventually. pgpLSYQbeXKNI.pgp Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Why are people sticking with GTK+ 26.? (Re: GTK+ modularization)
On Mon, 17 Jul 2006 13:58:41 -0700, Jesse Donaldson wrote: We're still using v2.6, so folks may not care, but I'm happy to share our results (once we've obtained them). Also, if he'd like, I can try to put Mathias in touch with whoever will be looking at this on our end. I'm personally interested in hearing more details about what your motivation for sticking with 2.6 is. If it's performance concerns, (as is the case with others I've talked to), then I should point out that I'm personally very interested, and planning on fixing those performance problems. There's no good reason that GTK+ should have ever gotten slower. So I'll be working to fix performance regressions. But I need help identifying them. So anything anyone can share about things they have hit would be useful. (And thanks to those who have already started identifying things here on this list.) -Carl -- [EMAIL PROTECTED] pgpaYZjS9P4ho.pgp Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: composite or render support in gtk
On Wed, 05 Jul 2006 17:13:20 -0300, Carlos Eduardo Rodrigues Diógenes wrote: There is any plan about wrapping composite or render in gtk? The X Render library provides a very low-level way of drawing things in X. A higher-level library that builds on Render, (or other systems), and actually designed to be used by application authors to draw things is the cairo graphics library. As of GTK+ 2.8, GTK+ provides easy access to draw with cairo via functions such as gdk_cairo_create. If there's something that Render allows that you're not able to do with cairo, then I would be interested in hearing about that. As for Composite, I'm not sure what kind of wrapping you are imagining would be appropriate for GTK+. -Carl pgpc4aWY6mZJM.pgp Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [cairo] Hit detect surface?
On Tue, 28 Feb 2006 14:07:12 -0800, Bill Spitzak wrote: 4. All attempts to modify the one pixel do the callback function, giving it the source color, the mask, and the op used, and possibly other information. If we were going to do that, then we might as well specify the drawing operation being performed, (paint, mask, stroke, fill, or show_glyphs). And then we might as well specify the operation-specific parameters, (path, fill rules, stroke parameters, etc.). And at that point, we'd have support for new backends to be implemented outside of cairo. This is something that I've always been willing to consider adding, but I wanted to wait until we felt very good about the backend interface. Delaying this has proven valuable as we have basically two sets of backend interfaces in cairo right now, (the old one with lots of junk, and the new one with little more than paint, mask, stroke, fill, and show_glyphs). The other prerequisite I've put before exporting a backend interface is that we must have good printing support, (that is, cairo 1.2 at least must be out the door). If we've got a backend interface that can handle X, Win32, OpenGL, as well as PS and PDF quite well, then I think we'll be able to feel confident about exporting it. Then, with an exported backend interface, the only other thing that this proposed new hit detect surface would require is aggressive culling of drawing operations that are outside the current clip region. (This is so that the hit detect surface could just set a clip and know it wouldn't see anything outside its region of interest.) At that point, it would be easy to implement this hit detect surface, as well as any number of other kinds of ways to analyze rendering code without having to instrument that rendering code at all. And that would be a powerful thing to be able to do. I'm not sure when exactly it should do the callback function. This is a tricky kind of question to answer. The approach I've outlined above would allow the application to answer it in any way appropriate. -Carl pgpi1JEzgMS4W.pgp Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [cairo] Hit detect surface?
On Wed, 01 Mar 2006 11:27:38 +0100, David Trallero Mena wrote: render everything again there. This new surface I use I refer to as select surface (hit-surface for you). The color used when re-rendering is indeed and ID (I have to talk with cairo guys about this) of the figure (rectangle, ellipse, circle...) that was rendered on the original-surface. You found us cairo guys. What questions do you have? As for this technique. To use it, one would want to ensure that no colors appeared in the output other than the id colors. It's possible to get that with cairo by using CAIRO_ANTIALIAS_NONE. But, we don't currently make any strong guarantees about the precise behavior of ANTIALIAS_NONE rendering. So the results might differ by a pixel here or there from what you would might prefer. Taking external events like mouse or joystick-motion or whatever I just have to read in the hit-surface and see the ID to know which element was drawn on that point. In my case the ID means the widgets drawn there, in yours, it can means the structure that contains the figure with the operators and colors used, I think what Bill was trying to get at is a mechanism to define the shapes entirely by the code that uses cairo to render them. Your approach requires a slight modification to the rendering code, (using ID values instead of the colors desired). And the tradeoff there is between how invasive the approaches are to cairo's implementation itself. And as we're talking about picking, there are other techniques that should at least be mentioned. Cairo can determine whether a given point is within a path as stroked or filled with cairo_in_stroke and cairo_in_fill. This is much more precise than anything pixel-oriented such as ANTIALIAS_NONE rendering and examining a pixel. In one sense, cairo_in_stroke/fill is the fundamental operation needed. It's just not very cheap, (each call does all the tessellation of cairo_stroke/fill, but not any rasterization or compositing). So the question just becomes how to optimize the code around this. The ANTIALIAS_NONE rendering with ID colors is a way to get a low-resolution cache of these calls for a set of of priority-encoded shapes. Other techniques for optimizing picking might rely on geometric descriptions of the objects. Bounding boxes would be the simplest such description, but one could get much more elaborate than that for better optimization. The obvious disadvantage of such an approach is having to maintain geometric descriptions separate from the rendering code. But an advantage is that ambiguous picks could easily be detected and drop down to the precision of cairo_in_stroke/cairo_in_fill as needed. Which combination of techniques is best depends a lot on the needs of the application and the data it has available. -Carl PS. When I cross-posted thread like this lands in my inbox, I'll send a single cross-posted reply like this one. After this, be prepared to chase down replies to individual lists if you really care about how I might reply. pgpZ3pIl77pd4.pgp Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [cairo] Re: Notes on cairo/win32
On Fri, 14 Jan 2005 16:39:16 +, J. Ali Harlow wrote: Ah. I had understood that you were pushing for GDI+ because it gives us anti-aliased paths and alpha-composited primitives. If GDI will do what we need then the hardware acceleration, ease of use and familiarity would all seem to be benefits. If the anti-aliased paths and alpha-composited primitives were a good fit for cairo and gave good performance then that might make sense. But if they're just software on top of GDI, then we're better off using our own software on top of GDI. We've already got all those pieces in cairo anyway. -Carl pgpiTBiqldreW.pgp Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
