turning g_assert* into warnings
hey All.
i'd like to propose to turn g_assert and friends like g_assert_not_reached
into warnings instead of errors. i'll give a bit of background before the
details though.
the main reasons we use g_return_if_fail massively throughout the glib and
gtk+ code base is that it catches API misuses verbosely and gives programmers
a chance to fix their code. this could be achieved with either a g_warning
(mourn on stderr) or a g_error (mourn and abort).
the reasons for the default behavior to use g_warning:
a) a warning usually fullfills its purpose, the programmer knows there's
something to fix and can start to trace the root cause.
b) for easy tracing in gdb with backtraces, programmers can use
--g-fatal-warnings to force abort behavior.
c) programs that aren't 100% bug free could possibly trigger these warnings
during production. aborting would take all the end user data with it,
created/modified images, text documents, etc.
issuing just a warnig preserves the possibility to still save crucial
data if the application logic state still permits (which is most often
the case in practice).
in a recent discussion, i figured that (c) perfectly applies to g_assert
and g_assert_if_reached() also. but we're actually aborting here:
void
g_assert_warning ([...])
{
[...]
abort ();
}
i'd like to change that to:
void
g_assert_warning ([...])
{
[...]
- abort ();
+ if (--g-fatal-warninngs)
+ abort ();
}
for a few reasons:
1) allow users to save their data if still possible; i.e. (c) from above.
2) for glib/gtk+ unit tests (more on that later), failing but
non-aborting tests are interesting for overall report generation; and the
ability to force immediate aborts for debugging is preserved with
--g-fatal-warninngs.
3) assertions can help to document programmer intentions and frequent (but
regulated) use as we have it with g_return_if_fail can significantly
reduce debugging time. i have so far been fairly strict about not adding
assertions to the glib/gtk+ core though, because they also tend to make
the code and end-user experiences more brittle, especially an
occasional wrong assertions that'd have to be revoked upon closer
inspection.
conditionalizing the abort removes the brittleness and allows for
adding more helpful assertion statements.
note that in practice, this shouldn't change anything for programmers
(except for the ability to write better code ;)
because of G_DISABLE_ASSERT, programmers can already not rely on
failing assertions to abort their programs (only g_error will reliably
do that).
it should however take down programs in end user scenarios less often,
and code review can be more lax about adding assertions.
as a side note, it'd probably make sense to present the end users with more
prominent warnings if one of his applications ran into a glib warning/
critical/assertion, and he should be notified about needing to save
his data and exit ASAP. but that's really another topic, probably
best tackled by gnome.
comments welcome and thanks for the interest.
---
ciaoTJ
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: turning g_assert* into warnings
Am Freitag, den 12.10.2007, 11:52 +0200 schrieb Tim Janik:
> note that in practice, this shouldn't change anything for programmers
> (except for the ability to write better code ;)
> because of G_DISABLE_ASSERT, programmers can already not rely on
> failing assertions to abort their programs (only g_error will reliably
> do that).
I was in strict "HELL, NO!" mode until I read this reasoning. Still I am
not sure if G_DISABLE_ASSERT is a misfeature, since when using g_assert*
instead of g_return* or g_warning you usually really have no good
fallback strategy and therefore accept the program crashing.
So for better error handling I'd suggest keeping the old and boring "if
(blub) { g_warning ... } paradigm.
Also remember that such a dramatic that (external) programmers most
certainly do not expect their program to continue after a failed
assertion (despite the G_DISABLE_ASSERT misfeature). So not calling
abort on failed assertions could make the program eat little children,
if not worse.
So I guess what you really want is some kind of "g_soft_assert" or some
"g_warn_if_fail".
Ciao,
Mathias
--
Mathias Hasselmann <[EMAIL PROTECTED]>
http://taschenorakel.de/
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: turning g_assert* into warnings
Hey,
Why not introduce a new check, some g_check_stuff() which would
do what you propose? And let g_assert() be what it is, a glib analog
of C assert(). When an assertion fails, you can't possibly expect the
code to function in any meaningful way, e.g.
int idx;
g_assert (idx >= 0);
array[idx] = 8;
you get segfault or worse here if g_assert() above fails to bring program
down, you simply can't change g_assert() now to behave in such a
different way.
Often you indeed can do sensible things after some important assumption
happened to be false, and in those situations a new check would be
really cool
(where existing code does manual checks like
if (bad) {g_critical ("oops"); emergency_return_or_whatever();} ).
But it should be a programmer decision, and it's just not acceptable
to change behavior of existing code.
Best regards,
Yevgen
Tim Janik wrote:
> hey All.
>
> i'd like to propose to turn g_assert and friends like g_assert_not_reached
> into warnings instead of errors. i'll give a bit of background before the
> details though.
>
> the main reasons we use g_return_if_fail massively throughout the glib and
> gtk+ code base is that it catches API misuses verbosely and gives programmers
> a chance to fix their code. this could be achieved with either a g_warning
> (mourn on stderr) or a g_error (mourn and abort).
>
> the reasons for the default behavior to use g_warning:
> a) a warning usually fullfills its purpose, the programmer knows there's
> something to fix and can start to trace the root cause.
> b) for easy tracing in gdb with backtraces, programmers can use
> --g-fatal-warnings to force abort behavior.
> c) programs that aren't 100% bug free could possibly trigger these warnings
> during production. aborting would take all the end user data with it,
> created/modified images, text documents, etc.
> issuing just a warnig preserves the possibility to still save crucial
> data if the application logic state still permits (which is most often
> the case in practice).
>
> in a recent discussion, i figured that (c) perfectly applies to g_assert
> and g_assert_if_reached() also. but we're actually aborting here:
>void
>g_assert_warning ([...])
>{
> [...]
> abort ();
>}
>
> i'd like to change that to:
>
>void
>g_assert_warning ([...])
>{
> [...]
> - abort ();
> + if (--g-fatal-warninngs)
> + abort ();
>}
>
> for a few reasons:
> 1) allow users to save their data if still possible; i.e. (c) from above.
> 2) for glib/gtk+ unit tests (more on that later), failing but
> non-aborting tests are interesting for overall report generation; and the
> ability to force immediate aborts for debugging is preserved with
> --g-fatal-warninngs.
> 3) assertions can help to document programmer intentions and frequent (but
> regulated) use as we have it with g_return_if_fail can significantly
> reduce debugging time. i have so far been fairly strict about not adding
> assertions to the glib/gtk+ core though, because they also tend to make
> the code and end-user experiences more brittle, especially an
> occasional wrong assertions that'd have to be revoked upon closer
> inspection.
> conditionalizing the abort removes the brittleness and allows for
> adding more helpful assertion statements.
>
> note that in practice, this shouldn't change anything for programmers
> (except for the ability to write better code ;)
> because of G_DISABLE_ASSERT, programmers can already not rely on
> failing assertions to abort their programs (only g_error will reliably
> do that).
> it should however take down programs in end user scenarios less often,
> and code review can be more lax about adding assertions.
>
> as a side note, it'd probably make sense to present the end users with more
> prominent warnings if one of his applications ran into a glib warning/
> critical/assertion, and he should be notified about needing to save
> his data and exit ASAP. but that's really another topic, probably
> best tackled by gnome.
>
> comments welcome and thanks for the interest.
>
> ---
> ciaoTJ
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: turning g_assert* into warnings
> c) programs that aren't 100% bug free could possibly trigger these warnings > during production. aborting would take all the end user data with it, > created/modified images, text documents, etc. > issuing just a warnig preserves the possibility to still save crucial > data if the application logic state still permits (which is most often > the case in practice). > > in a recent discussion, i figured that (c) perfectly applies to g_assert > and g_assert_if_reached() also. but we're actually aborting here: One problem i see is that g_return_if_fail() also does something, ie returns, which can act as a sufficient fallback in many cases. Another tradeoff is that while you may be able to save something, it may be corrupted. my recent work (on journalling databases) has seen a lot of cases where assertions prevented corruption from making it to disk, allowing an earlier state to be resumed. but that may be less common on the desktop. Finally, i do think it's a pretty big break with the traditional definition of assert(). - dave ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: turning g_assert* into warnings
On Fri, 12 Oct 2007, Yevgen Muntyan wrote:
> Hey,
>
> Why not introduce a new check, some g_check_stuff() which would
> do what you propose? And let g_assert() be what it is, a glib analog
> of C assert(). When an assertion fails, you can't possibly expect the
> code to function in any meaningful way, e.g.
>
> int idx;
>
> g_assert (idx >= 0);
> array[idx] = 8;
>
> you get segfault or worse here if g_assert() above fails to bring program
> down, you simply can't change g_assert() now to behave in such a
> different way.
please reread my reasoning about G_DISABLE_ASSERT, there already is no behavior
of g_assert() you could rely on. (and some distributions do build their
binaries with G_DISABLE_ASSERT and/or G_DISABLE_CHECKS defined).
if you really meant the above assertion as an essential program
logic part and want to depend on the program exiting before array[]
is accessed, you already have to use if (idx >= 0) g_error ("off bounds");
> Best regards,
> Yevgen
---
ciaoTJ
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: turning g_assert* into warnings
On Fri, 2007-10-12 at 14:40 +0200, Mathias Hasselmann wrote: > So I guess what you really want is some kind of "g_soft_assert" or some > "g_warn_if_fail". +1 on a g_warn_if_fail() API addition. ciao, Emmanuele. -- Emmanuele Bassi, W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: turning g_assert* into warnings
Tim Janik wrote:
> hey All.
>
> i'd like to propose to turn g_assert and friends like g_assert_not_reached
> into warnings instead of errors. i'll give a bit of background before the
> details though.
Like Mathias, I was in a bit of "hell no!" mode when I first read this.
After reading your rationale, I'm less opposed, but... well, still
opposed.
> the main reasons we use g_return_if_fail massively throughout the glib and
> gtk+ code base is that it catches API misuses verbosely and gives programmers
> a chance to fix their code. this could be achieved with either a g_warning
> (mourn on stderr) or a g_error (mourn and abort).
>
> the reasons for the default behavior to use g_warning:
> a) a warning usually fullfills its purpose, the programmer knows there's
> something to fix and can start to trace the root cause.
> b) for easy tracing in gdb with backtraces, programmers can use
> --g-fatal-warnings to force abort behavior.
> c) programs that aren't 100% bug free could possibly trigger these warnings
> during production. aborting would take all the end user data with it,
> created/modified images, text documents, etc.
> issuing just a warnig preserves the possibility to still save crucial
> data if the application logic state still permits (which is most often
> the case in practice).
This is reasonable, and pretty much covers why I use g_return_if_fail()
and friends.
> in a recent discussion, i figured that (c) perfectly applies to g_assert
> and g_assert_if_reached() also.
Sorry, but I just don't buy it. When I use g_assert(), my thinking is:
"this is something that's a pretty bad bug on my part, and if the
assertion fails, I'm almost 100% sure that the program is going to crash
very very soon, and possibly in unpredictable ways."
> for a few reasons:
> 1) allow users to save their data if still possible; i.e. (c) from above.
If I think it's possible for users to still do something meaningful with
the program, I'll use a g_return_if_fail() or a custom if(foo) {
g_warning(); do_something(); } type thing. That's why we have the
separate macros in the first place! g_return*() are for cases where the
programmer thinks recovery might be possible, and g_assert*() is where
it isn't possible.
> 3) assertions can help to document programmer intentions and frequent (but
> regulated) use as we have it with g_return_if_fail can significantly
> reduce debugging time. i have so far been fairly strict about not adding
> assertions to the glib/gtk+ core though, because they also tend to make
> the code and end-user experiences more brittle, especially an
> occasional wrong assertions that'd have to be revoked upon closer
> inspection.
And that's the right approach, IMO: use assertions sparingly. Sometimes
one might be a mistake, and you fix it.
> conditionalizing the abort removes the brittleness and allows for
> adding more helpful assertion statements.
No, it doesn't. Changing a g_assert*() to a g_return*() when you
realise aborting is unnecessary is the way to go.
> note that in practice, this shouldn't change anything for programmers
> (except for the ability to write better code ;)
> because of G_DISABLE_ASSERT, programmers can already not rely on
> failing assertions to abort their programs (only g_error will reliably
> do that).
... which I think is pretty broken. You shouldn't be able to disable
asserts and pre-condition checks (G_DISABLE_CHECKS) at compile time.
They were put there for a reason.
> it should however take down programs in end user scenarios less often,
> and code review can be more lax about adding assertions.
No -- instructing programmers to make *proper* use of g_assert*() (and
to use g_return*() otherwise) will bring programs down less often. Or
maybe not -- maybe everyone uses it "properly" and this problem you just
doesn't exist.
Also... The documentation tells us what g_return*() and g_assert*() do.
If you change this, you're essentially changing the API of glib.
That's... not cool. You can argue that G_DISABLE_CHECKS and
G_DISABLE_ASSERT will do this anyway, but that's a choice on the person
who builds the code (and again, I'd argue that the existence of those
defines is a *really* bad idea). IMO, if you build with
G_DISABLE_(CHECKS|ASSERTS), you get to keep the pieces when things break.
-brian
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: turning g_assert* into warnings
2007/10/12, Tim Janik <[EMAIL PROTECTED]>: > > hey All. > > i'd like to propose to turn g_assert and friends like g_assert_not_reached > into warnings instead of errors. i'll give a bit of background before the > details though. [snip] While the reasoning to make programs seem less crashy sounds compelling, isn't this just admitting that developers are misusing the g_assert* macros and Glib will bow down and disable functionality due to this? The macros are very clearly stated as fatal to the application in the documentation, so they should be used very carefully and only when *any* part of the program cannot function properly due to that condition being false. If an application is terminating while it still has a chance to save data, I'd say it is a bug in the application. It should either automatically do so before quitting or advice the user to perform those two tasks to prevent data loss. And libraries naturally should IMO _never_ use g_assert* in the first place, since libraries should never be in charge of application lifetime no matter how bad their internal state is. So I'd vote no for circumventing API misuse, no matter how wide it is. Distributors could start disabling assertions in their builds if they feel that it is compelling enough to warrant it, and as said, development builds (ie. all "from the source" installations) should always have clear indications of bugs. The macros probably could use more clear usage suggestions in the documentation though, mentioning the fact that using them in a library is usually just unfriendly to application developers since it prevents craceful termination even if it would be possible. -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://syslog.movial.fi ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: turning g_assert* into warnings
On Fri, 12 Oct 2007, Mathias Hasselmann wrote:
> Am Freitag, den 12.10.2007, 11:52 +0200 schrieb Tim Janik:
>> note that in practice, this shouldn't change anything for programmers
>> (except for the ability to write better code ;)
>> because of G_DISABLE_ASSERT, programmers can already not rely on
>> failing assertions to abort their programs (only g_error will reliably
>> do that).
>
> I was in strict "HELL, NO!" mode until I read this reasoning. Still I am
> not sure if G_DISABLE_ASSERT is a misfeature, since when using g_assert*
> instead of g_return* or g_warning you usually really have no good
> fallback strategy and therefore accept the program crashing.
>
> So for better error handling I'd suggest keeping the old and boring "if
> (blub) { g_warning ... } paradigm.
>
> So I guess what you really want is some kind of "g_soft_assert" or some
> "g_warn_if_fail".
thanks for the input, however i'm not surprised you bring this up ;)
i thought about suggesting some g_assert_warn() myself before i proposed
changing g_assert.
i didn't suggest introducing that because i fail to see a considerable
benefit in introducing it over adapting g_assert.
it boils down to these two properties of g_assert:
a) g_assert issues a warning about failing assertions, so in this regard
it already achieves what we'd otherwise use g_warn_if_fail() for;
b) we already can't rely on g_assert abort()-ing a program, depending on
the build time flag G_DISABLE_ASSERT.
given (b) in particular, g_assert already provides no stronger guarantees
than g_warn_if_fail would, so i think it'd be most straight forward if
we adopted the code to be more consistent about (b) so we only abort for
--g-fatal-warnings, and be more explicit (in the docs) about the existing
need that you have to use g_error() to reliably abort.
to some extend, this could be seen as just enabling a runtime switch
(--g-fatal-warnings) for an existing build time option (G_DISABLE_ASSERT).
> Also remember that such a dramatic that (external) programmers most
> certainly do not expect their program to continue after a failed
> assertion (despite the G_DISABLE_ASSERT misfeature). So not calling
> abort on failed assertions could make the program eat little children,
> if not worse.
the same reasoning applies to g_return_if_fail(), so i'll extend on it
here for a bit.
for development phase i welcome all available aid for developers and
support early catching + fixing of program errors, often done best with
gdb + --g-fatal-warnings (after all, that's why this option was introduced
in the first place).
for end-users however (i.e. production phase), it simply turned out that
warn + return for our many function call guards is much friendlier.
contrary to a developer, a user can't fix the program if it aborts, and
contrary to a developer, the user can loose critical data due to an
unneccesarily forced abort. (if developers trust critical data to their
programs during development phase, that's their own responsibility ;)
i'm not proposing any change in semantics here, glib/gtk+ programs
that spew a critical, warning or error are by definition in an undefined
state. the cause of which must be fixed, and no support or guarantees
for program behavior after a warning can be made.
however, the above end-user friendly reasoning about g_return_if_fail
also applies to g_assert, so i think assertions should be adapted to
act accordingly (abort on --g-fatal-warnings and not otherwise like
g_return_if_fail).
> Ciao,
> Mathias
---
ciaoTJ
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: turning g_assert* into warnings
Il giorno ven, 12/10/2007 alle 15.16 +0200, Tim Janik ha scritto: > please reread my reasoning about G_DISABLE_ASSERT, there already is no > behavior > of g_assert() you could rely on. (and some distributions do build their > binaries with G_DISABLE_ASSERT and/or G_DISABLE_CHECKS defined). What distributions? Excluding Gentoo and other distros that allow the user to choose how to build everything. -- Marco Barisione http://www.barisione.org/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
how to use libwnck to get information regarding the opened windows
hi.. how to get information regarding opened windows using libwnck library.. and another thing..how to log mouse events and keyboard events.. is there any package is there.. -- Thanks & Regards sridhar gupta yerram M.Tech(A.I) University of Hyderabad ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: turning g_assert* into warnings
That's pretty much a no-go. g_assert_warning is marked G_GNUC_NORETURN. If you return from such a function, there is no telling what incorrect assumption the following code was compiled with, i.e., things that the compiler thought were in registers all of a sudden are not. Crash. Burn. Toast. If you remove G_GNUC_NORETURN, you are going to get an unpleasant number of "might/is used uninitialized" warnings. And if you do return, you get the same problems with bad assumptions as above, only this time in the client program. All of this leads to the conclusion that g_asserts should be used sparingly, i.e., for things where the program is in a really bad shape and has no idea about how to limp on. Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: turning g_assert* into warnings
On Fri, 12 Oct 2007, Owen Taylor wrote: > On Fri, 2007-10-12 at 11:52 +0200, Tim Janik wrote: > >> i'd like to propose to turn g_assert and friends like g_assert_not_reached >> into warnings instead of errors. i'll give a bit of background before the >> details though. > > This is an incompatible change. The contract now is that unless you > compile with G_DISABLE_ASSERT, g_assert(FALSE) will cause your program > to exit with a non-zero status. i don't think a function contract is anything worth if it depends on build time options. if there is any contract breach here, it was the introduction of G_DISABLE_ASSERT (Thu Feb 19 01:11:48 1998 in gtk+-0.99.4 ;) however, due to the g_warn_if_fail variant having quite a following, i intend to change my proposal anyway. so persuing this argument is moot. > - Owen --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: turning g_assert* into warnings
On Fri, 2007-10-12 at 11:52 +0200, Tim Janik wrote: > i'd like to propose to turn g_assert and friends like g_assert_not_reached > into warnings instead of errors. i'll give a bit of background before the > details though. This is an incompatible change. The contract now is that unless you compile with G_DISABLE_ASSERT, g_assert(FALSE) will cause your program to exit with a non-zero status. The fact that you *could* fix up 'make test' (for GLib, etc, etc, etc) by making warnings terminate the program doesn't help. It's still incompatible. - Owen signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: turning g_assert* into warnings
Il giorno ven, 12/10/2007 alle 14.40 +0200, Mathias Hasselmann ha scritto: > I was in strict "HELL, NO!" mode until I read this reasoning. Still I am > not sure if G_DISABLE_ASSERT is a misfeature, since when using g_assert* > instead of g_return* or g_warning you usually really have no good > fallback strategy and therefore accept the program crashing. I always considered G_DISABLE_ASSERT as the glib version of NDEBUG, useful only for performance reasons. So if you disable assertions you know that you could get a program crashing hours after the g_assert and without any useful debugging output. > So I guess what you really want is some kind of "g_soft_assert" or > some > "g_warn_if_fail". +1 on g_warn_if_fail()/g_warn_if_reached(). -- Marco Barisione http://www.barisione.org/ ___ 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?
I've been thninking about this issue for some while now as well, and I've written (in gtkmm straight, so i didn't attempt to provide patches yet) a CairoImageSurface cellrenderer, and a few miscellaneous widgets which render directly a Cairo ImageSurface to a drawable instead of doing roundtrips. The renderer is a drop-in replacement for CellRendererPixbuf, it also has a pixbuf property, in which case it will render just that, otherwise it's possible to make it render imagesurface directly, or construct some in a cell data function. There is however one more problem which wasn't discussed yet in this thread: Widget insensitivity and the gtk style engines. The Pixbuf cellrenderer uses the gtk style engine to render its state when insensitive. It also uses a "gtkcellrendererpixbuf" detail to the style engine, and (thinking of Aaron Bockover's blog post about "Suboptimal Theming") possibly checks if the "widget" arg passed to it is a TreeView as well (i didn't check). My widgets fall back to rendering a Pixbuf version of the Cairo surface when insensitive, which is of suboptimal indeed. -- Milosz On 10 Oct 2007 21:46:38 +0200, Soeren Sandmann <[EMAIL PROTECTED]> wrote: > > "BJörn Lindqvist" <[EMAIL PROTECTED]> writes: > > > Incidentally, blitting pixbufs is slower than it has to be because its > > format rarely matches the X11 server which uses either xRGB32 or > > ARGB32. > > I don't disagree with anything else you say, but this "performance > issue" is really a non-issue. We are talking about data on the client > here, so there is no way the X server can hardware accelerate those > blits [1]. This means we are back to software in both cases, and in > that case the difference between convert_and_copy_data() and > copy_data() is completely negligble. > > > Soren > > > [1] Some day, maybe, we'll be able to DMA directly out of client > memory, but this will require lots of work in both the kernel and the > X server. We are still far away from that being possible. > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list > ___ 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 10/8/07, Kalle Vahlman <[EMAIL PROTECTED]> wrote: > 2007/10/8, BJörn Lindqvist <[EMAIL PROTECTED]>: > > It feels like Cairo doesn't fit in. For example, GDK uses GdkColor to > > represent colors but Cairo has no equivalent. > > There is gdk_cairo_set_source_color() though, which bridges the gap. > > > Same thing with > > GdkRectangle, GdkPoint and a whole host of other types that becomes > > much less useful in a cairo-world. > > There's also gdk_cairo_rectangle() and _region(), and I'm sure the > rest (what they ever may be) could have similar bridging API if deemed > necessary. Like forming a path from an array of GdkPoints etc. Yeah, but those functions aren't substitutes for "native" Cairo types. For example, gdk_cairo_set_source_color() as no matching gdk_cairo_get_source_color(). It is not so strange because Cairo handles an infinite amount of colors in the range 0..1 and has alpha channels, GdkColor only has 0..65535 and no alpha channel. There is a similar mismatch between GdkRectangle and cairo_rectangle_t. I think that integrating Cairo with GDK involves much more work than just replacing GdkPixbuf even if that is good first step. > > So how about replacing gdk-pixbuf with something cairo compatible that > > is also modern? 16 bits per sample is common these days. Support for > > digital camera RAW images would also be nice. Is a completely new > > image library worth pursuing? Are there maybe better ways to solve the > > problems Cairo and GdkPixbuf have? > > Even having an additional API for things like > gdk_pixbuf_cairo_load_from_file() would be a step forward I guess. I'd > personally like to see all the useful pixbuf API (file loading/saving, > possibly others) migrated to allow cairo usage and then deprecate > PixBufs over cairo image surfaces, but YMMV. I think that is out of the question. The Cairo developers are happy with Cairo being "only" a drawing API and letting other libraries handle loading and saving. -- mvh Björn ___ 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 10/8/07, Havoc Pennington <[EMAIL PROTECTED]> wrote: > BJörn Lindqvist wrote: > > So how about replacing gdk-pixbuf with something cairo compatible that > > is also modern? 16 bits per sample is common these days. Support for > > digital camera RAW images would also be nice. Is a completely new > > image library worth pursuing? Are there maybe better ways to solve the > > problems Cairo and GdkPixbuf have? > > > > I would say "completely new" is scary, because the actual loaders in > gdk-pixbuf represent years of bugfixes and contributions, and are > security-sensitive to boot. Something completely new that didn't use > that code would be a major regression. It might be nicer to frame the > issue as creating a parallel cairo-centric API using the same loader code. Yes, that is exactly what I meant. Of course it would be nice to extend it with support for 16 bit color channels and more image formats, but the working code should work. > Those two things (cairo surface from file/stream, and supporting cairo > surfaces where widgets currently support pixbufs) would address most > practical problems. Definitely would be good to get those simple fixes > in ASAP, imo. 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) and doesn't support as good-looking bilinear filtering that gdk-pixbuf does. -- mvh Björn ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Pixel formats and blitting performance
Hello!
On 10 Oct 2007 21:46:38 +0200, Soeren Sandmann <[EMAIL PROTECTED]> wrote:
> "BJörn Lindqvist" <[EMAIL PROTECTED]> writes:
>
> > Incidentally, blitting pixbufs is slower than it has to be because its
> > format rarely matches the X11 server which uses either xRGB32 or
> > ARGB32.
>
> I don't disagree with anything else you say, but this "performance
> issue" is really a non-issue. We are talking about data on the client
> here, so there is no way the X server can hardware accelerate those
> blits [1]. This means we are back to software in both cases, and in
> that case the difference between convert_and_copy_data() and
> copy_data() is completely negligble.
I'm not sure about that, but what I am (almost) sure about is that
blitting pixbufs is slow. :) Here is a small test program in SDL
(exhibit A):
--
#include
#include
#include
#define N_LOOPS 1000
#define SRC_DEPTH 32
#define DST_DEPTH 32
int main (int argc, char *argv[])
{
SDL_Init (SDL_INIT_EVERYTHING);
SDL_Surface *screen =
SDL_SetVideoMode (500, 500, DST_DEPTH, SDL_SWSURFACE);
SDL_Surface *surface =
SDL_CreateRGBSurface (SDL_SWSURFACE,
500, 500, SRC_DEPTH,
screen->format->Rmask,
screen->format->Gmask,
screen->format->Bmask,
0);
SDL_FillRect (surface, NULL, 0x);
struct timeval tv_start, tv_stop;
gettimeofday (&tv_start, NULL);
for (int n = 0; n < N_LOOPS; n++)
{
SDL_BlitSurface (surface, NULL, screen, NULL);
SDL_UpdateRect (screen, 0, 0, 0, 0);
}
gettimeofday (&tv_stop, NULL);
double elapsed = (tv_stop.tv_sec - tv_start.tv_sec) * 100.0 +
(tv_stop.tv_usec - tv_start.tv_usec);
double ms_tot = elapsed / 1000.0;
printf ("total %.2f ms, per loop %.2f\n", ms_tot, ms_tot / N_LOOPS);
}
--
On X11, this just copies a source surface to an XWindow using
XShmPutImage. And here is the same thing using GdkPixbufs (exhibit B):
--
#include
#include
#include
#define N_LOOPS 1000
int main (int argc, char *argv[])
{
gtk_init (&argc, &argv);
GtkWidget *win = gtk_window_new (GTK_WINDOW_TOPLEVEL);
gtk_window_set_default_size (GTK_WINDOW (win), 500, 500);
gtk_widget_show (win);
GdkPixbuf *src = gdk_pixbuf_new (GDK_COLORSPACE_RGB, TRUE, 8, 500, 500);
gdk_pixbuf_fill (src, 0xffff);
struct timeval start, stop;
gettimeofday (&start, NULL);
for (int n = 0; n < N_LOOPS; n++)
{
gdk_draw_pixbuf (win->window, NULL, src,
0, 0,
0, 0,
-1, -1,
GDK_RGB_DITHER_NONE, 0, 0);
}
gettimeofday (&stop, NULL);
double elapsed = (stop.tv_sec - start.tv_sec) * 100.0 +
(stop.tv_usec - start.tv_usec);
double ms_tot = elapsed / 1000.0;
printf ("total %.2f ms, per loop %.2f\n", ms_tot, ms_tot / N_LOOPS);
}
--
AFAIK, SDL performance is pretty damn good and probably as fast as you
can get on Linux. By changing SRC_DEPTH and DST_DEPTH in exhibit A, I
get different timings (best result for each):
SRC_DEPTH = 24, DST_DEPTH = 24 = 6.59 ms/loop
SRC_DEPTH = 32, DST_DEPTH = 24 = 6.55 ms/loop
SRC_DEPTH = 24, DST_DEPTH = 32 = 5.89 ms/loop
SRC_DEPTH = 32, DST_DEPTH = 32 = 1.84 ms/loop
I have a very fast computer and graphics card (NV43 GeForce 6200) so
these timings may not be representative for everyone. But at least in
this case I think it is clear that it pays off *alot* to use the
correct pixel format.
Here are the results for the GDK test (pixbuf with and without alpha
and best results):
ALPHA= 8.07 ms/loop
NO ALPHA = 2.10 ms/loop
Unless my tests are really flawed (they very well might - I'm not an
expert), it seems to me that avoiding pixel format conversions is
extremely important. Both GdkPixbuf and SDL uses XShmPutImage to draw
with and you can test the performance of that function alone:
$ x11perf --shmput500
...
2 trep @ 1.2978 msec ( 771.0/sec): ShmPutImage 500x500 square
So SDL adds 1.84 - 1.30 = 0.54 ms overhead and GDK 2.10 - 1.30 = 0.80
ms. That could be improved quite a bit I think.
--
mvh Björn
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: turning g_assert* into warnings
On 10/12/07, Emmanuele Bassi <[EMAIL PROTECTED]> wrote:
> On Fri, 2007-10-12 at 14:40 +0200, Mathias Hasselmann wrote:
>
> > So I guess what you really want is some kind of "g_soft_assert" or some
> > "g_warn_if_fail".
>
> +1 on a g_warn_if_fail() API addition.
What is wrong with:
if (!everything_is_ok)
g_warning ("blaha");
? Those double or triple negatives that the *_if_fail routines
introduce always confuses me: g_return_if_fail (!(flag != SOMETHING &&
x)); ugh..
--
mvh Björn
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: turning g_assert* into warnings
BJörn Lindqvist wrote:
> On 10/12/07, Emmanuele Bassi <[EMAIL PROTECTED]> wrote:
>
>> On Fri, 2007-10-12 at 14:40 +0200, Mathias Hasselmann wrote:
>>
>>
>>> So I guess what you really want is some kind of "g_soft_assert" or some
>>> "g_warn_if_fail".
>>>
>> +1 on a g_warn_if_fail() API addition.
>>
>
> What is wrong with:
>
> if (!everything_is_ok)
> g_warning ("blaha");
>
> ? Those double or triple negatives that the *_if_fail routines
> introduce always confuses me: g_return_if_fail (!(flag != SOMETHING &&
> x)); ugh..
>
You messed it up somehow. It's never triple, since our normal logic
is either "yes" or "no", the max is double negative which is positive.
Your example would be some
g_warn_if_fail (everything_is_ok, "blaha");
nothing fancy.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
