Re: [Gerbv-devel] Switching the default render mode to NORMAL
As Julian Lamb wrote: Is anyone vehemently opposed to switching the default to NORMAL? If so, please speak up now. Otherwise I'll apply Stefan's patch-set. On a slow machine, it might extend the startup time quite a bit. Ideally, there should be some kind of gerbv preferences ... For those who are plagued with a notoriously slow machine, how about at least adding a command-line option to override the default render mode? -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d ___ Gerbv-devel mailing list Gerbv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gerbv-devel
Re: [Gerbv-devel] Switching the default render mode to NORMAL
On Sun, 6 Mar 2011 13:53:29 +0100
Joerg Wunsch j...@uriah.heep.sax.de wrote:
For those who are plagued with a notoriously slow machine, how about
at least adding a command-line option to override the default render
mode?
skimmed over (the getopt code in) main() and was greeted by a creative
variation of whitespace behavior (8-unit tabs + 4-unit spaces) :(
i started to clean it up but refrained from continuing when i saw the
whole thing. im not willing to clean up other ppl's mess (or work with
it right now) sorry.
but the idea seems reasonable and easy to implement imho :)
--
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
From 0260cc2cf495226e27d4625b64ae2e6672616fe2 Mon Sep 17 00:00:00 2001
From: Stefan Tauner stefan.tau...@student.tuwien.ac.at
Date: Sun, 6 Mar 2011 14:36:27 +0100
Subject: [PATCH] whitespace cleanup of longopts[] in main.c
---
src/main.c | 22 +++---
1 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/src/main.c b/src/main.c
index c4daa20..7fedaf7 100644
--- a/src/main.c
+++ b/src/main.c
@@ -120,34 +120,34 @@ int longopt_val = 0;
int longopt_idx = 0;
const struct option longopts[] = {
/* name has_argflag val */
-{border, required_argument, NULL,'B'},
-{dpi, required_argument, NULL,'D'},
-{version, no_argument, NULL,'V'},
+{border, required_argument, NULL,'B'},
+{dpi, required_argument, NULL,'D'},
+{version, no_argument,NULL,'V'},
{origin, required_argument, NULL,'O'},
-{window_inch, required_argument, NULL,'W'},
-{antialias, no_argument, NULL,'a'},
+{window_inch, required_argument, NULL,'W'},
+{antialias, no_argument,NULL,'a'},
{background, required_argument, NULL,'b'},
-{dump,no_argument, NULL,'d'},
+{dump,no_argument,NULL,'d'},
{foreground, required_argument, NULL,'f'},
-{help,no_argument, NULL,'h'},
+{help,no_argument,NULL,'h'},
{log, required_argument, NULL,'l'},
{output, required_argument, NULL,'o'},
{project, required_argument, NULL,'p'},
{tools, required_argument, NULL,'t'},
{translate, required_argument, NULL,'T'},
-{window, required_argument, NULL,'w'},
+{window, required_argument, NULL,'w'},
{export, required_argument, NULL,'x'},
{geometry,required_argument, longopt_val, 1},
/* GDK/GDK debug flags to be let through */
{gtk-module, required_argument, longopt_val, 2},
-{g-fatal-warnings,no_argument, longopt_val, 2},
+{g-fatal-warnings,no_argument,longopt_val, 2},
{gtk-debug, required_argument, longopt_val, 2},
{gtk-no-debug,required_argument, longopt_val, 2},
{gdk-debug, required_argument, longopt_val, 2},
{gdk-no-debug,required_argument, longopt_val, 2},
{display, required_argument, longopt_val, 2},
-{sync,no_argument, longopt_val, 2},
-{no-xshm, no_argument, longopt_val, 2},
+{sync,no_argument,longopt_val, 2},
+{no-xshm, no_argument,longopt_val, 2},
{name,required_argument, longopt_val, 2},
{class, required_argument, longopt_val, 2},
{0, 0, 0, 0},
--
1.7.1
--
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d___
Gerbv-devel mailing list
Gerbv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gerbv-devel
Re: [Gerbv-devel] Switching the default render mode to NORMAL
As Stefan Tauner wrote: skimmed over (the getopt code in) main() and was greeted by a creative variation of whitespace behavior (8-unit tabs + 4-unit spaces) :( Well, there's nothing wrong with that per se. Alas, there are other functions apparently written with the assumption that one hard tab occupies four columns, and in even other cases, there are four spaces in front of the first tab. :/ Plus, a lot of trailing whitespace all over the file. im not willing to clean up other ppl's mess (or work with it right now) sorry. Well, I wouldn't touch the existing code anyway. Cosmetical changes are always a bad thing to do, and if at all, they should be committed as a change of its own, so by reading the commit log, you immediately know that you don't have to expect any functional change in that commit. If all that's needed is a patch, I'm willing to contribute that. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d ___ Gerbv-devel mailing list Gerbv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gerbv-devel
Re: [Gerbv-devel] Switching the default render mode to NORMAL
Joerg, Sorry...I misunderstood your offer. :) If you don't have time, I'll take a look into it in the next few weeks. Cheers-- Julian On 03/06/2011 03:18 PM, Joerg Wunsch wrote: As Julian Lamb wrote: If you feel like creating a patch for the cleanup, I would definitely welcome it. Ah well, I've been referring to a patch to implement the commandline option to setup the rendering mode. ;-) As for the cleanup, well, I might look into that, but won't make any promises. -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d ___ Gerbv-devel mailing list Gerbv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gerbv-devel
Re: [Gerbv-devel] Switching the default render mode to NORMAL
On 03/06/2011 08:22 PM, Julian Lamb wrote: As Stefan Tauner wrote: skimmed over (the getopt code in) main() and was greeted by a creative variation of whitespace behavior (8-unit tabs + 4-unit spaces) :( Well, there's nothing wrong with that per se. Alas, there are other functions apparently written with the assumption that one hard tab occupies four columns, and in even other cases, there are four spaces in front of the first tab. :/ Plus, a lot of trailing whitespace all over the file. Welcome to communal software development! When many different people contribute, you're bound to get a mix. Stefan's original code used a unique indentation method (2 spaces to start, then +4 spaces for each level afterward)...I'm assuming he was using some specific Emacs modeline for his coding. It should be 4 spaces per increment, never two anywhere what I know of. Maybe in error? I use emacs with the following code snippet in my .emacs: ;;; Common C-mode hooks (defun my-c-mode-hook () (setq c-basic-offset 4) (turn-on-font-lock)) (add-hook 'c-mode-hook 'my-c-mode-hook) Original emacs uses 2 and linux/BSD uses 8. This is something in between. My original intentions for code standard are described in the HACKING file of the repository. (http://git.gpleda.org/?p=gerbv.git;a=blob;f=HACKING;h=a700f7bb6a280a5e38c69ea21829aed1add84bbe;hb=HEAD). When I started to get contributions I was glad to get contributions and did not enforce any coding standard. Anyhow, I'm still more glad for all contributions than for code standard. Regards, /Stefan -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d ___ Gerbv-devel mailing list Gerbv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gerbv-devel
Re: [Gerbv-devel] Switching the default render mode to NORMAL
Julian et al, when it comes to Cairo and it's infamous lack of rendering speed I have a slight hum of remembering a discussion of why Cairo was so much slower. I cannot understand why it should be so much slower... There were some work put into finding out why. I found code that implements pixel align. My simple tests using Analyze-Benchmark did not give any big difference between pixel align or not (disabled/enable via the #define in draw.c). Is there a simple trick to get it faster? In GTK there are, for instance functions, where you send in lists of objects to draw, and that makes it faster. I use libcairo 1.8. Is 1.9 faster in any way? When it comes to replacing GDK, I think it is a long trip. It might suck but there is a lot of energy put into that. But I for one would like to see a solution of the Cairo slowness to get rid of GDK, because Cairo is so much better in every other way. But more than 5 times slower is not acceptable. Regards, /Stefan On 03/05/2011 08:39 PM, Julian Lamb wrote: Stefan Tauner, Thanks for the patch set. I, personally, would like to switch the default to NORMAL, but other developers have been resistant in the past. However, GTK3.0 is officially deprecating the GDK code, so we can probably assume it will be eliminated by the time GTK4 comes out. Is anyone vehemently opposed to switching the default to NORMAL? If so, please speak up now. Otherwise I'll apply Stefan's patch-set. Cheers-- Julian On 03/05/2011 01:54 PM, Stefan Tauner wrote: hello regarding the fast aka GERBV_RENDER_TYPE_GDK rendering mode julian said in bug 3197741 (https://sourceforge.net/tracker/?func=detailatid=409538aid=3197741group_id=33921) will be deprecated soon. if it will... it shouldnt be the default mode in everything != WIN32 imho. :) on the search for the reason why it defaults to fast on my machine i also noticed a bug in the contribution i made before and some use of magical numbers... -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d ___ Gerbv-devel mailing list Gerbv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gerbv-devel
[Gerbv-devel] Switching the default render mode to NORMAL
Stefan Tauner, Thanks for the patch set. I, personally, would like to switch the default to NORMAL, but other developers have been resistant in the past. However, GTK3.0 is officially deprecating the GDK code, so we can probably assume it will be eliminated by the time GTK4 comes out. Is anyone vehemently opposed to switching the default to NORMAL? If so, please speak up now. Otherwise I'll apply Stefan's patch-set. Cheers-- Julian On 03/05/2011 01:54 PM, Stefan Tauner wrote: hello regarding the fast aka GERBV_RENDER_TYPE_GDK rendering mode julian said in bug 3197741 (https://sourceforge.net/tracker/?func=detailatid=409538aid=3197741group_id=33921) will be deprecated soon. if it will... it shouldnt be the default mode in everything != WIN32 imho. :) on the search for the reason why it defaults to fast on my machine i also noticed a bug in the contribution i made before and some use of magical numbers... -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d ___ Gerbv-devel mailing list Gerbv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gerbv-devel -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d___ Gerbv-devel mailing list Gerbv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gerbv-devel
